How the KeyScore works: the math behind a verified-asset score

The KeyScore is the single number that drives every downstream engine in Keystone. Pool ratings read it. Disbursement eligibility reads it. Insurance pricing reads it. The Modular Index aggregates it. It's the verified-asset equivalent of a credit score — a compressed signal that captures everything relevant about a module's quality, provenance, and resilience. Here's exactly how it's computed.

What the KeyScore is, and what it isn't

The KeyScore is a number between 0 and 99 computed at the module level. It's deterministic — the same module record produces the same KeyScore every time. It's not a probability, not a credit grade, not a market-clearing price. It's a structural quality signal that downstream engines convert into their own outputs.

Specifically: the lender's pool-rating engine converts weighted KeyScores into AAA/AA/A/BBB/NR letter ratings. The disbursement engine uses KeyScore thresholds to gate milestone-tied releases. The insurance engine uses KeyScore as one of three inputs (alongside seismic class and net-zero status) into the rate-bps pricing function. The index engine aggregates KeyScores into the EVBHI / Modular Index average.

The base score

Every registered module starts with a base score of 40. That's a deliberately low floor — the baseline reflects the fact that the module exists and has provenance, but no other quality signals have been verified yet. Modules that don't progress past the base get filtered out at the eligibility gates (pool ≥65, IG ≥72, AAA ≥90).

The additive components

Six weighted adjustments are added to the base, each tied to a verified data point in the module passport:

• Weld inspection passed — +12 points. Verified third-party weld inspection record at the structural-shell stage.
• Third-party QA inspection — +10 points. Independent inspection beyond the manufacturer's own QA cycle.
• Net-zero certified production — +8 points. Production-side net-zero certification (not just intent).
• Seismic class A — +12 points. Engineering classification A on the seismic resistance schedule. Class B adds +6, class C adds +2, class D adds 0.
• Embodied carbon below threshold — +6 points. Verified embodied carbon below the program-defined threshold.
• Value state advancement — up to +12 points across the lifecycle. Certified +3, completed +5, in-structure +4.

The total possible additive is 60, on top of the base 40 — for a maximum theoretical KeyScore of 100. The score caps at 99 (no module is "perfect"; the design language reserves 100 for a future calibration).

How the scoring runs

The scoring function lives in the database. It's a Postgres function (keystone_keyscore()) executed by a trigger on every INSERT or UPDATE of the module record. That has three important properties:

• Deterministic — same inputs, same output, always. No client-side calculation, no model drift.
• Auditable — the function's SQL definition is part of the schema. Any subscriber can verify that their score was computed against the same function every other subscriber's score was.
• Trigger-driven — the score updates automatically when any input changes. A module that advances from "certified" to "completed" sees its KeyScore recompute at the moment of state transition.

What's deliberately not in the KeyScore

The KeyScore intentionally doesn't include:

• Manufacturer-of-origin discount or premium — the score doesn't favor or penalize specific manufacturers. The same input data produces the same output regardless of who produced the module.
• Geographic adjustments — location-specific risk lives in downstream engines (the insurance rate function applies a location loading; the disbursement engine references program jurisdiction). Folding it into the KeyScore would conflate asset quality with asset placement.
• Lifecycle-time decay — a module's KeyScore doesn't deteriorate over time. A 5-year-old in-service module with no quality issues should still read as high-quality. Decay would conflate quality with vintage.
• Synthetic adjustments based on model output — no ML model layer, no opaque correction. Every additive component is a verifiable data point on the passport.

The principle: the KeyScore captures verified, current, asset-level quality. Anything else — geographic, vintage, modeled — gets handled by the engine that consumes the KeyScore, not in the KeyScore itself.

How downstream engines use it

Once the KeyScore exists, the downstream usage is straightforward:

• Capital Rail — KeyScore ≥65 = eligible to enter a pool. The pool's weighted KeyScore (weighted by collateral value) drives the AAA→NR letter rating: ≥90 AAA, 85-89 AA, 80-84 A, 72-79 BBB, <72 NR. Gain-on-sale + servicing revenue triggers above BBB.
• Disbursement Rail — KeyScore is one input. The primary gate is state (certified / completed / installed) matching the requested milestone. KeyScore additionally guards against releasing program funds against modules below the program's quality floor.
• Insurance Rail — KeyScore is one of three inputs to the rate-bps function. Higher KeyScore = lower premium. The pricing math is published; any MGA can validate the formula.
• Modular Index — KeyScore aggregates into the industry average. Investment-grade share, average KeyScore, and resilience-mix breakdowns all derive from the KeyScore distribution.

Why this design, and not a more sophisticated model

The KeyScore is intentionally simple. A more sophisticated model — gradient-boosted trees on historical loss data, deep learning on inspection imagery, multi-factor adversarial calibration — could in principle produce a better-fit per-module signal. We didn't build one. Three reasons:

• Auditability. Every lender, insurer, regulator, and inspector general can read the KeyScore formula and verify that their input data produces their output score. A ML model would require model-card disclosure, calibration audits, and ongoing drift monitoring. The simple sum-of-components is defensible without any of that.
• Industry standardization. The point of the KeyScore is to give everyone in the financing stack the same signal. A simple, public formula is the fastest path to that. A proprietary ML model would invite parallel competing models and re-fragment the signal layer.
• Cold-start economics. A ML model needs loss-experience data to train. That data doesn't exist for modular at the scale required. The simple formula works at low data volumes and gets refined as the industry's loss experience matures.

How the KeyScore evolves

The current formula is v1. Future calibration is expected as the underlying loss + performance data accumulates. Specifically:

• Weighting between the additive components will get re-calibrated against actual lifecycle performance data once the registry has 12-18 months of operational history.
• Additional verified data points (sensor-instrumented production line data, parametric environmental telemetry, second-life-condition signals) may be added as registry sources expand.
• Every KeyScore formula version is recorded against the module record, so backward-comparable scoring is preserved for audit and contract purposes.

The formula version is part of the module's metadata. Any downstream contract that references KeyScore can lock to a specific formula version for contractual predictability.

Verifying for yourself

The live demo exposes the KeyScore for each module in the sample workspace. You can see the additive components, the base score, and the computed total — and verify the math by hand if you want. Open the demo → and pick any battery in the Registry tab to see its full passport with the KeyScore breakdown.

The KeyScore is deliberately simple. Auditable, deterministic, shared. That's the design constraint that makes a verified- asset rail possible across five revenue engines and five buyer cohorts at once.