Version. 0.2
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.
Amendment note (v0.2). Adds two refinements arrived at 2026-06-13, both grounded in a scope-model inspection of the engine at HEAD 7159870: (1) Rung 0 is a permanent, first-class, frictionlessly-selectable choice — an Operator may declare "no content protection" for any engagement without justification; this is preserved explicitly so it is not eroded by a future "secure-by-default" drift (§2a, new). (2) The posture is scope-kind-aware by design; domain scopes default to Rung 0 as a forward commitment — domain knowledge is shared, open-by-nature reference material, but domains (and every scope kind other than the engagement) are not yet built, so this defaulting is forward-looking, not current state (§3a, new). The v0.1 body is otherwise preserved.
Provenance. Operator (Marvin Percival) direction, 2026-06-13. The v0.2 refinements rest on the scope-model inspection @ 7159870 (engagement is the sole Memory scope; domain/team/role/jurisdiction and the reference relation are forward-commitment-only). Seed-grounded resolutions rest on the verbatim seed check of candidate seed v0.12 (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).
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.
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.)
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.
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.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.
Rung 0 — none, no content protection beyond access control — is a permanent, first-class, frictionlessly-selectable rung, not a deprecated fallback. An Operator may declare Rung 0 for any engagement, without justification, on equal footing with every other rung. An Operator who runs ordinary, non-sensitive engagements and never wants content encryption is making a valid choice, not a negligent one.
This is recorded explicitly because the failure mode is real: a future "secure-by-default" drift could quietly demote Rung 0 to a grayed-out "unprotected (not recommended)" option carrying friction or a justification burden. That would violate the property's own logic — the posture is the Operator's declared choice per engagement, and Rung 0 is a legitimate value of it — and it would violate the seed's "only show what is available" rule, which means Rung 0 appears as a clean, selectable posture, not a discouraged one. Rung 0 stays first-class.
Two scope notes on what Rung 0 does and does not mean:
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.)
Confidentiality posture is scope-kind-aware in its design. Not every scope kind carries the same default: domain scopes — shared bodies of practice referenced across engagements — are open-by-nature reference knowledge, not sensitive, and so default to Rung 0 (none). Encrypting a domain's body of practice would protect something meant to be shared and would fight its purpose. This mirrors the seed's existing access-axis intent, where domain scopes default to open while engagements default to private — "different scope kinds, different defaults" (seed, Memory / Constraints).
The default is a default, not a mandate: a domain that carries something genuinely proprietary — a bespoke methodology, or a practitioner's encoded method/vertical sold as the product — may declare a higher posture, exactly as a domain may be restricted on the access axis. So "domain knowledge needs no protection" is the correct everyday case, not a hard rule. (This matters for the method-as-product line: a sold vertical is domain-shaped knowledge that is also the thing being sold, and may want protection.)
Posture travels with the scope that owns the content, and references are non-transitive: an engagement at Rung 2 that references an open Rung 0 domain keeps its own content sealed — the reference is read-only and one-directional, and the two postures do not mix. An engagement's protection is not weakened by reading from an open domain.
This is a forward commitment, not a description of current state. A scope-model inspection (engine HEAD 7159870) confirmed: the engagement is the only Memory scope that exists in code. Domain, team, role, and jurisdiction are not built as Memory scopes; the engagement→domain reference relation is not built; access-default-differentiated-by-scope-kind is not built (a single per-engagement visibility column exists for dashboard filtering, with no OVA/ACL enforcement); and organizations exist only as an auth-policy/membership object, not a content scope. So today, posture has only the engagement to attach to — it would land as a column beside visibility, Operator-governed per-engagement, consistent with the founder-authority finding that Operator governance is engagement-scoped. The seed's own per-scope-kind access defaulting is equally unbuilt; the posture's per-scope-kind defaulting and the access axis's land together, when the scope model gains domain (and the other kinds) as first-class. Until then: the engagement is where posture lives, Rung 0 is its de-facto current state, and "domain scopes default to Rung 0" is honored when domain becomes a first-class scope — designed-for now, built later.
**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.
Two facts bound what any rung can claim, and they must be stated to any buyer:
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.
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.
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.2 — 2026-06-13