Engineering transparency
The register comes from the platform.
Every production service, its verification state and its test coverage are published from the same capability source the engineering team uses.
Capability register
Verification built into the release path.
The register is generated from the platform itself, so public engineering state cannot drift from the operating system.
| Capability | Measure | Verification | State |
|---|---|---|---|
| Production services | 168 services | Included in the capability register | Production |
| Automated test suite | 5,447 tests | Enforced on every change | Active |
| Test coverage | 100 percent | Release-path enforcement | Enforced |
| Program surface | Six programs | One shared record, consent and audit layer | Full products |
| Clinical classification | Published deterministic criteria | Rule and threshold traceability | Implemented |
| Disclosure audit | SHA-256 hash chain | Append-only, write-once anchoring | Implemented |
| Post-quantum cryptography | NIST FIPS 203 / 204 | Hybrid ML-KEM and ML-DSA | Migration underway |
One source of truth
The website and product read from the same source.
Service state, verification and test coverage are generated from the platform capability register.
That direct relationship is what keeps the public page aligned with the code.
Institutional diligence
Inspect the artifact behind the state.
Each service carries a verification state, test coverage and a named engineering owner, giving diligence teams a direct path from public claim to technical evidence.
Institutional diligence