Unified Framework Registry — 14 frameworks, one canonical source

What changed

The Unified Framework Registry (RFC-027) lands as a shared Go module that defines every compliance framework vCISO Lite supports: SOC 2, ISO 27001, PCI DSS, HIPAA, NIST CSF, GDPR, FedRAMP, CIS Controls, and the rest of the fourteen, with canonical IDs, display metadata, and alias resolution. Every service now imports from the same registry instead of maintaining its own hardcoded framework map.

Canonical IDs

One ID per framework (soc2, iso27001, nistcsf, and the rest of the fourteen) that every service in the platform uses. No more debates in code review over SOC2 vs soc_2 vs SOC 2.

Alias resolution

The registry accepts any known alias (case-insensitive, punctuation-tolerant, common misspellings) and returns the canonical framework. Data imported from customer spreadsheets, CSV uploads, and legacy integrations resolves cleanly without a normalization pass every service has to write on its own.

Codegen parity

A codegen script produces a TypeScript equivalent from the Go source, so the frontend uses the same registry as the backend. Adding a framework or updating display metadata is a one-file change that propagates everywhere.

Migration

Every scattered framework map, normalizer function, and pattern-matching block that used to live inside a service is gone. The registry is the source of truth.

Why it matters

Every subsequent product improvement that touches a framework (adding a control, mapping a policy to a requirement, generating a compliance report, wiring evidence to an audit cycle) inherits the Registry. What used to be a stealth cost every service paid on every framework change is now a single Go type.

And when the framework list grows in a future release, the growth is a data change, not a code change.

Availability

Already live across the platform. Every service imports from the registry today, and the frontend consumes the Go-to-TypeScript codegen output on the same build.

The frameworks surfaced on /features/compliance are the same list the registry publishes to every service. Framework additions and display-metadata changes are a one-file edit in the Go source; the codegen propagates to TypeScript on the next build, and no service has to be touched to pick them up.

Known limitations

The codegen flows one direction, Go to TypeScript. A frontend-only framework addition isn't possible; new entries land in the Go registry first and propagate to the frontend on the next build.

Alias resolution covers known aliases. A genuinely novel misspelling or an alias the registry hasn't yet seen falls through to the canonical-lookup failure path and surfaces as an unresolved framework rather than being guessed.