python · profiled 15/06/2026, 2:30:00 am UTC · Copy for AI agent copies this whole report as a markdown brief - ordered fixes with cited lines - ready to paste into Claude Code, Cursor, or whichever agent maintains this code.
Closest auto-match: P2 QUICK SCRIPTweak signal - a hint
Fit to P2 QUICK SCRIPT: 67% of its priorities in place (partial fit)
If this is code built for getting a one-off job done fast, Facet reads every dimension against that profile, not a universal ideal. The dimensions this profile prioritises (marked priority) are what “good” means here; a low level on a dimension it does not prioritise is a deliberate trade, not a fault. A quick one-off script that skips tests is passing; a security boundary that skips validation is not. The profile above is auto-inferred - declare the one you intend for the exact read.
Every dimension is read on two separate tracks that are never added together: ✓ good practices found grows right, ✕ harmful patterns found grows left. Code can score high on one and low on the other at once, which a single number would hide. N/A means there is nothing for that dimension to measure here, which is not a low score.
D1 Runtime performance✕ 0%✓ 57%
D2 Memory efficiency✕ 0%✓ 38%
D3 Readability✕ 0%✓ 63%
D4 Maintainability✕ 0%✓ 43%
D5 Robustness✕ 33%✓ 22%
D6 Security✕ 33%✓ 50%
D7 Portability✕ 0%✓ 71%
D8 Prototype economypriority✕ 0%✓ 100%
D9 Testability✕ 0%✓ 25%
D10 Observability✕ 0%✓ 43%
D11 Auditability✕ 0%✓ 29%
D12 Concurrency safety✕ 33%✓ 38%
D13 API ergonomics✕ 0%✓ 43%
D14 Resource cost✕ 0%✓ 57%
probeD6 Security
measures Resisting adversarial input and protecting secrets, with fail-closed defaults.
reading 4 of 8 applicable capabilities present; 1 of 3 harm patterns present. Severity-weighted score 0.50 / 1.00 - see the security card below. Flagged for a human glance: retry/backoff wrapper present over an operation with no idempotency guard.
cited✕ lines 22, 25: the retry/backoff wrapper re-runs the write with no idempotency key on failure
D6 - the worst finding sets the score
Score 0.50 / 1.00
Held to 0.50 by the most severe finding present; no critical defect detected. The score is set by the single most severe finding present, not an average: one critical flaw caps it, and good practice elsewhere cannot buy that back. Defensive coverage is shown beside it, never subtracted from it.
Defensive coverage: 55% of the protections that apply here are in place.
Important
Input size bounds (MAJOR) - missing protection
Strengths - load-bearing protections in place
No hardcoded secrets (BLOCKER)
No sql injection sink (CRITICAL)
Low-severity notes (they do not move the score)
✓ minor good practices in place: Uses https by default
Weight confidence: Uses https by default (provisional). Provisional or contested weights are flagged so the score never claims more certainty than it has.
priority marks the dimensions P2 QUICK SCRIPT optimises for (D8); they carry the most weight in the fit score and the suggestions. A low pole on a non-priority dimension is a deliberate trade, not a fault.
One or more dimensions show a higher-ladder practice sitting over a missing lower-ladder foundation (a possible cargo-cult pattern). It is flagged for a human glance, not penalised.
Suggestions for P2 QUICK SCRIPT
Only two things earn a suggestion here: a gap on a dimension this read prioritises, or a harmful pattern anywhere (harm is never a trade). Work through them top to bottom, then re-profile: the good-practices track should climb without new harmful patterns appearing. Low capability on a dimension this profile does not prioritise is a deliberate trade - those sit under their own fold below, not in this list.
Fastest way to act on all of it: Copy for AI agent (top of the report) puts the whole brief - ordered fixes, cited lines, and the profile-relative ground rules - on your clipboard, ready to paste into Claude Code, Cursor, or whichever agent maintains this code.
What “Concrete fix” gives you
One small, reviewable edit for this one dimension - a recommendation, the minimal change (with a short revised snippet when the edit is clear), why it helps, and a way to verify it. It is not a rewrite of your whole file, and Facet never applies it for you.
The grey Area line beside each item is a direction, not code - this button is what turns it into an actual edit you can apply.
Paste just the function, class, or block the Where line points at - not the whole file. A tight snippet gives a better-placed fix; more than that only slows it down.
New to the code? Each fix ends with a Verify step you can run to check it worked. Still, read it before you apply it - it is a suggestion from a general-purpose model, not a guaranteed patch, and security changes especially deserve a look.
Concrete fix preview
In a live report, each suggestion can be turned into one small, reviewable code change by pasting the relevant snippet: you get the change, a short revised snippet when the edit is clear, why it matters, and how to verify it - never a whole-file rewrite, and never applied for you. The fix model sees only the public dimension name, the improvement direction, and your snippet; it never receives Facet’s proprietary indicators.
D5 RobustnessValidate the event payload before any field is read; an unchecked amount can raise deep in processing on malformed input.
Area: defensive correctness: input validation and failure handling.Where: lines 12-18.
✕ lines 12, 18: amount is read directly off the event dict with no bounds or type check before use
D6 SecurityAdd idempotency protection before retrying: a retried write with no dedupe key can double-apply on a transient failure.
Area: untrusted-input handling and fail-closed defaults.Where: lines 22-25.
✕ lines 22, 25: the retry/backoff wrapper re-runs the write with no idempotency key on failure
D12 Concurrency safetyGuard the shared counter update: two workers retrying the same event can race on the same account total.
Area: parallel-execution correctness and safe shared state.Where: lines 30-34.
✕ lines 30, 34: the running total is read, incremented, and written back with no lock or compare-and-swap
Deliberate trades (10) - capability headroom on dimensions this read does notprioritise. Leaving these low is the design, not a fault; only touch them if the code’s intent changes.
D9 TestabilityIf the intent changes: verifiability: seams, injection points, and pure functions.
D11 AuditabilityIf the intent changes: traceability: making behaviour externally verifiable.
D2 Memory efficiencyIf the intent changes: memory footprint: streaming and avoiding large intermediate copies.
D4 MaintainabilityIf the intent changes: change-cost: decoupling and removing duplication.
D10 ObservabilityIf the intent changes: operational visibility: logging and diagnosability.
D13 API ergonomicsIf the intent changes: interface design: misuse-resistance and stability.
D1 Runtime performanceIf the intent changes: the hot path: cutting per-item work and allocations.
D3 ReadabilityIf the intent changes: clarity: naming, structure, and intent-revealing organisation.
D7 PortabilityIf the intent changes: dependency minimalism and environment assumptions.
D14 Resource costIf the intent changes: deployment cost: compute and energy efficiency.
A model reads the code and cites the lines it relies on; deterministic scoring, not the model, sets each score, so the same code always gets the same result, and each dimension is routed to the judge that proved most reliable at measuring it. Hover a dimension for what it measures, or read the methodology for why there is no single best.
Why this report is trustworthy
The model is used to cite evidence from the submitted code, while deterministic scoring code sets the dimension levels from those findings, and the report keeps capability signals separate from harmful pattern signals instead of averaging them into a single opaque score. For methodology, validation, and deployment questions, see the Facet methodology page.
Profile your own code
This is a read-only report. Run Facet on your own file the same way: free while in beta, and your source code is never stored.
Facet reads this code against the profile it appears built for, then separates capability signals from harmful pattern signals. The result is a profile-relative view of fitness, not a universal scorecard.
Read againstP2 QUICK SCRIPT
Harmful patterns3 present across all dimensions
Priority dimensionsD8
Dimension profile
Green bars show capability indicators present. Coral bars show harmful patterns present. These poles are not netted, because absence of a good practice is different from presence of a harmful pattern.
Dimension
Capability
Harm
Status
D1 Runtime performance
57%
0%
-
D2 Memory efficiency
38%
0%
-
D3 Readability
63%
0%
-
D4 Maintainability
43%
0%
-
D5 Robustness
22%
33%
1 harm
D6 Security
50%
33%
1 harm
D7 Portability
71%
0%
-
D8 Prototype economypriority
100%
0%
priority
D9 Testability
25%
0%
-
D10 Observability
43%
0%
-
D11 Auditability
29%
0%
-
D12 Concurrency safety
38%
33%
1 harm
D13 API ergonomics
43%
0%
-
D14 Resource cost
57%
0%
-
Security, severity-weighted and non-compensatory
For dimensions with an external severity standard (security today), the score is the non-compensatory ceiling: the single worst finding present sets it. A detected critical defect fails the dimension closed regardless of surrounding good practice. Defensive coverage is reported separately and never offsets a defect.
D6: score 0.50 / 1.00. Defensive coverage 55%.
Strengths: No hardcoded secrets; No sql injection sink.
Recommendations
These recommendations are ranked by profile priority and measured gap. They are intended as review prompts for the code owner, not as automatic defect findings.
01
D5 Robustness
Validate the event payload before any field is read; an unchecked amount can raise deep in processing on malformed input.
Area: defensive correctness: input validation and failure handling.
02
D9 Testability
Open test seams: pull logic into pure functions and inject the dependencies you need to fake.
Area: verifiability: seams, injection points, and pure functions.
03
D11 Auditability
Make behaviour traceable: leave a verifiable record of what was decided and why.
Area: traceability: making behaviour externally verifiable.
04
D2 Memory efficiency
Lower peak memory: stream data through instead of materialising large intermediate copies.
Area: memory footprint: streaming and avoiding large intermediate copies.
05
D4 Maintainability
Cut the cost of change: decouple the pieces that change together and fold duplicated logic.
Area: change-cost: decoupling and removing duplication.
06
D6 Security
Add idempotency protection before retrying: a retried write with no dedupe key can double-apply on a transient failure.
Area: untrusted-input handling and fail-closed defaults.
07
D10 Observability
Make it diagnosable in production: log the decisions and failures an operator would ask about.
Area: operational visibility: logging and diagnosability.
08
D12 Concurrency safety
Guard the shared counter update: two workers retrying the same event can race on the same account total.
Area: parallel-execution correctness and safe shared state.
09
D13 API ergonomics
Make the interface hard to misuse: predictable naming, safe defaults, stable types.
Area: interface design: misuse-resistance and stability.
10
D1 Runtime performance
Trim the hot path: cut per-item work and avoidable allocations inside the loops that run most.
Area: the hot path: cutting per-item work and allocations.
11
D3 Readability
Make intent legible at a glance: sharper names, smaller units, structure that mirrors the problem.
Area: clarity: naming, structure, and intent-revealing organisation.
12
D7 Portability
Loosen environment assumptions: fewer dependencies and fewer platform-specific code paths.
Area: dependency minimalism and environment assumptions.
13
D14 Resource cost
Cut what it costs to run: the same result for less compute.
Area: deployment cost: compute and energy efficiency.
Trust and interpretation
Facet uses model calls to extract evidence from code, then deterministic scoring code assigns the dimension levels. The same unchanged code is frozen by content hash so repeated analyses return the same measurement. Each dimension is routed to the judge that proved most reliable at measuring it, after clearing Facet's reliability gate for that construct.
Serious readers should review the public methodology page for validation details, reliability criteria, and deployment constraints before treating the report as a governance artefact.
Pro feature · Concrete fix
What a Pro “concrete fix” looks like
On Pro, every area-level recommendation gets a one-click concrete fix generated against your own code. Here is a representative example for the D5 Robustness recommendation above. (Static preview; the live feature runs on your signed-in code.)
Recommendation (D5 Robustness, lines 12–18): external input is consumed before it is validated.
Suggested fix. Validate the event payload at the boundary before any field is read, and reject malformed input early so a bad message cannot propagate downstream.
Why it matters. An unchecked event["amount"] will raise deep in processing on a malformed message, where the failure is hard to attribute and may leave a partial write. Failing fast at the edge keeps the error close to its cause.
def handle(event: dict) -> None:
if not isinstance(event, dict) or "amount" not in event:
raise ValueError("event missing required 'amount'")
amount = event["amount"]
if not isinstance(amount, (int, float)) or amount < 0:
raise ValueError("amount must be a non-negative number")
... # safe to proceed
Verify by replaying a malformed event through your tests and confirming it is rejected at the edge.