The core thesis
There is no profile-free code quality
No file can sit at 100% on all fourteen dimensions, because the dimensions conflict pairwise: code that maxes raw speed necessarily spends readability; code that maxes one-off economy necessarily spends robustness. So a single quality score is not just lossy - it is wrong about what good code is. A profileis Facet’s unit of judgment instead: a named claim about which dimensions this code deliberately buys, and which it deliberately sells. The same file can be excellent as a quick script and negligent as a security boundary.
Profile names describe the optimisation target- never the code’s worth, and never a lifespan judgement. A low reading on a dimension your profile does not prioritise is a deliberate trade, not a fault; Facet’s reports and suggestions are built around that rule.
The ten profiles
Optimises = the priority dimensions the fit score and suggestions read against, in order. Typically trades away = what honest code built for this purpose usually sells to get there.
P1 HOT PATH
Built for raw speed on the execution path.
Optimises: D1 Runtime performance › D2 Memory efficiency › D12 Concurrency safety
Typically trades away: readability (manual unrolling, bit tricks) and quick-iteration economy
P2 QUICK SCRIPT
Built for getting a one-off job done fast.
Optimises: D8 Prototype economy
Typically trades away: robustness, testability, observability, auditability - deliberate, bounded debt
P3 PUBLIC LIBRARY
Built for consumers: a stable, readable, portable interface.
Optimises: D13 API ergonomics › D3 Readability › D4 Maintainability › D7 Portability › D5 Robustness
Typically trades away: raw speed (safety over cycles) and one-off economy
P4 REGULATED CORE
Built for auditability and defensive correctness.
Optimises: D11 Auditability › D5 Robustness › D6 Security › D9 Testability › D3 Readability
Typically trades away: one-off economy, and often raw speed - audit hooks cost cycles
P5 TEACHING EXAMPLE
Built for being understood.
Optimises: D3 Readability
Typically trades away: performance and resource cost - clarity over cleverness
P6 EMBEDDED / EDGE
Built for tight memory and resource budgets.
Optimises: D2 Memory efficiency › D14 Resource cost › D1 Runtime performance › D5 Robustness
Typically trades away: readability (packed structs) and portability - target-specific by design
P7 HIGH-CONCURRENCY SERVICE
Built for staying correct under load.
Optimises: D12 Concurrency safety › D10 Observability › D5 Robustness › D1 Runtime performance › D4 Maintainability
Typically trades away: one-off economy and some readability - locking discipline is verbose
P8 RESEARCH PROTOTYPE
Built for exploring an idea quickly.
Optimises: D8 Prototype economy › D9 Testability
Typically trades away: security, observability, auditability, interface polish
P9 SECURITY-CRITICAL BOUNDARY
Built for resisting adversarial input.
Optimises: D6 Security › D5 Robustness › D11 Auditability › D9 Testability
Typically trades away: one-off economy and some raw speed - validation costs cycles
P10 DATA PIPELINE
Built for robust, observable data flow.
Optimises: D5 Robustness › D10 Observability › D2 Memory efficiency › D1 Runtime performance
Typically trades away: one-off economy and interface polish
Why you can’t have all fourteen
The load-bearing tensions. This list is engineering rationale - the design argument behind the taxonomy - not a measured finding; the measured layer is the per-dimension evidence in your report.
Performance ↔ Readability. optimised code stops reading cleanly - unrolling, caching tricks, and branch-avoidance all trade clarity for cycles.
Performance ↔ Memory. caching buys speed with memory; streaming buys memory with speed. You pick one direction per hot path.
Robustness ↔ Quick-iteration economy. defence is ceremony: validation, failure handling, and guards are exactly what a one-off script strips to stay fast to write.
Security ↔ API ergonomics. fail-closed friction fights ergonomic defaults - the safest interface is rarely the smoothest one.
Auditability ↔ Performance / Maintainability. audit trails add cost and coupling: every traced decision is extra work on the path and extra structure to maintain.
Concurrency ↔ Readability / Economy. correct concurrent code is verbose - guards, bounds, and ownership discipline don't compress.
Resource cost ↔ Observability. telemetry costs compute: every log line and metric is capability bought with efficiency.
How Facet decides which profile to read against
Strict precedence, most honest signal first:
- Your ranked priorities (the 1st-to-5th picker on the dashboard) - the most precise signal there is: you say exactly which dimensions matter, in order, and the whole report reads against that.
- Your declared profile - you name one of the ten; the report holds the code to that bar.
- The auto-read - a confidence-gated heuristic over the measured shape. It only names a profile when the code is differentiallystrong on that profile’s priorities, it reports its own confidence (weak / moderate / strong), and when the dimensions read as balanced it abstains and says so rather than force a label. The auto-read describes what the code is; only you can say what it is for.
Profile a file against your intent See one problem solved for different profiles Open a sample report