Loomworks — Confidentiality posture as a declared engagement property (standing note)

Version. 0.1 Date. 2026-06-13 Status. Settled architectural direction. Records a destination and the discipline that governs reaching it. Architecture-and-positioning only — no engine change is implied, and nothing here is built. Each rung above the default is a substantial arc requiring its own scoping. Candidate for absorption into the comprehensive specification (and eventually the seed) once the property stabilizes. Provenance. Operator (Marvin Percival) direction, 2026-06-13, arrived at through the data-at-rest investigation arc. The seed-grounded resolutions rest on a verbatim seed check of candidate seed v0.12 performed 2026-06-13. The protection-mechanism landscape rests on web sources verified 2026-06-12 (cited in the parent investigation). Parent / sibling. investigations/loomworks-data-at-rest-protection-investigation-v0_2 (the arc this crystallized from; records the trajectory and the landscape). scoping-notes/loomworks-key-custody-hardening-scoping-note-v0_1 (Rung 1, already scoped).

Plain-language summary

What this records. A destination. Loomworks will treat confidentiality posture — how strongly an engagement's content is protected from DUNIN7 itself — as a declared property carried by the Engagement, governed by its Operator. The engine reads the declared posture and behaves accordingly. The posture names a rung on a protection ladder. The strongest practical rung releases a customer-held key only into an attested hardware enclave, so that DUNIN7 is structurally unable to read the content outside that seal — a cryptographically provable fact, not a promise.

Why it matters. It converts the data-at-rest question from "which single protection do we build for the whole platform" into "each engagement declares the protection it needs, and the engine honors it." It lets one engine serve an ordinary coaching engagement and a privilege-sensitive legal engagement without being two products. And it anchors the strongest confidentiality claim to a structural property — key absence plus hardware attestation — rather than to operational trust, because structural properties are the only ones that survive a decade of adversaries getting smarter.

What is settled here. That confidentiality posture is a declared, enforced, engagement-carried property; that it is orthogonal to the existing access axis; that it is bounded by the UUID-identity invariant; that the architectural destination is the enclave-with-customer-key rung; that enforcement-by-key-absence is non-negotiable and must be designed before any protective rung ships.

What is not settled here. The build of any rung. The exact enclave platform. The precise Companion-capability degradation at each rung. The seed addition (deferred until the property stabilizes). These are downstream.

1. The property

Confidentiality posture is a property an Engagement declares and the engine honors. It answers: how strongly is this engagement's content protected from DUNIN7 itself? It is set per-Engagement, governed by the Operator in their per-engagement capacity.

This is a correction to an earlier framing, recorded rather than smoothed: the property was first described as "a property of an Operator and by extension Engagement." The seed check resolved it — the load-bearing locus is the Engagement; the Operator governs the posture, the Engagement carries it. (See §3, Resolution 1.)

2. The protection ladder

The posture names a rung. The rungs stack; they are not a menu to choose once. The engine honors whichever rung an Engagement declares, and rungs are built in order as demand pulls.

• Rung 0 — none (operational trust). Content is readable by the running system; protection is access control plus operator trust. The full Companion — proactive organizing, recall, premise-change detection — operates without constraint. This is the default and always exists.

• Rung 1 — key-custody hardening. Still DUNIN7's key, but rotated, envelope-wrapped (data-key / key-encryption-key split), and ideally held in a key-management service rather than the process environment. Raises the cost of a careless leak; ends the single-key-protects-everything exposure. Does not make a confidentiality claim against DUNIN7 itself — the key is still DUNIN7's. Build regardless of the rest — it is the floor under every rung above it. (Already scoped: the key-custody hardening scoping note.)

• Rung 2 — customer key, released only into an attested enclave. The encryption key is the customer's. It is released into a hardware enclave (Trusted Execution Environment) only after remote attestation proves the exact code running, present only for the duration of a computation, never to DUNIN7's general infrastructure. DUNIN7 is structurally unable to read the content outside the seal, and the customer can cryptographically verify this. The server-side Companion survives, because the reasoning happens inside the seal. This is the architectural destination for the strong claim.

• Rung 3 — customer key, client-side only. The key never touches DUNIN7's infrastructure at all. DUNIN7 stores ciphertext it cannot decrypt under any circumstance. The Companion goes where the key is — client-side and constrained; the proactive, between-sessions, server-side behavior is surrendered. The absolute exclusion bar, at the cost of the product's most valuable property. Exists for buyers who require it and accept the trade.

The destination is Rung 2. It is the highest rung that preserves the server-side Companion — Loomworks's actual product, the recall and proactive organizing — while making confidentiality a structural, attestable fact rather than a promise. Rung 3 exists for the buyer who requires absolute exclusion; the property lets each Engagement choose its rung rather than forcing the platform to pick one.

3. Three resolutions from the seed (candidate seed v0.12, checked 2026-06-13)

The seed is silent on confidentiality-as-an-engagement-property, on key custody, on content protection, and on inheritance grammar — by the seed's own line-15 rule, the comprehensive specification governs these, which makes this property net-new architecture, not an amendment to a settled commitment. But the seed is not silent on three things that bind the design:

Resolution 1 — posture is per-Engagement, Operator-governed; there is no Operator-level platform-wide posture. The seed (Authorisation) scopes the Operator's governance per-engagement — "Engagement-scoped decisions are his" — and assigns cross-engagement reach to the founder role (methodology / program), not to Operator governance. A confidentiality posture is an engagement-scoped decision; it is set on the Engagement and governed by its Operator. The seed has no inheritance grammar, so none is invented — the property lives on the Engagement, not flowed down from an Operator-level setting.

Resolution 2 — posture is a new axis, orthogonal to the existing access axis. The seed already has a who-can-reach axis: a scope's Memory is open / restricted (via OVA access-control list) / private, with defaults per scope kind. Confidentiality posture is a how-content-is-protected axis — a different question (access control is not encryption). The two are independent: an Engagement can be private on access and Rung 2 on protection, in any combination. The posture must not be folded into the access modes as a fourth value — that would be a category error. They are orthogonal axes.

Resolution 3 — the personal side may carry a posture, but the posture cannot touch the UUID-identity invariant. The seed has no "personal" scope and is silent on personal Memory as a per-engagement-variable thing (the Companion functional spec governs the personal side). But the seed commits (Identity, line 111) that the UUID identity is a cross-cutting invariant — "applies across every engagement Loomworks hosts," a DUNIN7 standard, the thing FORAY attests against and OVA authorizes against. Therefore: a confidentiality posture may protect personal-Memory content, but it cannot make the UUID-identity reference vary or disappear — the UUID must remain the stable spine FORAY and OVA bind against. The posture protects content; the identity spine is untouchable. (This intersects directly with §5, the entanglement finding.)

4. The enforcement discipline — non-negotiable, designed first

**A posture that the engine merely describes — a flag the system consults politely while still holding a path to the plaintext — is worse than no posture, because it manufactures false confidence. For any rung above 0, the posture must be load-bearing**: the engine must be structurally unable to read the content, because the key genuinely is not there (Rung 3) or is present only inside the attested seal (Rung 2). The truth of the flag is enforced by the absence of the key, not by code that promises to behave.

This has a hard consequence for sequencing: before any protective rung ships, the engine's inability to read protected content must be testable and attestable. The customer receives cryptographic proof (enclave attestation at Rung 2; the structural impossibility of decryption at Rung 3), not DUNIN7's assurance. Enforcement-by-key-absence is designed and proven first; the rung is built on that foundation, never the reverse. This is the line that converts "we did our best" into "we cannot betray you even under compulsion" — the only version that withstands concerted intelligent interrogation.

5. The bound that survives every rung — self-identifying content and the entanglement finding

Two facts bound what any rung can claim, and they must be stated to any buyer:

• Content self-identifies by its facts, not just its proper nouns. A legal brief that names its own parties, coaching notes that say "the CFO after the Henderson deal," a rare-condition-plus-specific-facility clinical note — these re-identify themselves to an intelligent reader even with every proper noun tokenized. No protection mechanism makes self-identifying content un-sensitive at the moment an authorized reader reads it. The rungs protect content from DUNIN7 and from bulk compromise; they do not protect it from the authorized human, which is true of every system that has ever existed, including paper in a locked drawer.

• Identity is re-embedded in the content payload (engine finding, 2026-06-13). The memory-event payload is a whole-object serialization that duplicates the identity and provenance also held in dedicated columns, and free-text content may name people directly. So the relational identity spine is separable (a refactor), but the content payload re-embeds identity and is not identity-clean. This is why tokenization alone (protecting the separable columns) does not de-identify content, and why the enclave rungs — which protect content as content without needing to de-identify it — are the correct answer for self-identifying domains.

The residual at every rung is the authorized human. The destination accepts this by making the posture the customer's declared choice, not by pretending a rung dissolves it.

6. What is true today (do not over-claim before a rung is built and proven)

Only Rung 0 exists today, and not even hardened. Content is plaintext at rest; only secrets are encrypted, under one static key. Stand only on what is true: per-engagement isolation, no training, no sharing, access control, encrypted secrets, TLS in transit. Do not claim content encryption at rest, customer-held keys, "DUNIN7 cannot read your content," or de-identification — none is true until the corresponding rung is built and its enforcement proven.

7. Prerequisites and sequence toward the destination

1. Rung 1 (key-custody hardening) — build regardless. Already scoped. The floor under every rung above.
2. Enforcement discipline (§4) — designed and proven before any rung above 1. Testable, attestable inability to read protected content. This is the gate, not a later refinement.
3. Rung 2 (enclave + customer key) — the destination; demand-pulled. Scope when a buyer who requires the strong claim is real. Composes on Rung 1. Requires the enclave platform decision and the Companion-capability-degradation design.
4. Rung 3 (client-side only) — for absolute-exclusion buyers. Scope when such a buyer is real; accepts the constrained Companion.
5. Seed addition — deferred until the property stabilizes. Once the posture and the access axis are both settled in the comprehensive specification, the seed may gain a confidentiality-posture commitment alongside its access-mode commitment. Not drafted now; recorded as the eventual home.

The order is the resolution: the property is the frame (settled); enforcement is the foundation (non-negotiable, first); the rungs are built upward as demand pulls; the strongest practical rung that keeps the Companion is the destination.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Confidentiality posture as a declared engagement property (standing note) — v0.1 — 2026-06-13