The governed control library: every framework, every control, and the common controls between them, read through one API.
ControlRegistry is the shared substrate: a superset control library where each framework's controls project from common controls, with graded STRM credit between them. Approve evidence once and the equivalent control is credited across every framework it maps to.
It is served as a governed, versioned asset: the backbone every product inherits. The only way to read the data is the ControlRegistry API.
The same steps for every reader. The last one is what you end up holding.
Screens from the running product, against a demonstration organisation. No customer data appears here.



The artefacts, and who receives each one.
| Feature | Milestone | Scope |
|---|---|---|
| Dark library UI (framework + control wiki) | v1.0 | In MVP v1.0 |
| AC pilot cross-framework maps | v1.0 | In MVP v1.0 |
| Library asset + snapshot pipeline | v1.1 | Planned |
| Live pull-credit UX | v1.1 | Planned |
| The Vault + public API | v2.0 | Planned |
| Governance model (SoD / four-eyes) | v2.0 | Planned |
Milestones are roadmap targets, not shipped dates. Target for MVP v1.0: Live since Aug 2026. The stage above is the honest position today: Live.
What this establishes. These products prepare you for certification and audit. They do not award either. Every figure is derived from what your organisation reports, and is a documented position rather than an independent verification.
Provisioning is white-glove, never self-serve, and scope follows the due diligence review. If you would rather run it inside your own network, say so and we will talk about that too.