How Itstabyl calculates your LRS
Itstabyl is not a black box. Every score in your report is broken down by dimension, and every dimension links to the specific files, functions, and patterns that drove it. You see the inputs. You see the evidence. You see the remediation path.
For a non-technical summary: the LRS is a single score (0–100) that combines nine dimensions of software survivability into one number. Higher is more survivable. 80+ means launch ready. Below 60 means fix first.
1. Launch Readiness Score
A weighted combination of the nine dimensions below, normalised to a single auditable number in [0, 100]. Dimensions with higher blast-radius risk carry greater influence on the final score.
80 – 100
Launch Ready
System demonstrates survivability across all nine 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.
The nine dimensions, in ranked order of influence
Architecture and failure containment are the highest-weighted dimensions — they describe how the system holds together and how faults are contained. Knowledge continuity and data survivability carry equal weight in the middle tier. Cognitive load and UX readiness have the smallest influence on the final score, not because they don't matter, but because they're typically downstream symptoms of the higher-tier dimensions.
- 1.
Architectural Soundness
How cleanly the system's structure holds together under change. Layering violations, dependency cycles, and architectural drift drive this down.
- 2.
Failure Containment
How well faults stay local instead of cascading. Circuit breakers, retries, fallbacks, and isolation patterns drive this up.
- 3.
Change Survivability
Whether the codebase can absorb its own evolution — semantic change pressure balanced against the safeguards in place to absorb it.
- 4.
Knowledge Continuity
Bus factor, documentation health, ADR coverage, and onboarding friction. The team-survives-attrition score.
- 5.
Data Survivability
Schema destructiveness and reversibility — how recoverable the data layer is when something goes wrong.
- 6.
Operational Excellence
CI/CD health, observability, infrastructure-as-code, and the gap between installed and enforced tooling.
- 7.
Economic Survivability
Vendor lock-in concentration weighted by where the lock-in lives — fungible commodities are tolerated, single-source critical paths are not.
- 8.
Cognitive Load
How much complexity each high-traffic area imposes on the engineer reading it. High-centrality nodes that are also high-entropy are flagged.
- 9.
UX Readiness
Whether the critical user journeys actually trace end-to-end through the codebase. Broken or partial flows drive this down.
2. Blast radius (centrality)
Each file and function is scored by its blast radius — how far a fault in that node would propagate through the rest of the system. Nodes with many callers, proximity to authentication and authorisation logic, and reachability to data-egress paths receive higher centrality scores.
Every survivability dimension is centrality-weighted. A bug in a high-blast-radius module hurts the LRS more than the same bug in an isolated leaf. This is what distinguishes Itstabyl from traditional code-quality tools that count violations without weighting them by where they live.
3. AI-codebase signal (VCRS)
Codebases where quality tools are installed but not connected to CI pipelines receive a change-survivability penalty. This pattern — sophisticated tooling present in package.json but never invoked by any automated gate — is a strong signal of AI-assisted development with unenforced quality gates.
VCRS is a modifier, not a determinant. It adjusts the change-survivability dimension; it cannot dominate the LRS. Structural problems with the system graph remain the primary driver.
4. Failure-probability simulation
For every assessment, Itstabyl runs 10,000 simulations to estimate the probability of at least one system-level failure within 30, 60, and 90 days. Each simulation seeds a fault somewhere in the system graph and propagates it along the edges, taking into account the safeguards present at each connection.
Failure propagation is modelled based on the safeguards present on each edge. Connections with circuit breakers and fallback patterns propagate dramatically less risk than unprotected ones. The remediation engine uses this to prioritise the changes that would most reduce your simulated failure rate.
Results are reported with a 95% confidence interval. The simulation count is chosen so the confidence band is tight enough to be actionable, never larger than ±1 percentage point at the noisiest part of the distribution.
5. Open calibration
Itstabyl publishes its calibration status openly. Several internal parameters are provisionally set and will be refined after real assessment data is collected. We publish this because honest methodology includes uncertainty — and because we'd rather tell you the model is being refined than pretend it's perfect.
Specific calibration items currently in flight:
- Tooling-enforcement weights (how strongly missing CI hooks penalise change-survivability) — calibrating after 25 assessments.
- Failure-rate baselines per node — calibrating from real post-mortem data on assessed systems.
- Failure-isolation factors per safeguard pattern — validating against MTTR data after 50 assessments.
- Cross-dimension penalties (whether unenforced tooling should also affect failure containment, not only change survivability).
When a parameter is recalibrated, we version the methodology document and publish the change. Existing reports remain immutable under the methodology version they were generated against.
6. Mathematical invariants
Every assessment is governed by a set of mathematical invariants — properties that must hold for the score to be meaningful (weight normalisation, dimension-range constraints, output bounds, and so on). If any invariant fails during computation, the assessment is aborted rather than producing a corrupted result. Itstabyl does not produce partial or estimated scores.
Every dimension score in your report is broken down to the specific files, functions, and patterns that drove it. The methodology is auditable at the assessment level — that's the contract we ship.