How Aura calculates your LRS
Aura is not a black box. Every formula, every constant, and every mathematical invariant is documented here and independently verifiable. If you can find an error in the methodology, we want to know.
For a non-technical summary: the LRS is a single score (0–100) that combines 9 dimensions of software survivability into one number. Higher is more survivable. 80+ means launch ready. Below 60 means fix first.
1. Launch Readiness Score (LRS)
The headline metric. A single auditable number in [0, 100].
// LRS formula
LRS = 100 × Σᵢ [ wᵢ × Sᵢ ]
// Constraint enforced as runtime invariant: Σ wᵢ = 1.000
80 – 100
Launch Ready
System demonstrates survivability across all 9 dimensions. Proceed.
60 – 79
Launch with Conditions
One or more dimensions below threshold. Address top-3 remediation actions before go-live.
0 – 59
Do Not Launch
Critical survivability gaps detected. Launch risk is quantified and material. Fix first.
Weight vector — authoritative (Σ = 1.000)
| Dimension | Plain English | Weight | +1 LRS pt requires |
|---|---|---|---|
| S_arc | Architectural Soundness CCR-weighted violation count | 0.18 | +0.6 pts in S_arc |
| S_fail | Failure Containment CCR × FPC blast radius | 0.18 | +0.6 pts in S_fail |
| S_change | Change Survivability Semantic change magnitude × safeguard presence | 0.15 | +0.7 pts in S_change |
| S_k | Knowledge Continuity Bus factor, docs, ADRs, setup score | 0.12 | +0.8 pts in S_k |
| S_data | Data Survivability DII — schema destructiveness × reversibility | 0.12 | +0.8 pts in S_data |
| S_ops | Operational Excellence CI/CD, observability, IaC, SDA toolchain score | 0.10 | +1.0 pts in S_ops |
| S_econ | Economic Survivability CCR-weighted vendor lock-in index | 0.08 | +1.3 pts in S_econ |
| S_cog | Cognitive Load Shannon entropy × CCR per node | 0.04 | +2.5 pts in S_cog |
| S_ux | UX Readiness CPG-traceable critical user flow completeness | 0.03 | +3.3 pts in S_ux |
S_arc and S_fail have identical marginal return (1.8 LRS pts per 0.10 improvement). Always address architectural violations and failure containment gaps first.
2. Codebase Centrality Rank (CCR)
CCR is a PageRank variant over the Unified System Graph G = (V, E). It models the blast radius of each node — the probability that a fault in that node propagates through the system. All 9 survivability dimensions are CCR-weighted.
// CCR power iteration (PageRank variant)
CCR[i] = (1 − d) / N + d × Σⱼ ( CCR[j] / outDegree_ε(j) )
d = 0.85 (damping factor — standard Brin & Page value)
ε_floor = 0.0001 (prevents zero-division on sink nodes)
Convergence: ‖CCR⁽ᵏ⁾ − CCR*‖ ≤ 0.85ᵏ × ‖CCR⁽⁰⁾ − CCR*‖
// Worst-case: 59 iterations. Practical: 20–50.
Convergence proof: The transition matrix T is irreducible (teleportation term (1−d)/N > 0), aperiodic (self-loops from teleportation), and row-stochastic. By the Perron-Frobenius theorem, there is a unique dominant eigenvalue λ₁ = 1 with a unique stationary eigenvector. Power iteration converges to it.
3. Vibe Coding Risk Score (VCRS)
VCRS detects AI-generated codebases from static repository analysis by measuring the gap between installed tooling and enforced tooling. A codebase with tools installed but not wired into CI signals LLM-assisted development with unenforced quality gates.
// VCRS formula
VCRS = (installed_count − wired_count) / max(installed_count, 1)
// VCRS → S_change penalty (β = 0.30)
S_change_adjusted = S_change × (1 − 0.30 × VCRS)
// Maximum penalty: 30% reduction at VCRS = 1.0
// β < 1.0: VCRS is a modifier, not a determinant
Why β = 0.30 and not higher: S_change is a structural metric (graph topology). VCRS is a process metric (enforcement discipline). They are related but independent. The β-cap ensures VCRS cannot dominate the LRS — it adjusts, it does not override.
4. Monte Carlo Failure Probability
The pipeline runs 10,000 Monte Carlo simulations to compute P(system failure in T days). Each simulation seeds a failure at a node weighted by CCR and local failure risk, then propagates it through the graph via the FPC (Failure Propagation Coefficient) on each edge.
// Failure seeding
P(seed = v) ∝ (1 − S_fail_local[v]) × CCR[v]
// System failure threshold
system_failure = (Σ_failed CCR[v]) > 0.30
// Time-horizon Poisson model
P(≥1 failure in T days) = 1 − e^{−λ_eff × T/30}
// Confidence interval (Wilson score, 95%, N=10,000)
max CI half-width at p̂=0.5: ±0.98%
FPC 1.00
No safeguard
FPC 0.50
Timeout only
FPC 0.20
Timeout + retry + backoff
FPC 0.05
Circuit breaker + fallback
5. Authoritative Constants
Every constant is derived, not arbitrary. Sources cited.
| Constant | Value | Derivation |
|---|---|---|
| CCR damping factor d | 0.85 | Standard PageRank (Brin & Page 1998) |
| CCR convergence ε | 0.0001 | Geometric: 0.85^58 < 0.0001 → max 59 iterations |
| Monte Carlo iterations N | 10,000 | CLT: max CI half-width ≤ ±1% at N=10k (Wilson score) |
| Cascade failure threshold | 30% CCR mass | System-level failure defined as ≥30% of CCR mass failing |
| λ default (failure rate) | 0.10 / node / month | Provisional — calibrate after 100 assessments (VAR-010) |
| FPC (no safeguard) | 1.00 | Full propagation — no circuit breaker or fallback |
| FPC (circuit breaker + fallback) | 0.05 | Netflix Chaos Engineering empirical baseline |
| VCRS β-factor | 0.30 | Process modifier cap: β << 1 preserves structural primacy |
| SDA α (installation weight) | 0.30 | Expected value of manually-run tools ≈ 20–24%; floor at 30% |
| Bus factor saturation | 5 engineers | g(b) = min(b/5, 1.0) — enterprise-grade saturation point |
6. Runtime Invariants
These are enforced in workers/pipeline/constants.ts before every LRS computation. If any invariant fails, the assessment is aborted. An LRS computed from a broken invariant is not an Aura LRS.
INV-M1Σ w_i = 1.000 — LRS weights sum to exactly 1
INV-M2Σ CCR[i] = 1.000 ± ε — CCR normalised after convergence
INV-M3All S_i ∈ [0, 1]
INV-M4LRS ∈ [0, 100]
INV-M5CCR[i] > 0 for all i — Perron-Frobenius + teleportation guarantee
INV-M6SDA ∈ [0, 1]
INV-M7VCRS ∈ [0, 1]
INV-M8S_change_adjusted ≤ S_change — VCRS can only reduce, never increase S_change
INV-M9Σ w̃_i = 1.000 — SDA normalised weights
7. Open Calibration Questions
We publish these because honest methodology includes uncertainty. These constants are provisionally set and will be updated after real assessment data.
Is α = 0.30 correct?expand
Expected value of manually-run tools empirically ≈ 20–24%. The 0.30 floor may be conservative. Calibrate after 25 assessments.
Is β = 0.30 correct?expand
Does VCRS correlate with S_change post-incident? Requires 50 assessments + incident tracking to validate.
Is λ_default = 0.10 calibrated?expand
All P(failure) estimates derive from this. Requires real post-mortem data from assessed systems.
Do FPC values match empirical failure isolation?expand
The 1.0 → 0.5 → 0.2 → 0.05 scale reflects engineering judgment. MTTR correlation analysis after 50 assessments will validate.
Should VCRS also penalise S_fail?expand
A codebase with unenforced tooling likely also has poorer resilience patterns. Currently only S_change is adjusted — this may understate S_fail risk.
Full mathematical specification: AURA/10_AURA_MATHEMATICS.md (v1.1, May 2026). This document is the single source of truth. Any conflict between this page and prose descriptions elsewhere should be resolved in favour of the mathematical spec.