This record captures a strategic-direction discussion about Stele held on 2026-06-18 — what Stele is aiming to be in the identity market, how it should be licensed and distributed, what differentiates it, and how it relates to OVA and FORAY. It is written for two readers at once: as a Discovery record it preserves the trajectory of the discussion (including positions taken and then corrected, so the reasoning survives, not just the conclusions); as a heads-up for the Stele build chat it pulls the settled direction that bears on the current build phases to the front, so the build does not move in a direction the discussion has already turned away from.
Most important for the build chat, in one paragraph. The discussion settled several directions that touch what is being built right now (Phase 2 actor constructors just landed; Phase 3 session-resolution is next). The load-bearing ones: (1) OVA and FORAY call Stele; Stele never calls them — the dependency points inward, always. (2) The actor reference Stele produces should be treated as a clean, optional, zero-weight seed for authorization (OVA) and audit (FORAY) — present and consumable if those products are added, carrying no weight if they are not. (3) Email is a non-identifying attribute only — never authentication, never recovery; the no-email edict is reinforced, not relaxed. (4) The "Companion is the first consumer" framing is incidental, not a rule — the real first consumers are standalone test surfaces shipped in the repo. None of this changes Stele's scope fence: Stele still issues and authenticates only; it does not authorize, audit, or govern.
This record is direction, not a change request. Nothing here instructs a code change directly. Where it bears on the build, it does so as direction to hold and, in one case (the OVA/FORAY seed), as a design-check to verify against the live contract before acting. The build chat should read it as orientation, raise anything that conflicts with ground truth back to the Operator, and not treat any of it as a settled CR.
The Operator opened by comparing Stele to the identity field (Auth0, then Keycloak and SuperTokens) and pressing on what Stele is aiming to be — not its current build state, but its destination as a go-to identity product. From there the discussion moved through compliance posture, open-source and licensing, the true differentiator, the relationship to OVA and FORAY, the email edict, the testing and evaluation surfaces, and an example-generator idea. The Operator stated a clear ambition: make Stele a go-to product in the identity space, rock-solid in implementation, delivering value that seeds the authentication and audit flows of OVA and FORAY.
The discussion stayed deliberately in "discussion phase" — shaping direction, not producing change requests — with one concrete artifact produced along the way (the open-source/licensing decision memo, still staged for Operator decision and a legal read).
These are the positions the discussion arrived at and the Operator confirmed. They are stated as direction, with the reasoning that backs each, so the build chat understands why and not only what.
Stele will be open-source under DUNIN7 (already the brief's lean). The discussion sharpened that "open-source" is three decisions, not one: whether to open the source (yes), under which license (open), and on what timing (open). The recommendation: ship self-hostable immediately, publish under a protective license (source-available/BSL-style preferred, AGPL acceptable) at the Claude Code Miami milestone, and defer permissive licensing (Apache/MIT — what Kratos, SuperTokens, Keycloak use) until the agent-identity position is established and a security-review community exists. Reasoning: closed-to-open is always available later, open-to-closed is not, so start protective and open further when the position is held. Captured in full in the companion memo loomworks-stele-open-source-and-licensing-decision-memo-v0_1; license and timing remain the Operator's to decide, and a legal/IP read is required before any license is committed (the FORAY patent-pending and OVA provisional may interact with how an adjacent product is licensed).
The discussion separated two roles. Agent-identity — Stele issuing first-class identity to agents, the gap the brief's field scan identifies (issuers absent, governance overlays plentiful) — is the wedge: how Stele gets noticed in an underserved spot. The durable differentiator the Operator named is different: Stele as the identity layer purpose-built to seed a separate authorization-and-data-protection layer (OVA) and a separate pervasive-audit layer (FORAY) that were designed alongside it. No incumbent can tell that story, because none built the other two as adjacent products.
A correction the Operator made explicit (see §3.1): the differentiator is not a bundled "spine." OVA and FORAY are separate product offerings a solution builder may or may not adopt. Stele must stay only as heavy as necessary — it seeds authorization and audit if those products are present, and carries no weight when they are absent. This reinforces the brief's scope fence rather than straining it: Stele stays identity-only and lightweight; the seam to OVA/FORAY is a clean, documented, optional hand-off that adds nothing when unused.
The dependency direction is settled: inward. OVA (when added) calls Stele to learn who the principal is, then makes its authorization decision. FORAY (when added) takes the actor reference Stele produced and records the action. Stele knows nothing about either and is identical whether zero, one, or both are layered on. This is forced by three things already decided: zero-weight-when-unused (Stele calling outward would require it to carry machinery for products that may be absent); the dependency reality (the brief's own observation that OVA/FORAY/Loomworks all assume a principal exists and none creates one — a thing relied upon does not call its dependents); and the standalone bar (Stele must clone-and-run with none of them present, which is only possible if Stele calls nothing outward). The mechanism of the inward call — emit-vs-pull for FORAY's audit seed, where the authorization check sits for OVA's in-path decision, who holds the wiring — is reserved for a later long discussion, with the lean (consistent with the mint↔onboarding precedent) that the host or a thin adapter holds the wiring, never Stele.
Following from 2.2–2.4: the actor reference and principal contract Stele produces are the natural seed for OVA's authorization decisions and FORAY's audit records. The direction is that these should be first-class, clean seeds that stay light — not authorization or audit logic inside Stele (that would breach the fence), but outputs shaped so an authorization or audit layer can consume them cleanly, at zero weight when none is present. The ActorRef shape already carries capability_ref and approval_mode, which are the right kind of optional context. This is a design-check for the build chat to verify against the live contract (see §5), not a mandate — if the contract already seeds cleanly, nothing changes; if it does not, that is worth surfacing while the actor/session seams are being cut (Phases 2–3).
The no-email edict is on solid ground and reinforced. Email is a communication/convenience attribute: Stele may hold it (email: str?), a host may look up by it (find_by_email, explicitly non-unique and non-identifying), notifications may use it. Email is never identity, never a key, never an authentication path, never a recovery path. The Operator confirmed option A (attribute only) over option B (email as an auth/recovery path, which would have been a deliberate seed amendment). The reasoning that closed it: if any adopter needs email-keyed behavior, a host-side email→UUID alias is a trivial mapping any builder can write, and putting it inside Stele would corrupt the very UUID-purity that makes Stele worth adopting. The precise form the build chat must hold: email is not identity and never a key, but email may exist as a non-identifying attribute — do not over-read the edict and strip the attribute that compliance or host-integration legitimately wants.
The brief's "the Companion is the first consumer" is not an architectural rule — it is just what was nearest. The real first consumers will be standalone test surfaces shipped in the repo: (a) a basic web page holding the Stele SDK as a plugin, presenting raw sign-in results for review, and (b) a non-Loomworks agent that authenticates as itself and executes a known event, reporting every step. Both are stronger proof than a controlled-consumer integration, because they prove the contract to someone who knows nothing about Loomworks — which is exactly the standalone bar. This advances the standalone milestone rather than competing with it.
The two test surfaces are not internal scaffolding — they ship to anyone interested in the repo, as the evaluation on-ramp (clone, run, convinced). Two refinements landed:
A generator that asks a few questions (brand, locale, page/agent/both) and produces a ready-shaped instance for evaluation. The Operator chose A — a thin configuration generator that pre-wires the already-shipped surfaces with the answers (generates configuration and wiring, never new source); its low ceiling is the feature, and it demonstrates the white-label hooks by using them. B — a scaffold/source generator that emits tailored source the evaluator owns — is held as an earned future expansion, to be built when traction and interest justify carrying it as a second product. A and B share the same question front-end, so A is the first slice of B, not a throwaway: the sequencing is free.
One principle runs through every fork above and is worth naming as the spine of how Stele is being built: ship the smallest solid thing; keep the heavier move available but unbuilt until demand pays for it. Protective license now / permissive later; clean optional seam now / OVA-FORAY adopted when chosen; reveal-able app now / nothing heavier; config generator now / scaffold generator on traction. The build chat should read new decisions through this lens — when a question arises, the lightest option consistent with the standalone bar is almost always the settled direction.
Per discovery discipline, the corrections are preserved alongside the conclusions, because the reasoning is in the corrections.
Prior position (held by the assistant early): Stele's differentiator is an integrated Stele→OVA→FORAY spine — the bundled triple no incumbent can match. Correction (Operator): OVA and FORAY are separate offerings a builder may or may not implement; Stele must stay only as heavy as necessary. Resulting position: the differentiator is Stele as the identity layer engineered to seed authorization and audit optionally — clean seam when present, zero weight when absent. The corrected version is stronger and, crucially, reinforces the scope fence rather than straining it. This correction is the hinge of the whole discussion; several later decisions (2.4, 2.5, the keep-it-light through-line) follow from it.
Prior framing (assistant): compliance (HIPAA/SOC/PCI/GDPR) is something Stele would add later and have validated against the implementation; and a claim that Stele could "never be HIPAA certified." Correction (Operator + assistant self-correction): for a from-scratch standalone product, compliance-supporting structure is a design input decided now, not later validation. And "HIPAA certified" was both wrong wording (HIPAA has no software certification) and the wrong conclusion: a self-hosted layer built to the HIPAA Security Rule's technical safeguards is supportive of an operator's compliance, and self-hosting removes the third-party-BAA problem rather than creating a deficiency. Resulting position: Stele adopts compliance-supporting design requirements (not compliance claims), as design inputs — appropriate to an open-source, self-hostable product where there is no single deployment to certify. (A compliance/standards requirements note was scoped but not written; the discussion redirected to open-source. It remains the next candidate artifact, and is genuinely downstream of the license decision.)
Prior position (assistant): the evaluator-facing bare test page and the host-facing reference UI template are separate artifacts with opposite goals (reveal vs conceal the contract). Correction (Operator challenge): aren't these the same thing — and if not, can they be? Resulting position: one reveal-able reference app with a raw default and a brand-and-conceal mode. The difference between the two was real but on a single axis (reveal vs conceal); collapsing them into one artifact with a mode is lighter and drift-proof, and the reveal layer doubles as the builder's debugging view. A simplification that made the design smaller.
Prior framing (assistant, compressed): "the Companion is the first consumer; agent-identity unblocks it" — which mashed together two different ideas. Correction (Operator): the intended idea is the agent that acts holding its own first-class identity (Idea 2: the agent is a principal, authenticates as itself, acts and proposes under attributed identity, cannot commit), not the agent-as-test-plumbing (Idea 1). And "Companion is first consumer" is incidental, not a rule — the real first consumers are the standalone test surfaces. Resulting position: 2.7 and the agent definition in 2.2/2.8. This correction matters because Idea 2 is the underserved, differentiating capability, and conflating it with test-plumbing undersold it.
Early in the discussion the assistant reasoned about Stele from manifest summaries rather than reading the two canonical design documents (brief v0.4, integration design v0.2), which produced errors later corrected (importing a Loomworks non-erasure constraint into Stele; the "never certified" misstatement). The Operator supplied the documents. The lesson, consistent with the project's grounding discipline: read the canonical source before reasoning about the contract, and when a needed document is out of reach, ask for it rather than reasoning from summaries. This Discovery record's claims about the contract are grounded in the documents as read on 2026-06-18; claims about current code state still defer to the build chat's ground truth (see §5).
So the build chat does not over-read the direction above:
Phase 2 (actor constructors) is complete; Phase 3 (session-resolution) is next; the agent constructor (actor.for_agent / actor_from_agent) is unbuilt (64 inline sites, no constructor, per the Phase 2 completion record). Against that state, the items from this discussion the build chat should hold:
ActorRef's capability_ref / approval_mode) already seeds an authorization decision (OVA) and an audit record (FORAY) cleanly, carrying zero weight when neither is present. If yes, nothing changes. If not, surface it to the Operator while the seams are open — do not silently add seeding logic, and do not breach the fence by adding authorization/audit behavior. This is the one item that is a check rather than a directive.agent.authenticate are built, the target is a first-class principal that authenticates as itself and is attributed as itself acting for a person — not an agent borrowing the person's identity. This is the differentiating capability; build it as the real thing.Grounding caveat for the build chat. This record's claims about the contract are from brief v0.4 and integration design v0.2 as read 2026-06-18. Claims about current code state (symbol names, call sites, what is built vs unbuilt) defer to the live tree — the Phase 2 completion record already corrected several brief/contract names against code (actor.for_principal is actor_from_person; actor.for_agent unbuilt). Verify against ground truth before acting on anything here that touches code.
Not actions for now — the Operator kept this in discussion phase. Recorded so they are not lost: