v0.2.0 — RFC-0001: The Familiar Contract

RFC-0001: The Familiar Contract — first numbered, testable specification

This release reformulates the Familiar Contract from a draft SPEC.md into a numbered RFC with normative MUST/SHOULD/MAY language, a hardened authority-layer separation requirement, and an executable conformance test suite.

What's new

RFC-0001 — The Familiar Contract (NEW)

• 11 sections, ~3,600 words, normative throughout
• 85 RFC 2119 keywords (42 MUST, 12 MUST NOT, 18 SHOULD)
• Hardened authority-layer separation requirement (§5.1) — a Ward enforced solely by familiar cooperation does not satisfy this RFC
• Four enforcement gates with normative requirements (§5.4); Gate 4 is the real security boundary
• Protected invariants (§4.2) — semantic protection, not path-only
• Identity probes + regression suite (§5.5) are normative
• Append-only audit log (§5.6)
• Threat model + failure modes (§8)
• Open testing gaps (§9) — honest about what file-level conformance can and cannot prove

Conformance suite (NEW)

• 5 positive cases that MUST pass validation
• 9 negative cases that MUST fail validation, each with documented violation
• bash tests/conformance/run-conformance.sh returns READY only on full suite pass

positive: 5/5 passed
negative: 9/9 failed correctly
unexpected: 0
READY

rfcs/README.md (NEW) — RFC process docs (lifecycle, numbering, citation)

What changed

• README.md — Version badge → v0.2.0; RFC-0001 badge added
• SPEC.md — Marked Superseded; preserved for reproducibility with pointer to RFC-0001
• CHANGELOG.md — v0.2.0 entry
• validators/validate.js — Promoted missing MEMORY.md from warning to violation (RFC §3.4 makes file presence a MUST). Surfaced by negative/09-missing-memory test case.

Why this matters

The AI field has solved capability. What it has not solved is identity: a stable name, a declared scope, enforced authority limits, durable memory, and a clear human owner. Production systems are starting to ship the vocabulary — SOUL.md, IDENTITY.md, MEMORY.md files appear in HKUDS ohmo, Signet AI, and elsewhere — but none has specified the enforcement contract for that layer.

RFC-0001 specifies what convention cannot enforce: structural validation gates above the editable layer, enforced by an authority layer the agent cannot bypass.

Citing this release

@misc{familiarcontract2026,
  author       = {{OpenCoven}},
  title        = {The Familiar Contract, {RFC-0001} (v0.2.0)},
  howpublished = {\url{https://github.com/OpenCoven/familiar-contract/releases/tag/v0.2.0}},
  year         = {2026},
  note         = {Tagged release v0.2.0, 2026-06-19. Includes executable conformance suite.}
}

Conformance

A claim of v0.2.0 conformance MUST be backed by a passing run of bash tests/conformance/run-conformance.sh. The reference validator at validators/validate.js checks structural compliance; runtime enforcement (§5.1, §5.4) is required for full conformance and is verified at the system level, not the file level (see §9 for the open testing gaps this distinction creates).

Relation to other work

RFC-0001 §7.2 explicitly distinguishes from production systems that ship the vocabulary but not the contract:

• HKUDS ohmo — ships soul.md, identity.md, user.md, BOOTSTRAP.md, MEMORY.md. Convention-based protection only.
• Signet AI — ships SOUL.md, IDENTITY.md, MEMORY.md, USER.md, AGENTS.md. Markets the context layer; does not specify validation gates.
• Letta — supports a persona memory block self-editable by the agent. The explicit opposite of a protected surface.

These systems are convention-based protection. They are not non-conformant; they simply do not address the enforcement layer this RFC specifies.

Acknowledgments

Validator gap surfaced by Cody during the conformance-suite build. The suite did its job on first run — caught a real mismatch between spec and implementation.

---

Diff: v0.1.0...v0.2.0 — 77 files changed, +2764 / −12.