SAMPLE REPORT · Rendered from a fixture, not a live scan · Start your free trial
Sample · analysed January 1, 2026 · 60s run
Every card below is rendered by the same component the live product uses. The only difference is that this page is loaded from a saved fixture instead of your repository.
Operational maturity
0.74
Change safety
0.68
Outage chance ≤ 30d
18.0%
Change Risk
0.22
What is this?
A single 0–100 score that summarises whether this codebase can launch safely, absorb growth, and survive continuous change. Higher is better. The score combines ten resilience dimensions, the outage forecast, and build/test discipline into one auditable number.
How is it measured?
The score combines the resilience profile below, the outage forecast, and build/test discipline into a single auditable number. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Launch With Conditions. One or more dimensions are below par. Address the top remediation actions before go-live.
What to do
The weakest dimensions below are the highest-leverage remediation targets.
What is this?
The gap between quality tools that are installed in this repository and quality tools that are actually wired into CI. A codebase with linters, type-checkers, formatters, and test runners all installed — but not enforced on every change — signals AI-assisted development without quality gates. Higher Change Risk is worse.
How is it measured?
Aura inspects the repository’s quality toolchain — which linters, type-checkers, formatters, and test runners are installed, and whether they are actually enforced on every change. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
MODERATE. Most installed tools are enforced; a meaningful minority are not. Common sources: a lint config that exists but is not run on PRs, a test suite without a CI step.
What to do
Move the remaining unenforced tools to required CI checks. Most common gap: pre-commit hooks running locally but not gated on PRs.
What is this?
Some Aura outputs carry a 'provisional' badge while their weighting constants are calibrated against real-world assessments. The methodology and the score are real; the precise weights are still being tuned against ground-truth data.
How is it measured?
Outputs carry a provisional badge while their weighting is refined against real-world assessments. Scores are versioned so results stay comparable run-to-run.
What to do
Use provisional scores to identify the largest resilience gaps; the current scoring-version status appears in your authenticated report.
A small group of people understands this system. Losing one creates real incident risk.
2–3 people own the critical code paths. The absence of any one of them significantly slows incident response. Knowledge transfer has started but isn't complete.
Run a knowledge-transfer session for the top 5 highest-impact files. Each session should produce a short document: what it does, what can go wrong, and how to debug it.
The codebase is navigable, but some areas have high cognitive load.
Most areas follow clear patterns, but the highest-complexity files are hard to reason about. New developers struggle to understand those files without help.
Add JSDoc comments to the 10 highest-CCR files. One sentence per exported function explaining what it does and what can go wrong.
The system can survive some vendor failures, but not all critical ones.
Several vendor dependencies exist without circuit breakers. Some will cause degraded experiences when they're unavailable. The system doesn't distinguish between 'vendor down' and 'system broken'.
Add a /health endpoint that checks each vendor dependency. Return a 200 with a JSON body that shows which vendors are up and which are degraded. Surface this on a status page.
You have quality tools installed that aren't protecting you.
ESLint is installed but not enforced. It can run on a developer's machine — but it doesn't block a bad commit from reaching production. The tool is there; the protection isn't.
Add 'eslint --max-warnings=0' as a required CI step. This is a single-line change in your workflow file. After that, no commit can bypass the linter.
P30
18.0%
probability · next 30 days
P90
45.0%
probability · next 90 days
P180
71.0%
probability · next 180 days
Simulated outage rate 4.3%.
Understanding the 10 dimensions
What is this?
The share of the codebase's structurally important code that is free of architectural violations. Higher means a larger share of your most-central code is clean. Maps to ISO 25010 — Maintainability → Analysability.
How is it measured?
Components are checked against architectural rules; the score reflects how much of the structurally important code is violation-free. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. Most of the structurally important code is free of architectural violations.
What to do
No action required. Continue architectural review on new code.
What is this?
Whether this codebase has the operational machinery a system needs to ship, observe, and recover safely: CI/CD, observability, infrastructure-as-code, secret hygiene, scale-readiness. Maps to ISO 25010 — Performance Efficiency, Security.
How is it measured?
A composite of operational signals: CI/CD presence, observability tooling, infrastructure-as-code, secret hygiene, scale-readiness, and toolchain enforcement. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. The operational toolchain (CI, observability, scale-readiness) is largely in place.
What to do
Maintain. The operational toolchain is largely in place.
What is this?
Whether the codebase contains the structural ingredients of complete user flows: a UI layer that calls an API layer that talks to a data layer, plus a security layer for protected flows. Measures the architectural shape of user-facing flows, not their end-to-end correctness.
How is it measured?
The dependency graph is checked for the structural ingredients of complete user flows — UI, API, data, and protected-path layers present and connected. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Caution. Some flow segments are present but at least one core flow (signup, checkout, or auth-recovery) is structurally incomplete.
What to do
Identify which flow segment is missing. Most common: a UI exists but no security layer wired into the protected routes.
What is this?
How resilient the codebase is to the loss of any single contributor — bus factor, documentation depth, and architectural decision capture. Maps to ISO 25010 — Maintainability → Transferability.
How is it measured?
Estimated from how broadly the codebase spans architectural layers, as a structural proxy for knowledge concentration. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Caution. The codebase spans only some architectural layers — knowledge may be concentrated.
What to do
Document architectural decisions (ADRs) and add an onboarding README.
What is this?
How safely changes can be made to this codebase. Lower architectural-violation density and stronger toolchain enforcement both raise this score. Maps to ISO 25010 — Maintainability → Modifiability.
How is it measured?
Combines the density of architectural violations with whether the quality toolchain is enforced — unenforced toolchains amplify structural risk. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. Structural change risk is low.
What to do
Maintain. Re-assess as the toolchain and structure evolve.
What is this?
How well a single-component failure is prevented from cascading to other components. Driven by the presence of timeouts, retries, circuit breakers, and other safeguards on outbound dependencies. Maps to ISO 25010 — Reliability → Fault Tolerance.
How is it measured?
Assesses whether resilience safeguards exist on the components whose failure would matter most — combining component criticality with detected safeguards on outbound calls. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. The structural ingredients of failure containment (safeguards on the most-central boundaries) are present.
What to do
Maintain. Continue to add safeguards to new high-blast-radius components as they are introduced.
What is this?
How resilient the data layer is to destructive change — schema drift, irreversible migrations, and concentration of data risk on the most-central components. Higher means data-critical operations are spread across the codebase rather than concentrated on a few central components.
How is it measured?
Measures how concentrated schema-touching operations are on the most-central components — concentration raises the impact of destructive changes. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. Schema-touching operations are not unduly concentrated on the most-central components.
What to do
Maintain. Keep migration review discipline on schema-touching components.
What is this?
How mentally tractable the codebase is to a working engineer. Lower per-component complexity — fewer cross-domain responsibilities and less coupling on the most-central components — raises this score. Grounded in Shannon entropy and Miller's Law on working-memory limits.
How is it measured?
Estimates per-component complexity — coupling and cross-domain responsibilities — weighted toward the components that matter most. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Caution. Cognitive load is concentrated on a handful of high-coupling components. Onboarding and refactor cost is elevated.
What to do
Identify the top complexity contributors and split cross-domain responsibilities. Reducing inbound/outbound coupling on the top three components typically yields the largest gain.
What is this?
How exposed the codebase is to vendor lock-in — the cost the team would pay to switch any single vendor (auth provider, ORM, queue, cache, storage, etc.). Higher means lower switching cost. Maps to ISO 25010 — Portability.
How is it measured?
Identifies the vendors present in the codebase and weighs each by how expensive a migration away would be, concentrated on the most-central components. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Caution. One or more central components are tied to vendors with significant switching costs. Migration would be a multi-quarter project.
What to do
Review the vendor lock-in matrix below; identify the one or two vendors driving the score down. Often a thin abstraction layer (repository pattern, queue interface) lowers switching cost dramatically.
What is this?
How exposed the codebase is to security risk via its most-central components. Greater blast-radius-weighted exposure on auth, public API, and privileged-surface components lowers this score.
How is it measured?
Estimates how much security-sensitive surface — auth, public API, privileged paths — sits on the codebase’s most-central components. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Strong. Security exposure is well-contained on the most-central components.
What to do
Maintain. Continue to keep auth and public-surface components simple and well-tested.
18%
Outage within 30d
45%
Outage within 90d
71%
Outage within 180d
What is this?
How often a single-component failure in this codebase would spread to a system-wide outage. Aura runs many independent failure simulations and reports the share that ended in a system-wide outage.
How is it measured?
Aura simulates thousands of failure scenarios on the codebase dependency graph — each randomly fails components and measures whether the failure spreads system-wide. A confidence range is reported alongside the central estimate. The full methodology — weights, formulas, and detection details — is documented inside your authenticated report.
What does this score mean?
Low outage risk. The vast majority of simulated failures stay contained.
What to do
Add resilience safeguards on the most-central components first — those changes have the largest return per engineering hour.
Discipline
0.61
Change Risk
0.22
Installed
2 / 3
Wired
1 / 3
Next-best toolchain actions
Discipline completeness: 100% · schema v1.1