Loomworks — Data-at-rest protection: landscape, positioning, and recommendation

Version. 0.2 Date. 2026-06-13 Status. Discovery record / investigation. Architecture-and-positioning only — touches no engine code, implies no build. Amendment note (v0.2). v0.1 (2026-06-12) laid out the landscape, regulated-domain positioning, and a three-recommendation sequence (key-custody, tokenization, confidential computing). v0.2 records what the arc converged on after v0.1: (1) a Claude Code inspection establishing the payload/provenance separability verdict (MIXED — §8); (2) the resulting correction to the tokenization recommendation (tokenization protects structured identity, not self-identifying content — §9); and (3) the crystallization of the whole question into a single organizing frame — confidentiality posture as a declared, enforced, laddered engagement property — now carried in its own standing note (§10). The v0.1 sections are preserved below; §§8–10 are the amendment. Per Discovery discipline, the prior framing is preserved alongside the correction, not smoothed over. Provenance. Operator (Marvin Percival) direction. Landscape rests on web sources verified 2026-06-12 (cited inline in v0.1 sourcing). Implemented-state rests on the Claude Code data-at-rest status brief @ engine HEAD 7159870 and the follow-up inspection @ 7159870. Seed resolutions rest on a verbatim seed check of candidate seed v0.12 (2026-06-13). Companion deliverable. standing-notes/loomworks-standing-note-confidentiality-posture-v0_1 — the destination this investigation converged on, recorded as a durable architectural commitment.

Plain-language summary (v0.2)

What this document does. Lays out every credible way to protect engagement and personal content at rest while still letting the Companion reason over it, places each against regulated-domain requirements, and records where the inquiry converged: a declared confidentiality-posture property on the Engagement, with the enclave-plus-customer-key rung as the architectural destination.

What changed from v0.1. v0.1 recommended tokenization ("the map") as the highest-leverage second step. The follow-up inspection showed why that leverage is lower than it looked: identity is re-embedded in the content payload and content self-identifies by its facts, so tokenization protects structured identity, not semantic identity — it reduces breach blast-radius but does not deliver the strong de-identification claim for Loomworks's domains (executive coaching, legal, healthcare). The thing that protects self-identifying content is the enclave, because it protects content as content without needing to de-identify it. So the destination moved from "tokenization is rec #2, enclave is demand-pulled #3" to "the enclave-with-customer-key rung is the architectural destination, and the whole question is best framed as a declared posture property."

What it concludes. Confidentiality posture should be a declared property the Engagement carries and the Operator governs, naming a rung on a protection ladder (none → key-custody → enclave+customer-key → client-side-only), enforced by key absence rather than described by a flag. See the standing note for the settled form.

1–7. (v0.1, preserved)

The v0.1 body — the reframe trajectory (§1), the Companion-must-read constraint and the A/B threat split (§2), the three protection families (§3: confidential computing, tokenization, FHE), regulated-domain positioning (§4), the original three-recommendation sequence (§5), what-is-true-today (§6), and prerequisites (§7) — is preserved unchanged from v0.1. It is the landscape and the starting position. §§8–10 below record where the arc moved from there.

(Full v0.1 text retained in the v0.1 file; this v0.2 carries the amendment sections. When filed, v0.2 supersedes v0.1 as the current version; v0.1 is retained as the prior position per the versioning discipline.)

8. The separability inspection (Claude Code @ engine HEAD 7159870) — MIXED verdict

The v0.1 tokenization recommendation rested on a prerequisite: are content and identity separable in the schema? The inspection answered MIXED.

• The linkage spine is separable (a refactor). memory_events carries payload and provenance as separate JSONB columns, plus dedicated structured columns — engagement_id, actor_id / actor_kind, object_id / version, timestamp. The projection tables (current_memory_objects and typed projections) decompose identity even further into dedicated UUID columns and are rebuildable from the event log. A token/map model keyed off these columns can be built without touching content.
• The content payload is entangled (a partial rebuild). events.py:165 — payload = object.model_dump(mode="json") — serializes the entire object into payload, redundantly re-embedding the same identity and the full provenance that also live in the dedicated columns, and free-text content fields can name people directly. So you cannot strip identity from content by pointing at columns; the content blob carries it too. Making content identity-clean requires reshaping how memory objects serialize to payload and re-projecting — a rebuild of the object/event-construction layer.

Plainly: the who/where/origin linkage is separable today (refactor); the content payload re-embeds identity and is the part that would need rebuilding to tokenize. The tokenization prerequisite is half-met.

9. The correction to the tokenization recommendation

The MIXED verdict, combined with the nature of Loomworks's content, corrects v0.1's framing. Two failure modes for a pure map model:

1. Structural re-embedding (mechanically fixable, deep). Tokenizing only the separable columns leaves identity in the payload blob (provenance.origin still names the person; id still present). The vault protects the front door; the payload leaves the back door open. Fixable by reshaping serialization so the payload does not duplicate identity — deterministic, but it touches the construction layer every contribution flows through.

1. Semantic self-identification (not fixable by tokenization). The content's facts re-identify regardless of proper-noun tokenization. Worked examples, by domain:

• Executive coaching: "the CFO ... after the Henderson deal collapsed" re-identifies people and company with every proper noun removed.
• Legal: tokenizing party names and figures still leaves the shape of the matter privileged and recognizable to anyone in it; altering figures could corrupt privileged accuracy.
• Healthcare: the HIPAA 18-identifier list catches structured identifiers; it does not catch "rare Brugada variant + Miami cardiac unit + March," which re-identifies a single patient through quasi-identifiers in the clinical meaning the Companion must read.

The corrected conclusion. Tokenization protects structured identity and reduces breach blast-radius; it does not deliver the strong de-identification claim (HIPAA Safe Harbor; "your matters are de-identified") for self-identifying domains. The mechanism that addresses self-identifying content is the enclave — it protects content as content (DUNIN7 cannot read it even in use) without needing to de-identify it. This inverts v0.1's emphasis: for Loomworks's domains, tokenization's leverage is lower than it looked, and the enclave's necessity is higher. The enclave moves from "demand-pulled #3" to the architectural destination.

10. The convergence — confidentiality posture as a declared engagement property

The whole question crystallized into a single organizing frame, recorded in full in standing-notes/loomworks-standing-note-confidentiality-posture-v0_1. In brief:

• The frame (settled): confidentiality posture is a property the Engagement carries and the Operator governs — not "which protection do we build for the platform," but "each engagement declares the protection it needs, and the engine honors it." (Earlier framing "a property of an Operator" corrected to "Engagement carries, Operator governs," per the seed check.)
• The ladder: the posture names a rung — Rung 0 none (operational trust, full Companion) → Rung 1 key-custody hardening → Rung 2 customer key released only into an attested enclave (the destination — keeps the server-side Companion, makes confidentiality structural and attestable) → Rung 3 client-side-only (absolute exclusion, constrained Companion). Rungs stack and are built in order as demand pulls.
• Three seed resolutions (candidate seed v0.12, 2026-06-13): posture is per-Engagement and Operator-governed, no Operator-level platform posture (the seed scopes Operator governance per-engagement; cross-engagement reach is the founder's); posture is a new axis orthogonal to the existing access axis (open/restricted/private), not a fourth access value; the personal side may carry a posture but it cannot touch the UUID-identity invariant (the UUID is the cross-cutting thing FORAY and OVA bind against).
• The enforcement discipline (non-negotiable): a posture the engine merely describes is worse than none — it manufactures false confidence. For any rung above 0 the engine must be structurally unable to read the content (key absent, or present only inside the attested seal), and that inability must be testable and attestable before the rung ships. Enforcement-by-key-absence is the foundation, designed first.
• The residual that survives every rung: the authorized human, and self-identifying content at the moment of authorized reading. No architecture dissolves this; the destination accepts it by making the posture the customer's declared choice.

Sequence toward the destination: build Rung 1 regardless (already scoped); design and prove the enforcement discipline before any rung above 1; scope Rung 2 when a buyer requiring the strong claim is real; scope Rung 3 for absolute-exclusion buyers; defer the seed addition until the property stabilizes in the comprehensive specification.

What the Operator does next

1. The standing note (loomworks-standing-note-confidentiality-posture-v0_1) carries the settled commitment; this investigation carries the trajectory and landscape. Both file to loomworks-record.
2. Rung 1 (key-custody hardening) is already scoped and is the build-regardless floor — the next buildable step whenever chosen.
3. The enforcement discipline is the gate before any protective rung; it is a design arc of its own, not yet scoped.
4. Rung 2 (enclave + customer key) is the destination, demand-pulled — scoped when a real buyer requires it.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Data-at-rest protection: landscape, positioning, and recommendation — v0.2 — 2026-06-13