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?
Three inputs go into the score: (1) the ten-dimension Resilience Profile, (2) the Outage Forecast — the share of 10,000 simulated failure scenarios that spread to a system-wide outage, and (3) Build & Test Discipline — whether quality tools are installed AND wired into CI. Weights are provisional pending calibration against 100 real assessments; the methodology page documents every constant. Aura commits to 30-day notice before any weight change.
What does this score mean?
Launch With Conditions (60–79). One or more dimensions are below threshold. Address the top remediation actions before go-live; VP Engineering approval is the recommended gate.
What to do
Identify the two weakest dimensions below — those are the highest-leverage remediation targets. A focused 1–2 sprint effort typically moves the score into the Launch Ready band.
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 toolchain artifacts (package.json scripts, CI workflow YAML, pre-commit configs, lint/format/test runner presence). For each tool in the catalogue it determines (a) is the tool installed? and (b) is the tool enforced on every change via CI? Change Risk = (installed but not enforced) ÷ (installed). Bands: DISCIPLINED ≤ 0.20, MODERATE ≤ 0.40, HIGH ≤ 0.60, CRITICAL > 0.60.
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?
Aura discloses calibration status visibly. Provisional outputs are gated on a back-test against 100 real assessments. Once that calibration completes, the provisional badge is removed and a calibrated-as-of date is shown instead. Weight changes require 30-day advance notice and a free re-assessment.
What to do
Use provisional scores to identify the largest resilience gaps (those signals are robust). Defer absolute-threshold gating decisions (e.g., "score ≥ 80 = always launch") until calibration is final.
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
Per-simulation outage rate 4.3%; 95% confidence range [3.8%, 4.9%]. A system-wide outage is defined as more than 30% of components (weighted by blast radius) failing in a single simulated cascade.
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?
Aura's architecture analysis flags every component that fails an architectural rule (anti-patterns, layer violations, missing structural signatures). Architecture quality sums blast-radius weight across every clean component and divides by total blast-radius weight.
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?
Operational maturity is a six-signal composite: CI/CD presence (20%), observability tool (20%), Infrastructure-as-Code (15%), secrets-clean (15%), scale-readiness — e.g. a cache layer (10%), and toolchain enforcement — Build & Test Discipline (20%). Phase 1 limitation: IaC detection awaits a structural-parser integration; secrets-clean defaults to clean until a secrets scanner is wired in. Where these defaults apply, the score is a structural approximation rather than a full computation.
What does this score mean?
Strong. The operational toolchain (CI, observability, scale-readiness) is largely in place.
What to do
Maintain. Add IaC and a secrets scanner if not yet present to take this dimension to a perfect score.
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?
Aura detects four flow segments from the dependency graph: signup-style flow (UI → API → data, weight 40%), checkout-style flow (API → security, weight 35%), auth-recovery (security present, weight 15%), and accessibility (future). Each is binary present/absent. Score = weighted sum. Phase 1 limitation: this measures whether the architectural shape of a flow exists, not whether the flow itself works end-to-end. A backend-only repository will legitimately score 0.
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?
Phase 1 uses architectural-layer diversity as a structural proxy for bus factor — counting how many distinct layers (UI / DATA / SECURITY / INFRA / UNKNOWN) the codebase touches, capped at 5. A future iteration will replace this with a blast-radius-weighted git-blame bus factor, plus documentation-depth and ADR signals. Phase 1 limitation: the score is currently capped at the layer-diversity ceiling. A single-contributor codebase with strong layer diversity can still score moderately here.
What does this score mean?
Strong (Phase 1 ceiling). The codebase covers multiple architectural layers, suggesting structural breadth even before the future git-history measurement.
What to do
Maintain. Once the next iteration ships, your score may rise; ensure ADRs and onboarding docs exist to keep it there.
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?
Phase 1 uses the structural violation ratio: 1 − (components with architectural violations ÷ total components). A future iteration will compute change-impact directly from commit history, weighted by blast radius and the presence of safeguards. A Change-Risk-driven penalty also applies non-linearly — a high Change Risk reduces this score by up to 30%, since unenforced toolchains compound structural risk. Phase 1 limitation: per-commit history is approximated by the static violation ratio.
What does this score mean?
Strong. Structural change risk is low. (Note: a Change-Risk penalty applies if your toolchain is unenforced — see the score adjustments above.)
What to do
Maintain. Watch Change Risk — if it rises, this score is penalised non-linearly even if violations stay low.
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?
Per-component cascade risk = blast-radius weight × outbound-dependency count × a propagation factor. The propagation factor drops by more than half when a job-queue or other safeguard signal is present. Failure containment = 1 − (total cascade risk ÷ worst-case risk). Phase 1 limitation: full safeguard detection (timeout / retry / circuit-breaker code patterns) is approximated; current detection uses vendor signals as a proxy.
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?
Phase 1 measures how much blast-radius weight flows through schema-typed components: a heavily concentrated schema layer reduces the score. A future iteration will replace this with a Data Irreversibility Index computed from migration history (destructiveness × blast radius × (1 − reversibility)). Phase 1 limitation: a repository with no detected schema gets a moderate baseline. The current score does not yet read migration files.
What does this score mean?
Strong. Schema-touching operations are not unduly concentrated on the most-central components.
What to do
Maintain. Once migration-history analysis ships, this score may refine in either direction.
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?
Each component is scored on a complexity index that combines its blast-radius weight, the number of distinct domains it touches, and its inbound + outbound coupling. The dimension is the inverse of the average complexity across the codebase. Higher coupling and cross-domain components drive complexity up and the score down.
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?
Aura detects each vendor present in the codebase (job queue, ORM, identity, cloud SDK, etc.) and consults a switching-cost table calibrated per vendor category. Lock-in = Σ (component blast radius × switching cost of its vendor) ÷ total blast radius. The dimension reports 1 − lock-in. Vendor categories with abundant alternatives (email, build tooling, CI) carry low switching cost; categories with deep coupling (job-queue, ORM, headless CMS) carry high switching cost.
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?
Each component receives an exposure score based on file-path signals (api routes, auth-privileged paths, public surfaces). The dimension is the inverse of the total blast-radius-weighted exposure across the codebase, normalised to a 0–1 scale. Phase 1 limitation: exposure detection is path-heuristic; future iterations will augment with dependency vulnerability surface (CVE feed) and runtime privilege analysis.
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
A system-wide outage is defined as more than 30% of components failing in a single simulated cascade.
What is this?
How often a single-component failure in this codebase would spread to a system-wide outage. Aura runs 10,000 independent simulations: each randomly fails some parts of the codebase, then asks whether the failure spread beyond a system-wide threshold. The reported number is the fraction of simulations that ended in a system-wide outage.
How is it measured?
Inputs: the codebase dependency graph, blast-radius weights for each component, and a failure-propagation factor inferred from the safeguards present in the code (timeouts, retries, circuit breakers, job queues). A 95% statistical confidence range is reported alongside the central estimate. The 30/90/180-day projections extrapolate the per-simulation rate forward in time.
What does this score mean?
Low outage risk. The vast majority of simulated failures stay contained. Failure containment is working as designed.
What to do
Maintain current resilience patterns. Continue to add safeguards as new high-blast-radius components are introduced.
Discipline
0.61
Change Risk
0.22
Installed
2 / 3
Wired
1 / 3
Next-best toolchain actions
Discipline completeness: 100% · schema v1.1