Facet

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 performanceD2 Memory efficiencyD12 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 ergonomicsD3 ReadabilityD4 MaintainabilityD7 PortabilityD5 Robustness

Typically trades away: raw speed (safety over cycles) and one-off economy

P4 REGULATED CORE

Built for auditability and defensive correctness.

Optimises: D11 AuditabilityD5 RobustnessD6 SecurityD9 TestabilityD3 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 efficiencyD14 Resource costD1 Runtime performanceD5 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 safetyD10 ObservabilityD5 RobustnessD1 Runtime performanceD4 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 economyD9 Testability

Typically trades away: security, observability, auditability, interface polish

P9 SECURITY-CRITICAL BOUNDARY

Built for resisting adversarial input.

Optimises: D6 SecurityD5 RobustnessD11 AuditabilityD9 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 RobustnessD10 ObservabilityD2 Memory efficiencyD1 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:

  1. 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.
  2. Your declared profile - you name one of the ten; the report holds the code to that bar.
  3. 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