Status: Engineering phases 0–3 are frozen. Phase 0 design FROZEN v0.2 (2026-07-14, tag v0.2-phase0-design); Phase 1 crate FROZEN (threads-986.18 closed); Phase 2 daemon integration FROZEN (threads-986.20 closed) and merged into the coven daemon (PR OpenCoven/coven#382); Phase 3 C7 portability FROZEN (threads-986.21 closed) with the envelope decided: Shape B (.weave) + lossy one-way .af exporter (threads-986.16 closed). 98 workspace tests green. Both Val gates resolved 2026-07-15 (repo flipped public for threads-986.19); one human gate remains — Nova on threads-986.12 (grimoire C7 canonicalization). See docs/phases.md for the phase-by-phase ledger.
License: stated as Apache-2.0 (planned) in the design doc; the committed LICENSE file is currently MIT — a known discrepancy pending reconciliation (see docs/STATUS-2026-07-15.md §6).
Owners (design phase): Sage 🌿 + Echo 🔮 co-drive; Nova 👑 + Sage on lane assignments; Cody ⚡ Phase 1+ crate lane
coven-threads is OpenCoven's authority-boundary gate layer: the external, structural enforcement contract that sits above the coven Rust daemon's untrusted-client boundary, and underneath every familiar's protected memory surface.
In the vocabulary of the Familiar Contract (RFC-0001) and the Ward v0.2 spec: this is the gate-shaped receiver on which Ward's four validation gates sit. Ward specifies what the gates check; coven-threads specifies how they are enforced, by an authority outside familiar cooperation.
It is a conforming implementation of RFC-0001 §5 — and by declaration, RFC wins on any conflict with this repo.
Gate 4 fail-closed is a line-one conformance property, not a hardening milestone: an implementation that allows Gate 4 to be bypassed does not conform to RFC-0001 (§5.4).
User-facing docs live in docs/:
- Concepts — the vocabulary (Thread, Weave, Strand, Channel), the two-compaction contract, the descriptor-vs-predicate anti-pattern. Read this first.
- Architecture — where this layer sits, the enforcement flow, the
ward.auditstore. - Authority model — fail-closed, the three verdicts, the tension state machine.
- Channels and strands — the four channels, the five strand kinds, WARD-C1–C7.
- Phases — what is frozen, what is implemented, what is blocked, what is not started.
- FAQ · Glossary
The frozen design doc is specs/PHASE-0-DESIGN.md; the docs describe it and never amend it.
The coven daemon already ships an authority boundary — untrusted clients speak over a unix socket to a trusted Rust daemon that revalidates every sensitive request. That boundary is real, documented in coven/docs/SAFETY-MODEL.md, and works.
What is missing today: the boundary validates who and what action, but does not validate what the requester is trying to mutate against a typed protected surface. coven-threads is that missing layer. It doesn't replace the daemon; it gives the daemon a gate-shaped receiver for identity-surface mutation requests.
The architecture is named around the metaphor of weaving because the metaphor does load-bearing work, not because it sounds pretty. Every term is bound to a concrete referent at first use (design doc §2.5); the referents below are the frozen v0.2 bindings:
- Thread (authority relationship: surface → writer) — a directional line from a protected surface (SOUL.md, MEMORY.md, an identity field) to the authority that gates writes to it. One thread per
(surface, writer)pair. Threads have tension: they hold, fray, or snap under load. - Weave (enforced pattern of threads across a familiar or Coven) — the invariant that these specific threads must all hold together for the identity to be coherent. Ward's four gates are the loom the weave is made on — the fixed structure threads run through — not threads themselves.
- Strand (fiber inside a thread: hash | signature | manifest entry | audit trail | serialization marker) — the fibers that make a thread survive stress. A thread survives a channel iff its strands survive that channel; a thread frays when a strand fails, which is what makes failure legible.
- Channel (axis of load a thread must hold under) —
Deliberate,Forced,Serialization,Mutation. Every gate check is one question: does thread T hold under channel C?
Design intent of the metaphor: a familiar's identity is not a single object protected by a single gate. It is a woven structure of typed protected surfaces with distinct authority relationships. The metaphor makes the multi-surface, multi-authority reality of the architecture visible instead of collapsing it into "protect SOUL.md."
Co-designed as channels a weave must survive, not stacked as features (design doc §3.3):
- Identity-as-memory-property — the identity surface is a typed layer of memory, not a runtime configuration; threads bind to typed surfaces at construction time.
- Structural mutation authority — the gate is external to the familiar; the familiar cannot cooperate its way past it. Enforcement is Rust-side, daemon-called.
- Two-compaction contract — deliberate memory compaction (dreaming) and forced context compaction are distinct channels with distinct survival requirements; WARD-C1–C6 govern the forced channel.
- Survives serialization (WARD-C7) — the authority contract must round-trip across export/import, or fail visibly. Numbered seventh so its lineage from C1–C6 stays legible; canonical home for C1–C7 jointly is the
coven-grimoireWard Layer Spec Brief §9.
These are non-negotiable and must be co-designed, not stacked — the Channel enum is where the type system holds them together.
Honest labels; the detailed ledger is docs/phases.md.
- Phase 0 — design doc + beads scaffolding + repo skeleton. ✅ FROZEN v0.2 (2026-07-14, tag
v0.2-phase0-design). Nova sign-off; RFC-0001 §5 round-trip verified. No enforcement code, by design. - Phase 1 — core crate.
[MERGED, NOT RELEASED]—crates/coven-threads-core(types, hash-manifest layer, §5 receiver, RFC-0001 §5 conformance mirror; 98 tests green). Imported by covenmainviaCargo.tomlgit dep at tagv0.1.2and called fromcrates/coven-cli/src/threads_gate.rs::gate_protected_editson every protected-tier edit. The next coven release will include this integration; current releasev0.0.54(2026-07-14) predates PR #382..18closed. - Phase 2 — coven daemon integration.
[MERGED, NOT RELEASED]— crate-side contracts landed (audit.rs,staging.rs); daemon-side call site merged to covenmainvia PR #382 (feat/threads-gate-validator). Beads.14(epic),.20(FREEZE), and.19(merge gate — resolved by flipping this repo public) closed with evidence. - Phase 3 — portability contract. C7 round-trip semantics implemented and tested (
portabilitymodule + 12-test suite); the interchange envelope is decided (threads-986.16closed): Shape B (.weave) canonical, plus a lossy one-way.afexporter — see the §6 decision record inspecs/PHASE-3-PORTABILITY.md. - Phase 4 — cockpit integration. CovenCave surfaces for reviewing weaves, inspecting strand state, approving/rejecting proposals. Not started (
threads-986.17).
- Not a general-purpose policy engine. This is a typed authority layer for OpenCoven familiar surfaces. Reusability is a nice-to-have; typed correctness is the goal.
- Not a runtime-portability format. That's Phase 3's job. Phase 0 is enforcement design, not export.
- Not
.af-compatible. Documented divergence, source-verified 2026-07-14: Letta'sCoreMemoryBlockSchemahas no protection field and runtimeread_onlyis stripped at export — silent downgrade on import is exactly what WARD-C7 refuses. See docs/faq.md.
coven/docs/SAFETY-MODEL.md— authority boundary this layer sits onfamiliar-contract/rfcs/RFC-0001-familiar-contract.md— the contract this layer enforces (RFC wins on conflict)coven-grimoireWard Layer Spec Brief §9 — canonical home of WARD-C1–C7research/synthesis/memory-layer-comparison-opencoven-openclaw-hermes-2026-07-13.md— comparative context
First commit: 2026-07-14. Repo scaffolded in Phase 0 evening session with Val's greenlight.




