Eleven iterations
v0.1 through v1.0.1. Up to v0.9 the work was adding capability. v1.0 stopped, and asked whether the capability could be depended on.
| Version | What it added |
|---|---|
v0.1 | Working field, boundaries, operational tokens, authority commit |
v0.2 | Dynamic goals and versioned documents |
v0.3 | Transactions, faults, adversarial and false-bridge tasks |
v0.4 | Structured candidates, vector clocks, tail risk, stochastic DAGs |
v0.5 | Real subprocess providers, file and SQLite sandboxes, causal DAG, calibration |
v0.6 | Tool contracts, record and strict replay, credit assignment, sequential calibration |
v0.7 | HTTP import, drift detection, approximate credit, regression diff, OCI probe |
v0.8 | CI budget gate, privacy redaction, hierarchical credit, drift decomposition, OCI attestation |
v0.9 | Differential privacy, signed attestation, adaptive baseline, cross-group credit, drift root cause |
v1.0 | Convergence: frozen API, unified certificate envelope, schema registry, migration, release gate |
v1.0.1 | Defect fix: SQLite handle leak, and three ways the gate certified what it never measured |
What v1.0 dropped
v1.0's code is a superset of every earlier version. Its archive is not. The final package left behind nine per-version result reports, the historical summaries and figures for v0.1–v0.9, and the 50-seed fixtures — artifacts that exist only in the older archives.
They are restored in this repository under docs/history/ and history/, and all eleven original archives are kept verbatim under releases/. A superset of the code is not a superset of the record.
A note on counting
v0.8's archive looks like the largest at 358 entries. 127 of those are __pycache__ and .pytest_cache. Its actual content is smaller than v1.0's — which is a reasonable illustration of why this project measures things instead of reading them off a summary.
Verifying a release
The three raw episode ledgers total 134 MB and are not tracked in git; they are kept byte-exact inside the v1.0 archive. scripts/restore_ledgers.py copies them back out and checks each against the digest recorded in SHA256SUMS.txt, after which all 237 files verify.