# The Safety Framework Publication Format

**Version 0.1 · September 9, 2026 · CC0 1.0 (public domain)**
**Maintained by Major Labs as part of Threshold Watch**

---

## 1. Purpose

Every frontier AI lab publishes a safety framework. As of September 2026, Threshold Watch tracks six of them, and zero publish a version history a third party can verify. Two cannot be reliably retrieved by automated tooling at all. The result is that the most important commitments in the industry live in documents nobody else can diff: a threshold can be softened, an evaluation gate reworded, a deployment condition relaxed, and the only record is the lab's own announcement, if it chooses to make one.

This specification defines a publication format that closes that gap. It has three parts: a machine-readable representation of a safety framework's commitments, a changelog format for recording how those commitments change, and publishing requirements that make both independently verifiable. A lab that adopts it does not change a single policy decision. It changes only how its existing decisions are published: as structured, diffable, hash-anchored data instead of prose in a PDF.

The format implements commitment one of the Control Stack Compact (published capability thresholds with verifiable changelogs). The Compact states the principle, the Compact Clauses put it in contract language, this specification gives it a wire format, and Threshold Watch monitors who meets it. Adoption is deliberately cheap: for a lab that already maintains its framework, producing the structured edition is an afternoon of work by someone who knows the document.

## 2. Non-goals

This specification is a format, not a policy position. Explicitly out of scope:

- It does not recommend what any threshold, gate, or safeguard should be.
- It is not a safety standard, and conformance says nothing about whether a framework is adequate. A weak framework published verifiably is still a weak framework; it is merely a weak framework whose weakening can no longer be silent.
- It does not certify labs. Conformance levels describe publication practice only.
- It does not replace the prose framework. The structured edition is published alongside the canonical document and defers to it in any conflict, provided the conflict is disclosed in the next changelog entry.

## 3. The framework document format

A conforming framework document is a single JSON document validating against `schema/safety-framework.schema.json`. Top-level structure:

| Field | Contents |
|---|---|
| `spec_version` | The version of this specification the document conforms to (`"0.1"`). |
| `metadata` | Lab, document title, framework version, effective date, canonical prose URL, SHA-256 of the prose document as retrieved, retrieval date. |
| `capability_thresholds` | The capability levels that trigger obligations: id, name, domain, definition, what crossing it triggers, how it is measured. |
| `evaluation_gates` | The evaluations that decide whether a threshold is crossed: cadence, method, which thresholds each gate covers. |
| `deployment_conditions` | Requirements that attach to deployment at a given threshold (safeguard standards, access restrictions). |
| `escalation_commitments` | What the lab has committed to do when things cross lines: reporting, review, oversight bodies, pause rights. |
| `change_policy` | How the framework itself changes: where changes are logged, in what format, who is notified. |
| `unmapped_sections` | An honesty valve: prose content the format cannot yet represent, listed rather than dropped. |

Every threshold, gate, condition, and commitment carries a stable `id`, so a changelog entry can name exactly what changed, and an optional `source_excerpt` quoting the prose it was derived from.

## 4. The changelog format

A conforming changelog is a JSON document validating against `schema/changelog.schema.json`: an append-only list of entries, each recording the date, the version transition (`version_from` → `version_to`), the SHA-256 of the document before and after, the sections changed by stable id, a change type per section, and a rationale.

Change types are a closed set: `strengthened`, `weakened`, `clarified`, `added`, `removed`. The set is deliberately blunt. A lab that must label its own edit `weakened` in a machine-readable field, anchored to before-and-after hashes, is making the one disclosure that today's announcement-style release notes never quite make.

## 5. Publishing requirements

A conforming publication meets all of the following:

1. **Stable canonical URL.** The prose framework and the structured edition each live at a stable URL that does not change between versions.
2. **Automated retrieval permitted.** The URLs return the document to standard HTTP tooling. A framework whose canonical document blocks automated retrieval fails this requirement; as of September 2026 this is not hypothetical.
3. **Versioned.** Every change increments a version identifier carried in both editions.
4. **Hash-anchored.** The structured edition records the SHA-256 of the prose document it corresponds to; each changelog entry records the hashes on both sides of the change.
5. **Changelogged.** Every change to the framework, including wording changes, produces a changelog entry before or at the moment the new version is canonical.

## 6. Conformance levels

Levels are cumulative and map one-to-one onto the Threshold Watch scoreboard columns, so the scoreboard doubles as a public conformance report:

| Level | Name | Requirement | Scoreboard column |
|---|---|---|---|
| **L0** | Published | A public safety framework exists. | Publishes a framework |
| **L1** | Fetchable | Stable canonical URL, automated retrieval permitted, hashable. | Machine-fetchable |
| **L2** | Structured | A structured edition conforming to the framework schema is published alongside the prose, versioned in step with it. | Versioned |
| **L3** | Changelogged | A conforming changelog covers every change, hash-anchored to before and after. | Verifiable changelog |

As of September 9, 2026: six labs at L0, four at L1, zero at L2 or L3.

## 7. Relationship to the Compact and Threshold Watch

The Control Stack Compact's first commitment asks labs to publish capability thresholds with changelogs a third party can verify. This specification is that commitment made concrete, and Threshold Watch is its measurement: dated, hashed snapshots of each lab's framework, archived on change, with fetch failures shown as findings. A lab at L3 makes Threshold Watch's snapshotting redundant for its documents. That is the goal. The tracker exists to be made unnecessary.

## 8. Versioning of this specification

This specification is itself published under its own rules: versioned, changelogged in its repository history, and hash-anchored by git. Breaking schema changes increment the minor version before 1.0. Feedback and adoption reports: via the repository issue tracker.

## 9. License

CC0 1.0 Universal. No rights reserved. Adopt it, fork it, put it in a procurement rider; attribution is appreciated and not required.