Frameworks and packs

A framework pack is a small file that maps a regulation’s controls to the record fields that help demonstrate them. Packs do two jobs: they score one record’s coverage on its decision page, and they build the period pack, a signed report over a date range. They never claim compliance.

What a pack contains

Each pack lists controls. A control has an id, a title, the record fields it requires, an optional condition for when it applies (most notice controls apply only to adverse outcomes), a report section, and a gap sentence written for a reader: what is missing and why it matters.

A control is satisfied for a record when every required field is present on that record. Fields are things like “an approval event with an approver and an authority”, “an outcome flagged adverse”, “the record is signed and independently timestamped”, or “the subject is a real business subject, not a raw trace id”.

The six packs

Pack	Covers	Effective
Colorado SB 26-189, automated decision-making technology	Deployer duties for consequential decisions with an adverse outcome: plain-language notice within 30 days, disclosure of the ADMT’s role and inputs, human reconsideration by a reviewer with authority to override	1 January 2027
EU AI Act (Regulation 2024/1689), high-risk deployer obligations	Article 12 automatic logging, Article 14 human oversight, Article 26 deployer duties and six-month log retention, Article 86 right to explanation	2 December 2027
ECOA / Regulation B, adverse action notices	Specific principal reasons for adverse action, timing within 30 days, 25-month record retention (lending)	in force
NAIC Model Bulletin on the use of AI by insurers	Governance documentation, human involvement in adverse determinations, inventory linkage, testing and monitoring evidence	adopting states
ISO/IEC 42001, AI management system	The operational-control, logging, impact-assessment and third-party clauses that records can evidence	standard
NIST AI RMF 1.0	The Govern, Map, Measure and Manage subcategories that require records of decisions, overrides and monitoring	framework

Three of the six (Colorado, ECOA, EU AI Act) also drive affected-person notices, which is why they carry deadlines.

Reading coverage on a decision

Open any decision in the portal. The Framework coverage card lists, per pack, each control that applies to this record and whether the record’s evidence satisfies it. A satisfied control names the fields it found. An unsatisfied one shows the gap sentence, for example:

No human reviewer identity or authority is recorded on adverse decisions.

That sentence is meant to be actionable by an engineer: it says which event field the source should start sending. Over the API the same information is GET /v1/decisions/{id}/coverage.

The period pack

Reports → Period / audit pack takes a date range and a pack. It builds a report over every decision in the window: totals, adverse count, coverage per control with the records that satisfy and miss it, and the gaps ranked by how many records they affect. Download it as a zip containing report.json, report.html, every decision as one line of JSON, the workspace public key, a manifest listing each file’s fingerprint, and the manifest’s signature. It verifies the same way a bundle does: hash the files, check the signature. Evidence outputs.

What a pack cannot tell you

A pack sees records. It cannot see whether your policy was a good one, whether the approver really read the case, or whether your notice reached the person. It reports the existence and shape of evidence. A satisfied control means “the record contains the fields an auditor will ask for”, and nothing more. Treat the coverage number as a to-do list for engineering, not a certificate.

Adding or changing a pack

Packs are YAML files in the backend repository under api/packs/. Adding a control is adding five lines. The maintainers’ page explains where the text ends up.