OpenCoven · BunsDev · Jul 26, 2026 · Jul 26, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -7,6 +7,27 @@ This project uses [Semantic Versioning](https://semver.org/).
 
 ---
 
+## [0.6.0] — 2026-07-26
+
+Draft minor under the **v0.5.0** §6.3 rule: additive normative conformance changes (new MUSTs on previously implementation-defined hash fields; a new audit-record lane in the reference conformance suite). Closes the A-6 residual from the v0.3.0 provenance review. Design basis: `docs/superpowers/specs/2026-07-22-hash-canonicalization-design.md` (bead `threads-5vn`).
+
+### Added
+
+- **RFC-0001 §5.6.1** — Hash algorithms and canonical encodings for the audit log's hash-bearing fields: structural commitments (`ward_hash`, multi-field/Merkle commitments) use BLAKE3 with domain-tagged, length-prefixed framing; content fingerprints (`diff_hash`, `entry_hash`) use SHA-256 over exactly specified input bytes; textual encodings are 64-character lowercase bare hex (prefixed forms prohibited) with an explicit `"blake3"`/`"sha256"` discriminator where a field's definition does not fix the algorithm. Implementations **MUST** reject attestations naming unsupported algorithms (never skip verification), **MUST** be able to recompute every recorded hash from the audit log and referenced surface bytes regardless of writing implementation, and **MUST** treat recomputation mismatches as tamper evidence.
+- **schemas/audit-record.schema.json** — Machine-readable form of the §5.6/§5.6.1 audit-record field constraints for textual (JSON) encodings.
+- **tests/conformance/audit-records/** — New conformance lane (4 positive, 7 negative single-record fixtures) checked by `validators/check-audit-records.js` under the same `npm test` entry point; positive fixtures carry worked test vectors — SHA-256 vectors verified by recomputation from companion byte files, and the BLAKE3 empty-weave reference vector `blake3("coven-threads:empty:v1")` computed from the reference construction.
+- **validators/validate.js** — Optional claimant-directory audit-record samples: `audit/*.json` validates against the schema when present; absence of `audit/` is not a violation, a present-but-empty `audit/` fails closed. Covered by fixtures `positive/07-audit-record-samples` (worked provenance chain whose SHA-256 vectors recompute from the fixture's own `MEMORY.md` bytes), `negative/37-bad-entry-hash`, and `negative/38-empty-audit-dir`.
+- **RFC-0001 §8.2 / §9** — Failure mode and testing-gap bullets for runtime hash obligations: recomputation-as-tamper-evidence, fail-closed unsupported-algorithm rejection, and cross-implementation `ward_hash` verification are runtime properties beyond the file-level suite.
+- **rfcs/RFC-0001-v0.5.md** — Historical snapshot of the final v0.5.x text (exact copy of tag `v0.5.0`).
+
+### Changed
+
+- **Migration impact:** none for the reference implementation (`coven-threads-core` and the `coven` daemon) — §5.6.1 codifies its deployed practice, grandfathering existing domain-tagged constructions (their `:v<N>` tags are their version). Other implementations of §5.6 must verify their hash fields recompute under the now-normative definitions. No claimant-directory changes are required; directories without `audit/` samples are unaffected. Consumers pinning v0.5.0 are unaffected.
+- **Security rationale:** unspecified hash constructions made provenance chains verifiable only by their writer — a foreign implementation or auditor had to trust, not verify, exactly where §5.6 exists to remove trust. Fixed constructions make tampering detectable across implementations; fail-closed algorithm handling prevents downgrade-by-unknown-algorithm; domain tags with length-prefix framing prevent cross-context collision and forgeable delimiter framing.
+- **README.md, PRIMER.md, SPEC.md, rfcs/README.md, docs/faq.md, tests/conformance/README.md, validators/README.md, validators/validate.js, schemas/ward.schema.json (description string), package.json** — Updated current-version references to v0.6.0.
+
+---
+
 ## [0.5.0] — 2026-07-24
 
 Draft minor, classified under the **v0.4.1** §6.3 rule per the incoming §6.3.1 freeze: one additive normative change, shipped alone. No directory-level conformance requirements change.

diff --git a/PRIMER.md b/PRIMER.md
@@ -94,7 +94,7 @@ You do not need to use OpenCoven's infrastructure to implement familiar-contract
 
 ## Where to go next
 
-- [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative specification (v0.5.0)
+- [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative specification (v0.6.0)
 - [`examples/minimal/`](examples/minimal/) — the minimal structurally conformant familiar directory (Lumen)
 - [`examples/sage/`](examples/sage/) — a richer structurally conformant familiar directory (Sage)
 - `node validators/validate.js ./your-directory` — validate your claimant directory

diff --git a/README.md b/README.md
@@ -2,7 +2,7 @@
 
 > **The Familiar Contract is an open specification for what an agent is allowed to be — not just what it can do, but what it cannot change about itself.**
 
-[![specification: v0.5.0](https://img.shields.io/badge/specification-v0.5.0-8b5cf6)](rfcs/RFC-0001-familiar-contract.md)
+[![specification: v0.6.0](https://img.shields.io/badge/specification-v0.6.0-8b5cf6)](rfcs/RFC-0001-familiar-contract.md)
 [![RFC-0001: Draft](https://img.shields.io/badge/RFC--0001-Draft-blue)](rfcs/RFC-0001-familiar-contract.md)
 [![license: MIT](https://img.shields.io/badge/license-MIT-green)](LICENSE)
 [![Ask DeepWiki](https://deepwiki.com/badge.svg)](https://deepwiki.com/OpenCoven/familiar-contract)
@@ -40,11 +40,11 @@ These are not soft design preferences. Each one has architectural implications,
 ## How to Use This Spec
 
 **If you're building a familiar:**
-1. Read [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative spec (v0.5.0)
+1. Read [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative spec (v0.6.0)
 2. Copy an example from [`examples/`](examples/) — `minimal/` for the floor, `sage/` for a richer structurally conformant familiar directory
 3. Create `SOUL.md`, `IDENTITY.md`, `MEMORY.md`, and `ward.toml` for your familiar
 4. Run `npm install` to install the reference validator's TOML parser and JSON Schema validator.
-5. For a v0.5.0 structural-conformance claim, run both `node validators/validate.js ./your-directory` and `npm test`
+5. For a v0.6.0 structural-conformance claim, run both `node validators/validate.js ./your-directory` and `npm test`
 
 **If you're evaluating a familiar:**
 - Five properties. All five. Fewer than five is an agent, not a familiar.
@@ -62,10 +62,10 @@ These are not soft design preferences. Each one has architectural implications,
 # Install the reference validator dependencies
 npm install
 
-# Validate the claimant directory for your v0.5.0 claim
+# Validate the claimant directory for your v0.6.0 claim
 node validators/validate.js ./your-directory
 
-# Verify the bundled reference validator + fixtures for the same v0.5.0 claim
+# Verify the bundled reference validator + fixtures for the same v0.6.0 claim
 npm test
 ```
 
@@ -88,7 +88,7 @@ See [`validators/README.md`](validators/README.md) for full CLI docs.
 ## Repository Contents
 
 ```
-rfcs/RFC-0001-familiar-contract.md ← The Familiar Contract (normative, v0.5.0)
+rfcs/RFC-0001-familiar-contract.md ← The Familiar Contract (normative, v0.6.0)
 README.md                ← This file
 PRIMER.md                ← Builder's guide (for new readers)
 CHANGELOG.md             ← Version history

diff --git a/SPEC.md b/SPEC.md
@@ -2,7 +2,7 @@
 
 > **Status:** Historical / superseded · **License:** MIT · **Version:** 0.1.0
 >
-> ⚠️ **This document is preserved for reproducibility.** The current normative specification is [RFC-0001 v0.5.0](rfcs/RFC-0001-familiar-contract.md), which uses RFC 2119 keywords (MUST/SHOULD/MAY), references the conformance suite at [`tests/conformance/`](tests/conformance/), and hardens the authority-layer separation requirement.
+> ⚠️ **This document is preserved for reproducibility.** The current normative specification is [RFC-0001 v0.6.0](rfcs/RFC-0001-familiar-contract.md), which uses RFC 2119 keywords (MUST/SHOULD/MAY), references the conformance suite at [`tests/conformance/`](tests/conformance/), and hardens the authority-layer separation requirement.
 >
 > If you are looking for the current spec, go to [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md). This file remains for historical and citation purposes.
 

diff --git a/docs/faq.md b/docs/faq.md
@@ -12,7 +12,7 @@ The core problem it addresses is this: AI agents have gotten very capable, but t
 
 The specification has two major parts. First, a five-property identity contract: a compliant "familiar" must have a stable named identity, a declared purpose, enforced authority limits, persistent memory, and an explicit binding to a specific person. Second, an enforcement model built around a component called the Ward — a TOML policy document plus a runtime enforcement daemon that checks proposed changes against the protected surface before they are applied. The key word is "enforced": the Ward is not asking the agent to have good values about self-modification. It is an external check that runs regardless of what the agent thinks about it.
 
-The Familiar Contract is a normative specification, which means it defines what must be true about a conformant system, tested against both a claimant-directory validator run and an executable conformance suite, not just described. The RFC (RFC-0001, v0.5.0) carries formal RFC 2119 keywords (MUST, MUST NOT, SHOULD) and the `tests/conformance/` directory is the fixture suite that verifies the reference validator. A familiar directory is structurally conformant only when `node validators/validate.js ./your-directory` succeeds and `bash tests/conformance/run-conformance.sh` passes in the repository. Full conformance also requires runtime Ward enforcement as described in RFC §6.2.
+The Familiar Contract is a normative specification, which means it defines what must be true about a conformant system, tested against both a claimant-directory validator run and an executable conformance suite, not just described. The RFC (RFC-0001, v0.6.0) carries formal RFC 2119 keywords (MUST, MUST NOT, SHOULD) and the `tests/conformance/` directory is the fixture suite that verifies the reference validator. A familiar directory is structurally conformant only when `node validators/validate.js ./your-directory` succeeds and `bash tests/conformance/run-conformance.sh` passes in the repository. Full conformance also requires runtime Ward enforcement as described in RFC §6.2.
 
 ---
 
@@ -278,7 +278,7 @@ The RFC also does not address security of the authority layer itself. If the War
 What you need is: a familiar directory with the required files (`SOUL.md`, `IDENTITY.md`, `MEMORY.md`, `ward.toml`); a `ward.toml` that conforms to the published schema; and an enforcement mechanism — a Ward authority daemon — that is structurally separate from the familiar's own logic. The reference implementation uses a Rust authority daemon (the `coven` layer), but the RFC is explicit that "other implementations may choose different mechanisms; what is normative is the separation, not the implementation."
 The structural conformance suite (`tests/conformance/`) has no Coven dependencies, but it does not by itself validate an arbitrary external directory. It verifies that the bundled reference validator accepts the positive fixtures and rejects the negative fixtures. Your own familiar directory still needs its own `node validators/validate.js ./your-directory` run. The reference validator requires Node.js plus `npm install`; its dependencies are a standards-compliant TOML parser and JSON Schema validator. The schemas (`schemas/`) are standard JSON Schema and can be validated with any conforming schema validator.
 
-The parts of the spec that are Coven-specific — Doll proposals, Cave Board integration, multi-familiar routing — are referenced as context, not as requirements. A standalone familiar implementing a Ward daemon without any Coven infrastructure can be fully conformant with RFC-0001 v0.5.0.
+The parts of the spec that are Coven-specific — Doll proposals, Cave Board integration, multi-familiar routing — are referenced as context, not as requirements. A standalone familiar implementing a Ward daemon without any Coven infrastructure can be fully conformant with RFC-0001 v0.6.0.
 
 ---
 
@@ -292,6 +292,6 @@ If you want to understand how the Familiar Contract relates to other agent speci
 
 If you want to build a conformant familiar, start with `ward.toml` (conforming to `schemas/ward.schema.json`), create the required files, run `node validators/validate.js ./your-directory`, then run `bash tests/conformance/run-conformance.sh`, and iterate until both pass. The negative test cases tell you exactly what the validator checks for and why.
 
-If you want to cite the specification in a paper, the canonical reference is RFC-0001 v0.5.0, available at `rfcs/RFC-0001-familiar-contract.md`. The accompanying paper (Alexander, 2026, forthcoming on arXiv) provides the academic framing including the principal-agent formulation, comparison with Self-Harness and SkillOpt, and formal definitions. The public companion authority-boundary design for Ward daemon builders is [OpenCoven/coven-threads `specs/PHASE-0-DESIGN.md`](https://github.com/OpenCoven/coven-threads/blob/main/specs/PHASE-0-DESIGN.md), but RFC-0001 §5 remains the normative Familiar Contract requirement.
+If you want to cite the specification in a paper, the canonical reference is RFC-0001 v0.6.0, available at `rfcs/RFC-0001-familiar-contract.md`. The accompanying paper (Alexander, 2026, forthcoming on arXiv) provides the academic framing including the principal-agent formulation, comparison with Self-Harness and SkillOpt, and formal definitions. The public companion authority-boundary design for Ward daemon builders is [OpenCoven/coven-threads `specs/PHASE-0-DESIGN.md`](https://github.com/OpenCoven/coven-threads/blob/main/specs/PHASE-0-DESIGN.md), but RFC-0001 §5 remains the normative Familiar Contract requirement.
 
 If you have questions that are not answered here, open an issue in the repository.
diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "familiar-contract",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "private": true,
   "type": "commonjs",
   "scripts": {

diff --git a/rfcs/README.md b/rfcs/README.md
@@ -18,7 +18,7 @@ The RFC is the spec. The schemas are the machine-readable form. The conformance
 
 | Number | Title | Version | Status | Notes |
 |---|---|---|---|---|
-| [RFC-0001](RFC-0001-familiar-contract.md) | The Familiar Contract | v0.5.0 | Draft | Canonical current draft |
+| [RFC-0001](RFC-0001-familiar-contract.md) | The Familiar Contract | v0.6.0 | Draft | Canonical current draft |
 
 ## Historical snapshots
 
@@ -28,6 +28,7 @@ do not edit them in place.
 
 | Snapshot | Version | Status | Source |
 |---|---|---|---|
+| [RFC-0001-v0.5](RFC-0001-v0.5.md) | v0.5.0 | Historical snapshot | tag `v0.5.0` (main `6ab88f8`) |
 | [RFC-0001-v0.4](RFC-0001-v0.4.md) | v0.4.1 | Historical snapshot | tag `v0.4.1` (main `8a2dfd2`) |
 | [RFC-0001-v0.3](RFC-0001-v0.3.md) | v0.3.0 | Historical snapshot | tag `v0.3.0` (main `710036e`) |
 | [RFC-0001-v0.2](RFC-0001-v0.2.md) | v0.2.0 | Historical snapshot | `808ae167d8bfea7f2162f84b6f4c9269d319a9b1` |
@@ -57,14 +58,14 @@ Proposed → Draft → Review → Accepted → (Superseded)
 ## How to cite an RFC
 
 ```
-Familiar Contract RFC-0001 v0.5.0, "The Familiar Contract."
+Familiar Contract RFC-0001 v0.6.0, "The Familiar Contract."
 OpenCoven, 2026. https://github.com/OpenCoven/familiar-contract/blob/main/rfcs/RFC-0001-familiar-contract.md
 ```
 
 For academic citation, prefer the tagged release (the version tag is cut when the corresponding RFC revision merges; until then, cite the latest existing tag):
 
 ```
-https://github.com/OpenCoven/familiar-contract/releases/tag/v0.5.0
+https://github.com/OpenCoven/familiar-contract/releases/tag/v0.6.0
 ```
 
 ## License