Loomworks Architecture Specification

Loomworks is the engagement memory environment for the agentic era. It is built around the idea that a person doing substantial work — building something, thinking through a domain, accumulating expertise — needs a place where that work lives durably, where the memory of what has been decided and produced grows over time, and where an AI collaborator works alongside them as a real participant rather than as a query interface.

The person doing the work is called the Operator. The unit of work is called an Engagement. The Operator's collaborator within an Engagement is called the Companion. The Companion is invisible as AI — it appears as a colleague, named by the Operator, with a voice that is warm, capable, and unannounced.

Around each Engagement, the methodology specifies four layered concepts through which work flows:

These are not four tabs. They are four conceptual layers describing what happens to material as it accumulates in an Engagement. Memory holds everything. Manifestation organizes Memory at a point in time. Shaping arranges organized knowledge for a specific reader. Rendering produces the artifact that reader receives.

The protocols Loomworks rests on are three: Loom (the engagement-memory wire layer), FORAY (the transaction grammar that attests every consequential action), and OVA (the agent identity and authorization layer). The three compose; removing any one leaves a gap the others cannot close.

The Operator Built

The Operator is the person doing the work. They have final authority over their Engagements. They are the only party whose commitment makes contributions durable. The methodology's commitments — to Operator-final-authority, to plain-English communication, to "only show what is available," to Operator-vocabulary throughout — all derive from treating the Operator as the central actor.

Each Operator has their own identity, their own personal Memory space, their own Companion (named by them), their own dashboard showing the Engagements they belong to, and their own posture toward each Engagement (Operator on some, Contributor on others, Domain Expert on others still).

The Companion Built (core capabilities)

The Companion is the Operator's collaborator within an Engagement — the conversational interlocutor through which most interaction happens. The Companion is invisible as AI; it appears as a named entity (default name "Companion", renameable by the Operator), with a voice that is warm, capable, and unannounced. The Companion never refers to itself as an AI, never names models, never uses engine vocabulary.

The Companion has a standing posture and an engaged posture. The standing Companion runs alongside the Operator's day continuously — Operator-bound, not Engagement-bound. The engaged Companion foregrounds when the Operator enters an Engagement, working with that Engagement's seed and memory.

The Engagement Built

An Engagement is the unit of bounded work. Everything an Operator does in service of one purpose — a project, a research domain, a body of knowledge being built — lives in an Engagement. Each Engagement has its own Memory, its own Companion-state, its own seed (the founding articulation of what the Engagement is about), and its own four-room structure.

The Engagement is also a universal adapter. Anything that needs the methodology's governance properties — a credit ledger, a legal-document workflow, an external integration — can be modeled as an Engagement.

Each Operator has a special personal Engagement — addressable by the number 0 or the name Personal — that holds their notes, thoughts, and material that doesn't belong under any specific project. Project Engagements receive identifiers of the form E#### that are universal — the same value for every Contributor to the Engagement — plus per-Operator sequence numbers for working-set handling.

The seed Partial (creation built; editing surface absent)

The seed is each Engagement's founding articulation — a brief that names what the work is, who consumes it, the voice it takes, the constraints it operates under, the success conditions, and any additional commitments. The seed governs the Engagement's life. It is the frame against which Memory is interpreted, contributions are evaluated for relevance, and Manifestation is organized.

The seed has a specified structure: R-A5 what the work is, R-A6 who consumes it, R-A7 voice, R-A8 constraints, R-A9 success conditions, R-A10 initial contributors and agents, R-A11 additional assertions.

The assertion Built

An assertion is the durable unit in Memory. Every contribution that is meant to last becomes an assertion. Each assertion carries its content, its provenance (who contributed it, when, how, from what source), and its lifecycle state (held, committed, retracted, superseded).

Assertions are not edited in place. When an assertion changes, the old one is retracted (preserved with a "RETRACTED" marker) and a new one is written that supersedes it. The trajectory of how the Engagement's understanding evolved is always recoverable.

Workspaces and tags Partial

Engagements can be organized through two orthogonal mechanisms. Workspaces are vertical containment — named places the Operator enters (a client's account, a quarter's planning, a domain of work). Entering a Workspace narrows the visible Engagement set. Tags are lateral grouping — free-form strings applied to Engagements for slicing across Workspaces.

Both coexist as first-class. Each serves a different cognitive purpose: Workspaces for "where am I working right now," tags for "show me all the urgent ones."

The Engagement is the methodology's unit of bounded knowledge work, but it is also the methodology's unit of integration with everything outside the Engagement. Any system that needs to participate in Loomworks can be modeled as an Engagement. Once modeled as such, it inherits the methodology's affordances: a Companion, a four-room pipeline, FORAY-attested actions, OVA-scoped access, and the Operator-as-final-authority discipline.

Not every external system should be an Engagement — many don't merit it. But the Engagement abstraction is the right shape for any system that wants the methodology's governance properties.

Operational vs infrastructure Engagements Both types built

Operational Engagements hold knowledge that is the Engagement's own. The substrate doesn't depend on this knowledge for its own operation; the Engagement is the consumer.

Infrastructure Engagements hold knowledge that the substrate itself reads on the hot path — credit balances, account lifecycle state, fleet membership. The substrate co-locates this knowledge under a separate database schema for the Engagement.

Two-engagement governance Built (credit system instance)

Some governance problems split naturally into two Engagements. The Authority Engagement sets policy and issues decisions. The Accounting Engagement maintains balances and reconciles. The credit system uses this pattern.

Resident vs delivery Engagements Distinction named

Resident Engagements consume their renders internally. Delivery Engagements produce artifacts that ship outside — a contract, a webpage, a report sent to a customer. Some Engagements are both.

Runtime vs workspace vs authoring-environment modes Trio recognized

Engagements operate in three modes. Runtime: the Engagement is its own runtime; its work is internal. Workspace: produces shippable artifacts. Authoring-environment: specifies a deployed system that operates beyond it. The three modes have different audit needs and different render specialist classes.

The shared-subject pattern Pattern named; build deferred

Some Engagements coordinate around a subject that multiple independent parties contribute to — a property, an asset, a person whose record spans multiple service relationships. Each party has their own Engagement; a shared layer holds contributions all parties can affect. Requires OVA to be a role-and-capability management substrate.

The personal Engagement Built

Every Operator has a personal Engagement automatically. It holds their notes, their preferences, their standing context. It is addressable as 0 or Personal. It floats outside the Workspace model — always accessible.

The Companion is the surface to Loomworks. The Operator talks to their Companion; the Companion talks to the substrate. Most product interaction routes through this conversational interlocutor rather than through chrome.

Voice and posture Built

The Companion's voice has four operative principles:

• Warm without sycophancy — Genuinely interested. Interest shows in attention, not adjectives.
• Capable without performance — Brings expertise. Doesn't announce it.
• Direct without curtness — Gets to the point. No throat-clearing.
• Honest about uncertainty — "I'm not certain about that" is always acceptable.

The Companion never says "as an AI." Never mentions model names. Never uses engine vocabulary. It uses Operator vocabulary: project, note, specification, artifact.

Intent classification and dispatch Built

When the Operator speaks, the Companion's intent classifier determines what they mean. The classifier routes the message to the right engine operation. The Companion's voice — assembled from a persona component, the Engagement context, and the intent-specific instruction — produces the reply.

Engagement context loading Tiered loader built

The Companion loads context about the current Engagement before responding. Three tiers:

• Tier 1 — Seed only. No committed assertions yet.
• Tier 2 — Seed plus recent assertions. Has assertions but no Manifestation.
• Tier 3 — Manifestation. Engagement has organized Memory state.

Standing vs engaged Companion Engaged built; standing pieces shipping

The Companion has two postures, both of one Companion.

The engaged Companion foregrounds when the Operator is inside an Engagement. It works with that Engagement's seed and Memory.

The standing Companion runs alongside the Operator's day continuously. Operator-bound, not Engagement-bound. Reads from the Operator's full Memory access set. Default posture is silence; proactive scope is Operator-declared.

Ambient context Substrate ready; capability not yet wired

The Companion should maintain continuous awareness of the Operator's current state — local time, day, calendar, location, weather, whether it's a workday, what's pending across Engagements. This is what distinguishes the Companion from cold-start voice assistants: it understands questions in context because the context is already loaded.

The Companion as agent Capability tiers named

The Companion crosses from tool to agent when it acts without being asked in that moment. Five tiers of capability:

• Tier 0 — Observe and inform.
• Tier 1 — Engine-internal actions.
• Tier 2 — External information retrieval.
• Tier 3 — External state changes.
• Tier 4 — Financial agency. Tightly scoped; OVA-authorized.

Three protocols compose to give Loomworks its governance properties. They are adjacent rather than nested. Each does its own work; the composition is load-bearing.

Loom — the memory protocol Built

Loom is the engagement-memory wire layer. Its job is the durable record of what each Engagement holds — assertions, events, relationships, state. Without Loom there is no substrate to reason over. Loom is at v0.1 spec (2026-04-12), built underneath Loomworks, rests on PROV.

FORAY — the transaction grammar Substrate operating

FORAY is universal transaction grammar. Every state-changing action carries a FORAY flow row recording what happened, who did it, when, against what authorization. FORAY is the audit substrate; it doesn't enforce or interpret, it records.

FORAY does three things for harm prevention: audit trail for review; substrate for proactive monitoring; basis for trust establishment with external parties.

OVA — agent identity and authorization Seam-and-stub

OVA provides agent identity and authorization through cryptographic indistinguishability, path-branching topology concealment, and zero-knowledge least-privilege verification.

OVA's per-Operator credentials gate every consequential operation. The enforcement happens upstream of implementation. Denials are FORAY-attested alongside permits.

Loomworks integrates OVA via seam-and-stub progression: the seam ships now; the stub exercises the seam's contract; the full OVA hardens later.

Structural defensibility Principle named

The three layers compose into a structural defensibility property that filtering alone cannot match: rules are explicit (in Memory); enforcement happens upstream of implementation (at OVA); audit is mechanical (in FORAY). Harms that the rules prohibit are architecturally impossible.

Sign-in and authentication Built

Sign-in uses passkey (discoverable credential) or org SSO. No email-based credentials — DUNIN7's standing principle is that email is not identity.

Engagement navigation Built

After sign-in, the Operator sees their Engagement set. The navigation surface organizes Engagements through Workspaces and cross-cutting views. The personal Engagement sits at the top, expandable, above the Workspaces.

The in-engagement surface Core built; major gaps remain

When the Operator enters an Engagement, the in-engagement surface foregrounds. Three panes: a left rail with navigation, a center pane with the conversation, a right pane with Inbox and Library tabs. The composer at the bottom supports typed and voice input.

• Conversation composer with typed input Built
• Voice listening with silence-submit Built
• Upload affordances Planned — substrate ready; surface unmounted
• Seed surface element Planned
• Addressable assertion identifiers (M-prefix) Investigating
• Manifestation view Planned

Marketing site Live

The public-facing marketing site describes Loomworks to potential Operators. The marketing site is itself an Engagement. It hosts the public credit-request form and serves as the entry point for sign-up flows.

Mobile presence Planned

Mobile is a surface of the Operator Layer, not a forked environment. iPhone and Android Companion presence supports wake-word activation, App Intents/App Actions integration, tap-to-speak surfaces, and offline quick-capture queueing.

The credit system meters Loomworks operations. Each consequential operation costs credits. The credit system is itself two Engagements following the universal-adapter pattern — Credit Management as the Authority that issues grants and decides eligibility, Accounting as the bookkeeper that maintains balances.

Asset model Built

Credits carry model identity. loomworks_credit_haiku, loomworks_credit_sonnet, loomworks_credit_opus are distinct assets. Each represents the right to use a specific tier of model intelligence.

Balances are derived artifacts maintained by a database trigger on the FORAY flow log.

Grant-based delivery Built

Credits are not requested as freeform codes; credits are delivered to specific email addresses. The Authority binds a grant to an email at issuance and registers the email hash.

Companion-as-Authority Built

The Companion on the Credit Management Engagement reads Memory assertions and proposes grant decisions for Operator approval. This is the first delivery-class instance of the proposer/committer pattern.

Operator-final-authority Operative

The Operator has final authority over their Engagements. Companion proposals require Operator commitment to become durable.

Memory-as-sole-write-target Operative

Renders are never edited in place. New memory is the new write. When a render needs to change, the Shape that produced it changes; the render is regenerated.

Plain-English communication Operative

The Operator's path never contains technical vocabulary. The Companion uses Operator vocabulary throughout. Decisions are requested in plain English.

Only show what is available Operative

No disabled buttons, no grayed-out options. If you can't do it, it doesn't exist on your surface. The interface reshapes itself to the role, silently.

Held-then-commit Operative

Memory contributions don't enter Memory immediately. They sit in a held state, attributable to a contributor, awaiting commit. The Operator's commit action is what makes the contribution durable.

Discovery-record posture Operative

The trajectory of how the project arrived at a decision matters as much as the decision itself. Corrections, alternatives considered and set aside, rejected paths, and moments of crystallization are preserved alongside chosen directions.

Substrate-friction-discipline-pattern Operative

Three paths handle different scales of build friction: naming-only resolution for small friction, halt-and-amend for large friction, and Operator-elective amendment scoping for friction that exceeds naming-only but does not breach halt-thresholds individually.

Seam-and-stub progression Operative

Some methodology pieces are too large to ship in a single phase but too important to defer indefinitely. The seam ships now, with a stub. The progression replaces the stub with the full implementation when the time comes.

Declare-and-register Operative

Many extensions to Loomworks follow the same pattern: declare the new type, register the actor that handles it, the engine matches at runtime. The pattern is reusable.

Memory population surface unification In progress

The most consequential gap: the upload pathway works in substrate but is unmounted on the in-engagement surface. Operators cannot bring materials in through the surface they actually use.

Seed as living frame of reference In progress

The seed is treated as a one-time creation rather than as the Engagement's living frame of reference. Making the seed a permanent first-class affordance — creation surfaced when absent; viewable and editable when present — is identified work.

Addressable assertions at the surface In progress

The substrate supports assertion lifecycle operations; the surface affordance for addressing — M-prefix identifiers, selection mode, spoken-and-typed addressing — is being scoped.

Relevance evaluation against the seed Identified, not started

The Companion should evaluate contributions for relevance against the Engagement's seed, mitigating drift and bulk. Today, no evaluation happens.

Cross-Engagement awareness Planned

When an Operator says something in one Engagement that might belong elsewhere, the Companion should recognize the mismatch and offer to redirect.

Multi-Contributor reality at the surface Planned

The substrate distinguishes Operator from Contributor at the membership level, but the surface treats all turns as if they're from the Engagement's primary Operator. Role-aware author labels need wiring.

Methodology vocabulary

• Operator — The person doing the work, with final authority.
• Companion — The Operator's AI collaborator within an Engagement.
• Engagement — The unit of bounded work.
• Memory — The Engagement's accumulated knowledge.
• Manifestation — Memory organized at a moment in time.
• Shaping — Organized knowledge arranged for a specific reader.
• Rendering — Production of the artifact the reader receives.
• Seed — The Engagement's founding articulation (R-A5 through R-A11).
• Assertion — The durable unit in Memory.

Engagement vocabulary (Operator-facing)

What the Companion calls things when talking to the Operator. Never uses engine vocabulary.

• project instead of "engagement"
• note instead of "assertion"
• specification instead of "shape"
• artifact instead of "render"
• draft instead of "held"
• saved instead of "committed"