Version. 0.1 Date. 2026-05-08 Status. Investigation. Architectural extension that the existing 2-space pattern already supports as a special case. Build is far behind the methodology-level answer. Filed to preserve the trajectory and to make explicit the load-following relationship between memory-space extension and OVA's substrate role. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Conversation began with the Operator observing that today's architecture supports two memory spaces concurrently (personal Memory and active engagement Memory), and asking whether the same pattern accommodates 2+ identifiable memory spaces, multiple "personalities" in multi-Contributor engagements, and connections between engagements and other particular memory spaces. The conversation extended into the implications for OVA's role as memory spaces and contributors multiply. Informed by. Phase 41 (Companion identity, ActorRef, personal engagement). Phase 43 (personal memory contribution, held + commit lifecycle). Phase 14 person layer Discovery (designation stacking, Domain Expert recognition). Methodology v0.18 / v0.20 (Companion identity, Memory expectations, the protocol triangle: Loom remembers, OVA authorizes, FORAY audits). Companion-as-Agent Investigation v0.1. Loomworks Deployment Strategy v0.1 / v0.2 (multi-instance fleet via DevOps engagements, jurisdiction governance through the protocol triangle). The two sister investigations from this same session: closed-loop engagement investigation (Companion as attribution channel for non-human reporters; agent fabric reporting model) and knowledge elevation pathway investigation (operator-gated promotion across the domain hierarchy; the rejection of auto-flow). Phase 45 CR (delegation contract, approval cards, OVA seam). OVA provisional patent (March 2026).
The Operator opened with a sequence of related observations and questions:
A follow-up question landed: So OVA is going to play an increasingly important role? This second question, on examination, turns out to be the load-bearing structural consequence of the first. The two are filed here as one coherent investigation rather than as two separate ones.
The 2-space pattern is already a special case of an N-space pattern. There is nothing in the architecture that limits the Companion's session to two memory spaces. Personal + engagement is the minimum useful set, not a hard limit. The extension to 2+ identifiable memory spaces is structurally clean and requires no architectural rework — what changes is that the Companion's memory access set at session time becomes computed from a richer membership chain rather than a hard-coded pair.
The "multiple personalities" question collapses cleanly once vocabulary is pulled apart: in a multi-Contributor engagement, each Contributor has their own Companion; each Companion brings its own personal Memory access; the engagement Memory is shared. The architecture already produces multi-personality reasoning as a consequence of personal Memory being per-person and engagement Memory being per-engagement — not as a feature added on top.
The OVA observation is the structural consequence: as memory spaces multiply, contributors multiply, and authorization questions become matrixed (cross-Contributor, cross-space, cross-engagement, cross-instance), OVA stops being a notional third corner of the protocol triangle and becomes the runtime gate on every action crossing an authority boundary. OVA's role is load-following — it scales with how many authority boundaries the architecture crosses.
The Operator's question conflated two things that turn out to be worth separating cleanly.
Initial framing under consideration. "Multiple personalities" as a feature of the Companion — a single Companion that adopts different personae depending on which Contributor it is serving.
Why it fell. That framing puts personality at the wrong layer. The Companion is bound to a person (Phase 41); identity is per-person, not per-engagement and not per-context. A Companion that switched personalities by context would either lose its bond to the Operator (drift) or carry stale context across sessions (leakage).
What landed. Each Contributor has their own Companion. Each Companion has its own personal Memory access. Engagement Memory is shared across Contributors on the engagement. So in a four-Contributor engagement, four distinct Companions are in play — each with its own personal-Memory access, each reading the same engagement Memory. The engagement itself has context (Memory, decisions, voice guidelines, ways of working) but does not have personhood. Each Contributor's Companion adapts to the engagement's context while retaining the Contributor's personal context. "Companion identifies with the Operator" is preserved in shared work because each Contributor's Companion identifies with that Contributor.
This means multiple personalities is already what the architecture produces — not as a feature added on top, but as the natural consequence of two design commitments already in place: personal Memory is per-person, and engagement Memory is per-engagement.
The conversation then established that "2 memory spaces" was never a hard limit. The Companion's session today reads from two spaces concurrently because two is the minimum useful set for single-Contributor work — personal context plus the active engagement's context. Nothing in the design prevents adding more.
The natural additional space types — none built today, all consistent with the existing architecture:
Each space is typed; each has its own governance (who authors, who reads, who supersedes); each contributes to the access set when the session's context invokes it. The Companion is unchanged structurally — it just has more spaces to read from.
Engagements connect to additional memory spaces through membership chains, not through direct linkage. An engagement belongs to an organization (or to none); the organization is in a sub-domain (or the engagement is in a sub-domain directly); the sub-domain is in a domain. The Companion's access set at session time is computed from this chain plus the Operator's personal Memory plus any role designations that apply.
The chain is layered, not flat. An engagement does not "have" organization Memory; it belongs to an organization that has organization Memory, which becomes visible to any Companion working inside that organization. This separation matters because it preserves the sole-write-target discipline at each level — fragments don't auto-flow up or down the chain; they are written into specific spaces under specific governance.
The Operator's follow-up question — So OVA is going to play an increasingly important role? — turned out to be the load-bearing structural consequence of the multi-space discussion. The conversation established that OVA's role is not increasing linearly with build progress; it is load-following. Each architectural extension that multiplies the authorization graph puts more load on OVA.
In the single-Operator case, OVA's role is light. Most actions are the Operator's own and don't need credential scoping beyond standing identity. The Phase 45 delegation contract is sized for the simplest application — the Operator authorizes the Companion to act in standing categories.
As Contributors multiply and spaces multiply, OVA's role grows along three new axes:
Under this load, the protocol triangle holds but the load distribution changes:
In single-Operator Loomworks the gate is mostly trivial; in multi-Contributor, multi-space, multi-engagement, multi-instance Loomworks, the gate is on every action that crosses an authority boundary.
Three commitments specifically should not bend under the multi-space extension. The temptation under multi-space load is to relax them in the name of usability; resisting that temptation is what keeps the methodology deployable in serious work.
Adding spaces does not add write paths. Each space has one write target — its assertion lifecycle, its held → committed flow, its provenance recording. The Companion authors held assertions in whichever space the contribution targets; commits flow through the same lifecycle as today. There is no shortcut through which a Companion writes directly to organization Memory because "everyone in the organization should know this." Operator-gated commit, then operator-gated promotion if the fragment belongs at a higher level.
Fragments don't auto-flow from personal to organization, or from engagement to domain, or from team to organization. The promotion rule from the elevation pathway investigation extends to all cross-space lifts. The receiving space's governance accepts, qualifies, or rejects. The Companion may notice a candidate (proposer role); a human approves the lift (authorizer role); the receiving space's governance evaluates (admitter role). Three roles, three gates, no auto-flow.
R-B19/R-B20 still applies. Adding spaces doesn't relax it. Phase 45 delegation widens pre-authorized categories; the attribution chain still resolves to a person. The OVA scope determines which person and what category, but does not remove the attribution itself.
Several. They are not blockers; they are work that needs doing when the additional space types come into the build.
What rule determines which spaces are visible to which Companion in which session? Today's rule is implicit (personal always; the active engagement when the Operator is in it). With multiple spaces, the access policy must be explicit. A natural shape: the Companion's session computes the access set from (1) the person's identity → personal Memory + role Memory; (2) the person's organization membership(s) → organization Memory + team Memory; (3) the active engagement → engagement Memory + the membership chain to domains. OVA scopes which subset of this set the session is authorized for.
The methodology defers on most of these. This is not a gap; it is a deliberate handoff to each level's own seeding.
If an organization-level fact and an engagement-level fact disagree — the organization says "we always require sign-off from the regulatory officer"; the engagement says "fast-track approval for low-risk changes" — which wins for the Companion's reasoning?
A natural rule: specificity takes precedence. Engagement wins over organization wins over domain wins over personal-as-context. But this needs to be explicit, and there are exceptions worth thinking about (a domain-level regulatory constraint should not be overridable by an engagement-level convenience). The conflict-resolution rule may itself be space-type-specific.
In the single-Operator Phase 43 design, this is implicit: personal is invisible, engagement is the active room. With multiple spaces, the contribution surface needs to communicate which space a contribution lands in, especially when an Operator could plausibly target any of several. Conversational defaults plus an explicit override (the Companion proposes "this looks like an organization-level fact; should it land in organization Memory?" with an explicit yes/no) is one shape; dedicated room tabs per space is another. Probably both.
The cross-Operator domain-level proposer question (elevation pathway §5) generalizes. Organization-level Memory may need its own steward role — analogous to a domain steward but scoped to the organization rather than to a domain. Team Memory may need a team-lead steward. Role Memory may need a role-issuer steward. These are not Companion roles (Companions are bound to individuals); they are organizational/structural roles that humans take on, with their own Companions serving them in those roles.
A person's designation on an engagement (Operator, Contributor, Domain Expert) becomes the credential basis for what they can do in that engagement. Today the engagement enforces against direct designation lookups. Under multi-space load, the cleaner pattern is for OVA to scope credentials from designations — the engagement enforces against OVA-issued credentials rather than walking the designation graph itself at every action. This is a meaningful refactor of the authorization layer when the build reaches it.
The jurisdiction question (in user memory's recent updates: "prove data never left German soil"; OVA scopes access by jurisdiction; credentials prevent cross-instance leakage) is structurally an OVA question. As the multi-instance fleet pattern matures, OVA carries the cross-instance authorization load. Build implications are significant when this lands; for the present arc, this is queued.
When the Companion delegates work to a specialist or a task agent (the agent fabric model from the closed-loop investigation), the credentials passed downstream are OVA credentials — the specialist sees "I'm acting on behalf of this Companion, who is acting on behalf of this Operator, in this engagement, under these standing authorizations." The credential chain is what makes attribution survive delegation.
Today the Companion's access set is implicit. As soon as the build reaches multi-space — likely an organization-Memory or team-Memory case driven by an early business deployment — the access policy becomes a first-class object. Worth filing now so it is named when the work begins.
The user memory notes that the OVA spec hardens before deployment at Phase 45. The observation that emerged from this conversation is that Phase 45 sizes OVA for the lightest case (single-Operator delegation). The harder cases — multi-Contributor commit authority, cross-space access, cross-engagement operations, cross-instance jurisdiction, agent-fabric credential chains — are downstream. Worth thinking about whether the Phase 45 spec hardening anticipates the load growth or only addresses the present case. If the latter, a follow-on hardening pass will be needed when each additional axis comes online. If the former, the spec is sized for the long run and the Phase 45 ship is the floor of OVA's role rather than its ceiling.
This is filed as a question about the Phase 45 CR, not a directive. The CR drafting itself will surface what scope is appropriate.
OVA is currently described mostly through the protocol-triangle metaphor — third corner of "Loom remembers, OVA authorizes, FORAY audits." That framing is true but understated. The substrate-and-gate framing makes the load-bearing nature clearer: OVA is the runtime gate on every action that crosses an authority boundary. Worth reflecting this in the next methodology revision (v0.21+) — not by replacing the triangle, but by adding the load-bearing language alongside it.
The elevation pathway investigation proposed founding-Operator-becomes-governor-with-recursive-seeding for domain-level governance (§6.1). That pattern generalizes to organization, team, and role spaces. The methodology applied to the methodology's own structure is an attractive answer because it requires no new governance primitive — every level uses the same Loomworks engagement-and-seed pattern that the rest of the architecture uses. Worth filing as a standing proposal across all space-type governance questions.
If multiple space types accumulate (personal, engagement, team, organization, role, domain — six just from this conversation), a registry of space types with their governance, access patterns, write rules, and conflict-resolution behaviors becomes the natural artifact. Probably not needed before the third or fourth space type ships, but the shape is worth noting.
This investigation completes a coherent four-piece arc filed in this session:
Together these describe how Memory flows through time and space within Loomworks, and how the protocol triangle scales with that flow. The architectural discipline is consistent across all four — Memory as sole write target; operator-gating on cross-space movement; human-attributability for commit; OVA as the gate that scales with the authorization graph.
The OVA observation in particular ties the four together. Each of the prior three investigations surfaced OVA as implicit substrate without naming the load-bearing nature. The closed-loop investigation has agent-fabric credential chains running through the Companion to specialists; that's OVA. The elevation pathway investigation has cross-space promotion under operator-gated approval; that's OVA. The AIF comparison has multi-Contributor governance as a Loomworks differentiator; that's OVA. This investigation makes the role explicit: OVA is what makes all of those other things work at scale.
This investigation was produced through a two-turn conversation responding to the Operator's framing question and follow-up. The first turn established the 2-space-as-special-case-of-N-space pattern and the multiple-personalities collapse. The follow-up question about OVA — initially appearing to be a separate topic — turned out to be the load-bearing structural consequence of the multi-space discussion, and the two were merged into one investigation rather than filed as two separate ones.
The trajectory worth preserving for future work: the conversation moved from a use-case question (can we accommodate multiple personalities?) to an architectural recognition (the existing 2-space pattern is already N-space) to a structural consequence (OVA's role is load-following, not feature-following). The recognition that OVA's importance is load-following — increasing not with build progress but with each architectural extension that adds an authorization boundary — is the conceptual move that makes OVA's role across all the prior investigations legible. It is the strongest synthesizing observation of the session.
The conversation also reinforced an observation from prior investigations: the methodology has the structural answers for these extensions; the build is at the simplest case; the work is in connecting the structural answers to the build sequencing. None of the four investigations from this session require methodology revision; all four describe extensions that the existing methodology already supports.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Memory Space Extensibility Investigation — v0.1 — 2026-05-08