Version. 0.3
Date. 2026-06-14
Status. Standing note. Records the architecture surfaced in discussion on 2026-06-13: operational Loomworks requires four independent products — the principal layer (named Stele, v0.3), OVA, FORAY, and Loomworks itself — settles where zero-knowledge cryptography belongs across them, settles whether the principal layer should be delegated to a third-party identity platform, and (v0.3) names the principal layer and records its connection to the Companion. Operator-facing. HTML primary to follow; this Markdown source alongside.
Change from v0.2. Names the principal layer Stele (said "steel") and adds §8 recording the name, its clearance, and how Stele connects to the Companion. The name is committed for internal use; a trademark knockout by counsel is the gate before public use. All v0.2 content preserved; references to "the principal layer" stand as the generic term, with Stele as its proper name.
Change from v0.1. Added §7, settling the build-versus-delegate question for the principal layer. Decision: keep Loomworks's own identity layer (already built and seed-conformant); borrow only the agent-authentication standards (RFC 7523 / RFC 8693), not a third-party identity platform. Grounded in a Claude Code survey of open-source identity platforms (2026-06-13).
Author posture. Discovery posture: the corrections that produced the four-product conclusion are preserved alongside it (§5), so a later reader can reconstruct how it was reached, not only where it landed.
Source grounding. Grounded against Claude Code ground-truth reports (2026-06-13): the Companion build-state report, the FORAY/OVA build-state report, and the OVA operational-surface-and-credential-lifecycle report, all read against OVA_PROTOCOL_SPEC_V3.md, the OVA provisional patent (filed 2026-03-11), candidate seed v0.12, and Companion architecture foundation note v0.2 / functional spec v0.2. Where a claim is the Operator's design intent not yet in any written spec, it is marked as such. Settled in discussion 2026-06-13; nothing here is built.
Operational Loomworks needs four independent products, not one. Three of them — a principal layer (who exists and what roles they hold), OVA (verifies access, conceals authorization), and FORAY (tamper-evident audit) — are usable by anyone, with or without Loomworks; Loomworks is a consumer of all three. The decision this note settles: zero-knowledge cryptography is aimed, not spread. It is concentrated in OVA, where concealing the shape of authorization is the whole product. It is kept out of the principal layer, which is an ordinary transparent store, because the dominant need there is the opposite — a consumer must plainly see and govern its own principals. A named seam is left where cross-consumer concealment could later borrow OVA's ZK if a real threat appears.
Operational Loomworks is four independent products, each usable without the others, orbiting a center.
The principal layer is named Stele (said "steel"; see §8). It establishes, persists, and authenticates who — human or agent — and holds their roles and attributes. Mints and revokes credentials. This is the who that FORAY records against, OVA verifies, Loomworks governs, and credentials are minted for. It is an ordinary transparent store (see §3), not zero-knowledge.
It is the keystone because the other three each assume a principal and none of them establishes one: FORAY records an actor, OVA verifies a credential a principal already holds, Loomworks governs a UUID already authenticated. The principal layer is what they were all silently assuming and none provided.
Verifies that a principal's credential satisfies an access condition, gates the protected resource, and conceals the existence and topology of authorization from observers. Zero-knowledge is concentrated here (§3). OVA's distinctive claim (per its patent and OVA_PROTOCOL_SPEC_V3.md) is cryptographic indistinguishability of authorization objects and topology concealment — hiding not just what is permitted but whether an authorization structure exists and its shape. OVA verifies credentials; it never issues, assigns, persists, or revokes them (§2). It has no identity model and conceals identity by design.
Confirmed: OVA V3 has no dependency on Kaspa vProgs — the spec states synchronously-composable verifiable programs are "a possible future migration target and are not a dependency of this specification." OVA runs on the Toccata KIP-16 ZK opcode. The earlier "OVA awaits vProgs" framing was documentary (two docstring comments), never a code dependency.
Records what was done, tamper-evident, as an independent product OVA and others write to. The existing deployments are reference, not foundation: foray.dunin7.com (Intel Mac Mini) is a purpose-specific persistence deployment, and foraychallenge.dunin7.com (M4) is a no-persistence showcase. Neither is the generic, reusable substrate Loomworks needs. The work is a new generic FORAY implementation (SDK/API) designed for reuse, of which Loomworks is the first consumer and which is also generally available. Off-chain attestation, hash-chaining, and persistence are already built and runnable in dunin7-foray; the engine seam is pre-wired (a no-op _foray_reserved_emit() with ~11 call sites). On-chain Kaspa anchoring is separately unbuilt and optional — FORAY works off-chain without it.
Remembers (the engagement-memory pipeline), governs (the Operator assigns/revokes roles and drives the pipeline), and produces (the rooms, the Companion, customization, agents). Loomworks is a consumer of the principal layer, OVA, and FORAY — not their owner. So is any other future consumer.
> The principal layer establishes and persists who. Loomworks identity is that principal's door (authenticate the person in). Credential minting issues verifiable claims about a principal. OVA verifies those claims and gates and conceals access. FORAY records what the principal did. Loomworks governs (assigns/revokes roles, drives the pipeline) and produces. Four products; Loomworks consumes the other three.
Confirmed total across every OVA document: OVA has no credential issuance, no credential/role revocation, no principal→role assignment, and no identity store. It defines the shape a credential must match (a role identifier in the ACL's role list; an attribute key-value pair in the ACL's attribute map) and verifies possession by zero-knowledge, with proof generated entirely on the requester's local device. But who issues a credential, who assigns a principal to a role, and how a role is revoked when someone leaves are nowhere in OVA — by design. OVA's only revocation is resource-side: revoke the egg, re-provision its ACL, expire it, or force re-acquisition. To cut off a departed member you change the resource, never the person — because OVA holds no record the person ever held anything.
The missing principal/credential layer was surfaced four independent times before it was named once:
Four questions, one missing component. When the same gap appears from four directions, it is an unbuilt component, not four separate gaps.
If FORAY and OVA are usable by anyone without Loomworks, then a non-Loomworks OVA consumer faces the identical credential gap and has no Loomworks to fill it. So the principal layer cannot live inside Loomworks — it must be its own product at OVA's level, with Loomworks as one consumer. The products' own independence drags the principal layer out to their level.
The credential lifecycle splits by the recurring principle (§4): the principal product owns the mechanism (persist principals, hold role/attribute bindings, mint credentials, revoke, authenticate — including a non-human agent identity). The consumer governs (who gets which role, when to revoke — for Loomworks, the Operator's authority). Mechanism is shared and extractable; governance stays with the consumer. This is why the principal product is a product (mechanism) and role assignment is still Operator governance (consumer).
Agents cannot act today not because of OVA and not because of the data-layer commit rule (R-B20 is a separate, permanent Operator-final-authority guarantee — see §6), but because there is no persisted, authenticatable agent principal for an agent to be. "An authenticated non-human agent identity over HTTP" is absent. The principal layer is what gives an agent something to be. Therefore "agents soon" means "principal layer soon" — it is on the near critical path, not a deferred concern.
Zero-knowledge is real and durable — it proves something true without revealing the thing itself, a permanent need, and its cost curve has crossed into practicality. But "real" does not mean "everywhere." Most of the Loomworks architecture wants the opposite of concealment: provenance reveals origin by design; FORAY's audit is meant to be verifiable, not hidden; an Operator must plainly see their own team to govern it. ZK is local to the authorization concern, not fundamental to the whole system.
> Concentrate zero-knowledge in OVA, where concealing the shape of authorization is the whole product and the moat. Keep it out of the principal layer, which is an ordinary transparent store with strong isolation and encryption-at-rest. Leave a named seam where cross-consumer concealment could later borrow OVA's ZK substrate if a real threat appears.
The principle is match the defense to the value of what is defended. OVA's payload — authorization topology — is the crown jewel; it earns the expensive vault (ZK, indistinguishable objects, topology concealment). The principal registry holds identities and role names — valuable but ordinary; the proportionate defense is strong isolation between consumers plus encryption-at-rest, not ZK.
Three observers, three correct answers:
Spending ZK on the principal layer would also be self-defeating in practice: the Operator's routine roster view would either pay the full ZK tax or require a parallel transparent view anyway — two builds for one job, with the ZK half mostly in the way. Building it ordinary keeps the Operator's normal use instant and spends the finite, hard ZK budget entirely on OVA, where it is the differentiator.
The only place ZK may later enter the principal layer is the cross-consumer seam — if one consumer learning the size or overlap of another's principal set turns out to be a real harm in an adversarial or regulated market. Build ordinary isolation now; confirm the threat is real before paying for ZK there. Do not pre-pay for an unconfirmed threat. The seam is named so it can attach later without rework.
ZK being a real, powerful, expensive tool is the reason to concentrate it, not spread it. Diluting it across every store would weaken the one place (OVA) where it is the moat. Discipline about a real tool is aiming it at the decisive point, not spreading it thin.
One principle held across every decision in this arc and in the method work that preceded it: mechanism is shared and extractable; governance stays with the consumer (for Loomworks, the Operator). Instances:
This is the same source-supplies / Operator-governs principle named four times in the skill/method standing note (v0.6, §2.1/§5/§7/§9.4) and flagged there as a v0.21 methodology consolidation candidate. The four-product architecture is its largest application yet.
The four-product conclusion was reached through a sequence of corrections, several of them the Operator correcting a framing mid-thought. Preserved so the path is walkable.
The destination is right and not merely last because it obeys the principle the whole architecture already runs on (§4) and because every piece of the principal layer already exists scattered (Loomworks UUID identity, recovery codes, declared agent actor kinds) without a coherent home — the conclusion consolidates existing scope rather than inventing new capability.
Settled.
Open (named, not decided here).
The principal layer (§1.1) raised an obvious question: identity is the classic "don't roll your own" domain — should the principal layer be delegated to a mature open-source identity platform rather than built? A Claude Code survey of the field (2026-06-13) settled it.
The seed's authentication framework eliminates most of the field. Of ten platforms surveyed, six failed the hard filter — identity must be the UUID, email optional and never identity/lookup/recovery, passkey-native (SuperTokens, Logto, Zitadel, Casdoor, and others assume email-as-identity deeply enough that the seed eliminates them). Only Ory, Keycloak, and Authentik survive, and even they require configuring against their email defaults. The platform with the best agent model (Zitadel) fails the identity filter; the best-fit survivor (Keycloak) cannot set its internal id via API, forcing a two-UUID reconciliation against the seed's UUID-as-identity core.
Loomworks already owns the part delegation is best at. The engine already implements UUID identity, WebAuthn passkeys, TOTP, recovery codes, no-email sign-in, and SSO-redirect — seed-conformant, with the recovery work shipped 2026-06-12. The commodity human-authentication surface that an identity platform is most trusted and most scrutinized for is already built, already to the seed's shape.
The survey confirmed that the hard, distinctive parts are custom under every option:
So delegation would remove work already done (seed-conformant human authentication) and leave the hard parts custom anyway. The trust-signal benefit the question was chasing lands on the commodity Loomworks already owns.
> **Keep Loomworks's own identity layer — it is built and seed-conformant. Do not adopt a third-party identity platform as the principal store. Borrow only the agent-authentication standards — RFC 7523 (JWT bearer / private-key client authentication) and RFC 8693 (token exchange, the act actor claim for "acting on behalf of") — implemented inside Loomworks's own principal layer, not as a platform dependency.**
This keeps total seed-fit (no fighting an identity platform's email defaults), zero lock-in, and discards no working code, while closing the one genuine gap — a standards-based agent-authentication substrate, which today exists only as declared actor kinds. The standards are themselves a trust signal ("we use RFC 8693 token exchange") without the platform.
Agent authentication borrows standards (mechanism — standardized, shared); agent governance is built (the distinctive, Loomworks-specific part — the delegation contract, personal-side-as-principal, the R-B20 gate). This is the same mechanism-shared / governance-with-the-consumer cut the whole architecture runs on (§4): the standardized authentication pattern is the extractable mechanism; the delegation governance is what only Loomworks can provide. The principal layer is therefore built by Loomworks, conforming to open standards where they exist (WebAuthn/TOTP for humans, RFC 7523/8693 for agents), distinctive where the architecture requires it (OVA credentials, delegation governance).
The principal layer is named Stele, pronounced "steel." A stele is an upright stone slab bearing an inscription — historically a name, a law, or a record made permanent. The name carries two meanings, both apt for a principal layer: the inscribed stone that bears a name permanently (the identity-and-record sense, sitting beside Tessera and FORAY in the DUNIN7 records-and-attestation motif), and — by its chosen pronunciation — steel, the hardened structural spine the whole architecture stands on. The classical pronunciation is "stee-lee"; DUNIN7 sets the pronunciation as "steel." The spelling-said-"steel" gap is a one-time point of product lore, not a liability: the spelling (clean and uncrowded in-sector) is what is typed and searched.
Stele was selected after searching nine candidates (Signet, Cachet, Crux, Etch, Tattoo, Plinth, Holdfast, Lodestone, Stele) across product collisions, package namespaces, domains, trademark, and DUNIN7 fit. Most were eliminated: the obvious identity/authority names are taken (Signet has live agent-identity products; Plinth — initially the frontrunner — has a live same-sector identity/authorization/audit product at plinth.run and a live US Class 9 software trademark; Lodestone, Holdfast, Crux are crowded in security; Cachet and Etch are established software names; Tattoo collides with tattoo-studio software and the contested "tattoo recognition" biometric meaning). Stele was the cleanest survivor: no same-sector live product, no live exact-literal tech trademark surfaced, a dormant-empty GitHub handle, and the best thematic fit to the estate. Hosting resolves by estate convention at stele.dunin7.com; open source under github.com/DUNIN7, which sidesteps the unrelated dormant GitHub handle.
Gate before public use. The trademark pass to date is a surface check only. It surfaced no registered exact-literal tech mark but flagged common-law tech uses worth running down ("Stele Infotech," a "Stele Tech" domain platform). A proper trademark knockout by counsel (USPTO live marks, Nice classes 9 and 42, plus a common-law and business-name pass) is the gate before the name is used publicly. The name is committed for internal use now; public use waits on counsel.
Stele is not bolted onto the Companion; it is the name for a chokepoint that already exists in the engine. Today there is exactly one place where "who is acting" is established for the Companion — the dependency that resolves the session to a person — and the whole chain runs: session cookie → resolve-current-person → person record → actor-construction helpers → an actor reference on every recorded event. Everything the Companion records flows through that one line.
Stele slots in under that line, at two points, leaving the Companion unchanged above it:
Three facts make Stele a named extraction rather than a new build: the person record is already the principal record (UUID is the identity; email and mobile are nullable and non-identifying — the seed's no-email-identity framework is already in the schema); the three credential kinds already exist, all keyed by the person's identifier and none by email (passkey, TOTP secret, recovery codes); and the authorization seam already carries a documented stable interface that OVA will replace. The genuinely new construction is the agent-authentication path (RFC 7523 / 8693 — see §7), which closes the "no principal for an agent to be" gap.
Unchanged by Stele, deliberately: the Companion above the resolve line; OVA, which replaces the authorization seam beside Stele; and the human-commit gate (R-B20), which stays independent and permanent. Stele gives an agent a principal to be and to act and propose as; the final commit remains a human/companion act regardless.
All new code runs on the M4. The first form of Stele is likely an extracted, named module inside the engine — most of it already lives there as engine code (the person record, the credential tables, the actor helpers, the authorization seam) — which lifts out into its own service when a second consumer (beyond Loomworks) needs it. This is the same extract-when-a-second-consumer-appears pattern applied to the credential-minting plumbing (§2.4).
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks standing note — the four-product architecture and where ZK belongs — v0.3 — 2026-06-14