DUNIN7 · Loomworks · Body of Work Brief · v0.2 · 2026-06-14 · Operator-facing
The principal layer — the part of Loomworks that knows who you are and proves it. This brief is the plain-English frame for the work: what Stele is, why it is worth building, how it sits against the field, what the work actually is, and what "done" looks like.
> In one paragraph. Every product Loomworks depends on assumes there is a someone acting — a person, or an agent acting for a person. Today that "someone" is established by scattered code inside the engine. Stele is the work of turning that scattered code into a clean, named product: an identity layer that creates and remembers who you are, authenticates you by passkey, manages your credentials, and — the new part — gives an AI agent a real identity of its own so it can act on your behalf. Stele is one of the four products that make Loomworks operational (alongside OVA, FORAY, and Loomworks itself). This brief describes the whole endeavour; the precise technical specification and the step-by-step build plan live in two companion documents, pointed to at the end.
A doorway and a record of who is allowed through it.
Stele does three things, and only these three things:
The name fits the job twice over. A stele is an upright stone that bears an inscribed name, made permanent — which is what an identity layer does. And said "steel," it is the hardened structural spine the whole system stands on. Both meanings are exactly right for the part that holds who.
Example — what Stele does in a single sign-in. You open Loomworks. You tap your passkey. Stele checks it, asks for your authenticator code, and — once both check out — hands back a session that says "this is principal #a1b2, signed in, valid for 24 hours." That session carries only your identity number and the fact that you're verified. It carries no email, no roles, no permissions. Everything else gets looked up when needed. That is the whole of Stele's job in that moment: prove it's you, and say so in a way the rest of the system can trust.
Because three other products are quietly leaning on it, and one of them can't stand up until it exists.
Stele's identity code already exists inside the engine — it was just never named or given a clean edge. So why do the work of pulling it out into its own product? Three reasons:
OVA verifies that a principal is allowed to do something. FORAY records what a principal did. Loomworks governs what a principal may reach. All three assume a principal already exists — and none of them creates one. Stele is the thing they were all silently relying on. If OVA and FORAY are to be usable by anyone (which is the plan — they are independent products), the identity layer they assume has to be a real product too, not a Loomworks-only convenience buried in the engine.
This is the urgent reason. Loomworks is about to introduce Companion Agents — AI agents that act on your behalf. An agent acting autonomously needs a verifiable identity of its own: a way to prove "I am this agent, authorised to act for this person." That mechanism does not exist today. An agent currently has no real identity to be. Stele is what gives it one. So the moment you want agents, you need Stele — they arrive together.
Example — why an agent needs its own identity. Imagine your Companion Agent drafts a document for you overnight. When it saves that draft, the system has to record who made it — and the honest answer isn't "you," it's "your agent, acting for you, under this authorisation." Without a real agent identity, the system can only pretend the agent is you, which erases the distinction that matters: a human reviewed and committed this versus an agent proposed it. Stele gives the agent a first-class identity so that distinction is preserved, truthfully, on every action. (And the final "commit" still requires a human — the agent can propose, never commit. That guarantee lives in Loomworks, not Stele, and stays permanent.)
Identity is the most security-critical code in the whole system. Buried inside the engine, you can only test it by running the entire engine around it. Pulled out as its own product with a clean front door, you can stand it up alone and hammer on it directly — create a principal, register a passkey, sign in, revoke a credential — touching nothing else. For a security layer, that isolation isn't a nicety; it's how you earn the right to trust it.
There are two kinds of competitor. Stele lives in the gap between them — deliberately.
We scanned the identity market to make sure Stele is complete where it should be and restrained where it should be. Two categories of product exist today:
The clearest example is Ory Kratos — an API-first identity server that does registration, login, recovery, sessions, and a broad menu of credential types (passwords, social login, email/SMS magic links, passkeys, authenticator codes, recovery codes). This is the right comparison for Stele's human side, and it gives us the checklist for what "complete" means.
But Stele is deliberately narrower here — and that narrowness is a feature. Loomworks's security posture rejects most of that menu: no passwords, no email-as-identity, no email/SMS magic links (because email is never identity). Stele keeps the strong, phishing-resistant subset — passkey, authenticator code, recovery codes — and drops the rest on purpose. Stele is not "Kratos with features missing." It is the opinionated, hardened subset the seed demands.
A hot, well-funded category (Oasis, Astrix, Entro — Oasis alone raised $120M this year). But look closely at what they do: they discover, monitor, and govern the machine credentials that other systems issued — API keys, tokens, service accounts. They are a governance overlay. **None of them is the thing that issues first-class identity to an agent.** The industry's own 2026 consensus is that agents need first-class verifiable identities and traceable delegation — and that this layer is still being built.
That gap is exactly where Stele sits. Stele issues first-class identity to both humans and agents under one model. It is the issuer the market says is missing, not the governance overlay the market already has plenty of.
> The position, plainly: Kind-one products do human identity but have no real answer for agents. Kind-two products govern agents but don't issue them an identity. Stele is a single principal layer that issues first-class identity for both humans and agents — narrower than Kratos on credential types by design, and doing the agent-issuing job the well-funded agent-governance crowd doesn't do.
The competitors blur "issue identity" together with "authorise actions" and "monitor behaviour." Loomworks keeps these separate on purpose. So Stele's scope is fenced:
Stele issues and authenticates. It does not monitor, score, or govern. Keeping that line sharp is what keeps Stele a clean product instead of sprawling into everything.
Mostly careful moving, with one genuine new build and one real refactor.
The encouraging finding from mapping the actual code: most of this is extraction, not invention. The identity code exists and works; the work is giving it a clean front door and filling a few real gaps. Here is the whole body of work, in plain terms.
Define Stele as a set of clean requests and responses — "authenticate this person," "tell me who this session belongs to," "register a passkey," "revoke this credential," "mint a new principal," "give this agent an identity." This front door is shaped like a web API even though, at first, it runs inside the engine — so that later, when a second product needs Stele, turning it into a standalone service is just "put a network under the door," not a rewrite. (The precise contract is written in the companion technical document.)
Pull the identity rows, the credential storage, the passkey/authenticator/recovery logic, the session handling, and the actor construction into a named Stele module. The reassuring part: the two scariest-looking numbers — the 119 places that ask "who is signed in?" and the 93 places that use the identity to label an action — don't change at all, because Stele slots in underneath them. Most of the work is mechanical moving and updating where code is imported from.
Measuring Stele against a complete identity layer surfaced two holes in today's code that a finished product must close:
Choosing to define the complete contract — including these gaps — is the right call precisely because we control the first use case (the Companion). We get to design the whole ecosystem thoughtfully and prove it against a consumer we also build, rather than reverse-engineering a contract from whatever the first integration happened to need.
Today, creating an account does several things in one inseparable step: it mints the principal (Stele's job) and sets up the person's memberships and personal workspace (Loomworks's job). Pulling Stele out means cutting that into "Stele mints the principal" → "Loomworks sets up the account." This is the one place that is genuine design, not mechanical moving, because it raises a real question: what happens if the account setup fails after the principal already exists? This gets its own careful, isolated step.
Example — why the sign-up split needs thought. Today, signing up is all-or-nothing: either you get a principal and a workspace, or nothing. Once Stele mints principals separately, you could end up with a principal that exists but whose workspace setup failed halfway. That's not necessarily bad — it just has to be a defined, recoverable state, not an accident. Because Stele is meant to stand on its own eventually, the cleaner long-term choice is to let the principal exist and have the workspace setup heal afterward — rather than welding the two back together in a way that won't survive Stele becoming a separate service.
Everything above is the human side. The new construction is giving an agent a real, verifiable identity — using established open standards (the same token-exchange standards the industry is converging on) rather than inventing our own. This is what unblocks Companion Agents, and it's sequenced after the human-side extraction is solid.
With passkey-revoke and authenticator-rotate now defined, finish the "how do you get back in when you've lost a factor" story — inside the now-clean Stele boundary, where it's a matter of completing a defined module rather than untangling scattered code.
Lowest-risk first, so the boundary is proven before the one hard part.
| Phase | What happens | Risk | |---|---|---| | 0 | Stand up the Stele module; move the pieces nothing else touches (credential storage, recovery, authenticator, passkey ceremony, session encode/decode) | Lowest — proves the boundary | | 1 | Move the identity records and the principal view; update where they're imported from | Low, wide, mechanical | | 2 | Move the actor construction (how an action gets labelled with who did it) | Low, contained | | 3 | Point "who is signed in?" at Stele — its name and shape unchanged, so the 119 callers don't move | Low to move, but test the full sign-in path hard | | 4 | Split sign-up: Stele mints the principal, Loomworks sets up the account | The one real refactor — its own scrutiny | | 5 | Complete recovery + build passkey-revoke and authenticator-rotate, inside the clean boundary | New build, into a defined shape | | Later | Build agent identity (token-exchange standards) and the agent actor path | The new construction; unblocks agents |
Every phase is committed separately, paused for your review before anything is pushed, and tested against the real database — not just the test suite. The auth path is tested hardest.
The outcomes this work delivers.
stele.dunin7.com, open-sourced under DUNIN7.There are two milestones, not one, and naming the second keeps the plan honest. Milestone one: Stele works for the Companion — running inside the engine, with Loomworks as the only consumer. Milestone two: Stele is offerable to an outside group — and that is the milestone where Stele becomes genuinely standalone.
The natural first external test is a local technical audience — for example, a Claude Code Miami developer group. It is close to an ideal first outside consumer: they are technical enough to integrate against the contract and file real feedback, and — crucially — they are a second consumer, which is the exact forcing function the architecture has been waiting for. Several pieces of work were deliberately deferred "until a second consumer needs it" (turning Stele into a reachable service, and splitting the identity data away from Loomworks's account data). A real outside group with a date attached is what turns those deferrals from "someday" into "now," and de-risks them — you extract because a concrete consumer is going to use it, not on speculation.
It is also the honest test of the contract. The Companion is a consumer we control — excellent for designing the contract, but weak for proving it, because we will unconsciously shape both sides to fit. A stranger building on Stele without us in the room is the real proof: if they can, the contract is genuinely good. And a local group using the open-source Stele (at stele.dunin7.com, under DUNIN7) is the start of the adoption story — first real users, first feedback, possibly first contributors.
Example — the gap between the two milestones. The day Stele works for the Companion, an outside developer still can't use it — there's no door to knock on (it runs inside the engine), and the principal records still carry Loomworks-only account fields a stranger's data has no business holding. Offering it to Claude Code Miami is exactly the work of closing that gap: stand Stele up as a reachable service, split its identity data clean of Loomworks's accounting, and hand over a contract a stranger can hit. That's not a far-off afterthought — it's the very next milestone, and the local group is the reason to take it.
One caution: don't offer it the day the Companion works — offer it after the service extraction and data split, or every integrator gets hand-held through an in-process module that was never built to be reached from outside, and the "test" measures patience rather than quality. The right moment is: Companion-proven → service-extracted → data-split → then a clean contract a stranger can hit.
This brief is the readable frame. The precise specifications live here.
loomworks-stele-integration-design-v0_1 — The complete API contract: every operation, its exact request and response, marked live (exists today) or to build — plus the host integration contract (how the Companion, and later OVA/FORAY/others, consume Stele) and the in-process-first implementation path.
loomworks-stele-extraction-scoping-note-v0_1 — The step-by-step extraction plan: the exact code boundary (what moves, what stays, what's referenced), the phase order, and the sign-up refactor decision — grounded in the real coupling map of the engine.
The decisions waiting on you, before this becomes an executable change request: approve the contract surface, and choose how the sign-up split handles a failure after the principal is minted (the recommended path is to let the principal exist and have account setup heal afterward — the choice that survives Stele becoming a standalone service).
DUNIN7 — Done In Seven LLC — Miami, Florida Stele — Body of Work Brief — v0.2 — 2026-06-14