Version. 0.1
Date. 2026-06-04
Status. Settled decision (Operator, this session). Records a resolution; removes one of two gates in front of C5 scoping.
Audience. Internal / architectural — informs C5 (Domain layer) scoping and any future work touching either the auth Organization object or the N-space Memory scope model.
Two different things wanted the name "Organization." One is an authentication-policy object that already shipped. The other is a Memory scope that C5 (the Domain layer) will introduce. They are unrelated concepts. The resolution: leave the shipped auth object alone, and do not create a second thing called Organization for Memory. Organization-level Memory lives as an ordinary row in the generic N-space scope table, with scope_type = "organization". There is one Organization entity in the system (the auth object); organization Memory is a scope row, not an entity. The collision is sidestepped, not renamed around.
This note records the decision and why, so the reasoning is recoverable when C5 is scoped.
The auth Organization object — already built and merged.
Shipped by the step-up authentication arc (engine fe8ee0b). It is an access-policy entity: presence_proof_window_seconds, always_tap_on_commit, and memberships. An Operator belongs to exactly one (DUNIN7 today), cannot change it in any direction, and an engagement may override it to stricter-only (raise-only). It governs how hard a person must prove presence before a sensitive action.
The organization Memory scope — wanted by C5, not yet built.
C5's backing investigations (loomworks-memory-space-extensibility-investigation-v0_1.md, loomworks-engagement-domain-composition-investigation-v0_1.md) name "organization" as one of several Memory scopes above the engagement — the tier holding brand, voice, and commitments shared across an organization's engagements, composed into renders at production. It governs what knowledge composes into a render.
Same word, two unrelated jobs: authentication policy vs. shared Memory. Both will exist — C5 guarantees the second.
Keep the two concepts separate. Organization-level Memory is NOT a new Organization entity. It is a row in the generic N-space scope table with scope_type = "organization".
There is exactly one entity named Organization in the system — the auth-policy object. It is untouched by this decision. When C5 builds organization-scoped Memory, it adds a scope row of type organization; it does not add a second Organization table, class, or model.
Considered — rename the shipped auth object. Rejected: it is built and merged on a recently-landed table; renaming it is pure migration cost with no benefit. The new (unbuilt) thing is the one to shape, not the shipped one.
Considered — give organization Memory its own first-class named entity (e.g. OrgMemoryScope, BrandScope). Set aside in favour of the generic-scope-row approach: minting a standalone named entity reintroduces a second "organization-ish" thing to reason about and reconcile. A scope row whose scope_type happens to be organization has no name collision to manage at all — the scope type carries the meaning, the scope table is generic across all scope types (organization, team, role, domain, jurisdiction, campaign, partner, audience).
Considered — unify the two into a single Organization carrying both facets (auth policy + Memory scope). Deferred, deliberately. There is a real case that an organization in the human sense (DUNIN7) is both the thing setting your auth floor and the thing whose brand composes into renders — possibly one entity seen from two layers. But unifying now would (a) couple the auth layer to the Memory model, a larger architectural commitment than a naming fix, and (b) front-run the seed-amendment decision that has not yet happened — deciding "organization is one unified entity in the Memory model" before the seed has even widened Memory to N-scope is answering the question before it is asked. If the forthcoming seed-amendment session concludes the two should unify, that is a clean forward decision made then — not a rushed one made now. This note does not foreclose unification; it declines to pre-decide it.
Resolves: the naming-collision gate in front of C5 scoping. C5 can now reference organization Memory without ambiguity — it is scope_type = "organization" in the N-space scope table.
Does not resolve (the other C5 gate, still open): the seed-amendment gate — whether the seed's Memory model widens from "the engagement's Memory" (committed, seed v0.9) to N-scope, and when it does, what a Manifestation organizes: one engagement's Memory or the composed N-scope view. That is Operator-authority, seed-level work, scheduled for its own focused session. C5 is not scoping-ready until that lands.
Decision made this session (2026-06-04) following a read-only CC alignment audit (engine main HEAD eb572c0) that surfaced the collision while orienting C5 against seed v0.9. The auth Organization object's fields and shipped status are per that audit (engine fe8ee0b). The organization-Memory-scope concept is per the two C5 backing investigations cited above and architecture/loomworks-architecture-specification-v0_4.md (§N-space Memory).