Loomworks person layer — Discovery record v0.1

Version. 0.1 Date. 2026-04-25 Status. Discovery record. Captures the trajectory of decisions reached in the Phase 13 / 13A scoping and close-out session regarding the person layer, identity model, domain declaration, designations, and account recovery. Raw material for a future phase scoping note and CR. Provenance. Claude.ai session, 2026-04-25. Operator: Marvin Percival.

The question that opened this

After Phase 13 (four UI surfaces) and Phase 13A (real TOTP) were complete, the question arose: how does a new Operator, Contributor, or Domain Expert get credentials? The answer was: they can't — not through the product surface. Phase 13 built a single-Operator product. The substrate has no concept of a "person" that exists outside of engagement-scoped contributor rows.

This led to a structural inquiry about identity, onboarding, designations, domains, and recovery.

Decision 1 — The person layer comes first

Prior position. Phase 13 deferred identity to a future phase. The substrate has only engagement-scoped contributor rows — no cross-engagement identity, no "person."

Settled position. The person layer is the foundation. A person must exist before they can hold memberships, receive invitations, or carry designations. Build order:

1. Person layer — a human being exists once in the system.
2. Membership layer — a person's relationship to a specific engagement, with stackable designations.
3. Invitation — an Operator invites a person to an engagement.

The person layer is the next phase.

Decision 2 — Self-service is the front door

Considered and rejected: invitation-only. If the first touchpoint always requires an invitation from someone already in the system, then DUNIN7 is the only authority that can bring people in. The Operator explicitly rejected this — "DUNIN7 cannot be the only authority that can invite someone."

Settled position. Anyone can come to Loomworks and create an account. Self-service signup is the first interaction. A person arrives, registers, and exists — before they have any engagements, before anyone invites them anywhere.

What signup collects:

• Name. Required.
• Passkey registration. Required. This is the primary credential. Real WebAuthn — this is the phase where the "Sign in with passkey" button becomes what it always said it was.
• TOTP setup. Required. Second factor. The mechanism from Phase 13A carries forward, but the secret moves from the contributor row to the person row.
• Email and/or mobile number. Optional. The person is told: without a contact method, no one can invite you by lookup and the system can't reach you. That's their choice. Not a credential — a contact handle.
• Recovery codes. Generated at signup. One-time codes the person stores in a password manager (LastPass, 1Password, etc.) or prints. The system generates them and never sees them again.

What the person is encouraged to do: register at least two passkeys on separate devices. The product surface should say this clearly.

Decision 3 — The welcome page, not the empty dashboard

Prior position (implicit in Phase 13). After sign-in, the person lands on the dashboard.

Settled position. After first-time signup, the person lands on a welcome page — not the dashboard. This is an arrival, not a workspace. The welcome page is ceremonial (vertical lockup, same register as the landing page) and tells the person:

• What Loomworks is and what they've gained access to.
• What engagements are and how they work.
• What designations mean (Operator, Contributor, Domain Expert) — per-engagement and stackable.
• What doors are open: create an engagement (become its Operator), enter an invitation code, or proceed to the dashboard (which may be empty, and that's fine).

The welcome page is the product's first conversation with a person who has chosen to be here.

Decision 4 — Designations are per-engagement and stackable

Prior position. The substrate has commit_authority (boolean) as the only role signal on contributor rows.

Settled position. Designations are:

• Per-engagement. A person holds designations within the context of a specific engagement, not globally.
• Stackable. A person can be Operator + Domain Expert on EngagementA, just Contributor on EngagementB, Contributor + Domain Expert on EngagementC.
• Not a single enum. Independent boolean flags (or a set), not a dropdown.
• Extensible. The system shouldn't assume exactly three designations. Three exist today; more may come.

The three current designations:

• Operator — commit authority, governance, can invite others into the engagement.
• Contributor — participates, adds knowledge.
• Domain Expert — recognized expertise in a domain relevant to the engagement. The badge from the UI exploration session.

Key insight from the Operator: "Operators, Contributors and Domain Experts may all be the same person. Therefore the person should be able to carry more than one (3+?) designation."

Decision 5 — Domains are person-declared, AI-assisted, Operator-recognized

Considered and rejected:

• (a) Engagement-derived. Domain is implicit in what the engagement is about. Too simple — doesn't let expertise compound across engagements.
• (b) System-level registry. Top-down taxonomy of named domains. Too rigid — who decides the taxonomy?

Settled position: (c) Person-declared, AI-assisted, Operator-confirmed.

The flow:

1. A person declares a domain in their own words (free text).
2. An AI agent examines the existing domain graph — all previously declared and recognized domains across the system.
3. The agent surfaces connections: overlaps, sub-domain relationships, near-duplicates.
4. The agent pre-populates a domain description and presents it to the person for approval.
5. The person reviews: adopt an existing domain, declare theirs as a sub-domain, edit the description, or insist on a new distinct domain.
6. The declaration is committed.
7. Recognition comes later, per-engagement, from Operators. An Operator on an engagement can recognize a person's declared domain expertise within that engagement.

Key principles:

• The AI doesn't gatekeep — it surfaces the topology so the declaration is informed rather than isolated.
• The agent drafts; the person confirms.
• Over time this builds an organic, connected domain graph without a top-down taxonomy.
• Recognition is load-bearing for the compounding thesis — a domain expert recognized across multiple engagements has compounding credibility.
• The domain-declaration agent is an agent behavior (requires interpretation and judgment), not a skill (bounded structural transformation). Fits the methodology's agent/skill distinction.

Decision 6 — Account recovery: your credentials, your responsibility

Considered and rejected:

• Admin-managed recovery. An admin who can restore access can impersonate you. Compromises security. Explicitly rejected by the Operator.
• (b) Peer recovery (M-of-N trusted contacts). Elegant but requires the person to have trusted contacts already in the system — which a new user doesn't. Worth keeping on the horizon for when the system has enough users for peer networks to form. Not buildable as the first mechanism.
• (c) Time-locked self-recovery via email/mobile. Explored but set aside in favor of simplicity. The person has standard credential stores available to them.

Settled position: (a) — the account is unrecoverable if all credentials are lost.

The system has no backdoor. The person is responsible for their credentials. Multiple passkeys on separate devices, TOTP in an authenticator app, recovery codes in a password manager or printed — all standard tools that already exist (LastPass, 1Password, etc.). No need for Loomworks to build a secure lockbox.

The product surface makes the stakes clear at signup:

• "Register at least two passkeys on separate devices."
• "Store your recovery codes in a secure place."
• "If you lose all credentials, your account cannot be recovered."

If all are lost, the person's engagements, memberships, and recognitions are orphaned. An Operator on each engagement can remove the orphaned membership and invite the person back under a new identity — but the history and recognition belong to the old identity.

Decision 7 — Three onboarding paths (built as engaged)

Three paths for how a person arrives in an engagement, built in order as each is needed:

Path 1 — Self-service signup + invitation (build first). A person creates their own account (self-service). An Operator on an engagement invites them by email/mobile/handle. The person accepts and is added to the engagement with the designations the Operator specified. If the person already has a Loomworks account, the new membership is added to their existing identity.

Path 2 — Org SSO. An organization connects its IdP. People from that org sign in with SSO and are provisioned into the engagements their org participates in. This is what "Organizational sign-in" on the landing page becomes when it stops being a toast.

Path 3 — Domain-based join (future). If an engagement is tagged with a domain, anyone with a matching declared domain can request to join. Lower priority — Loomworks engagements are considered and deliberate, not open-door.

Invite authority is distributed. An Operator on an engagement can invite people into that engagement. They don't need DUNIN7's approval. The system provides the mechanism; the Operator exercises the judgment.

Decision 8 — What happens to the existing substrate

Migration. The four existing contributor rows (Administrative, PartsPilot, FieldPilot, Agricultural Engagement) need to be repointed:

• A person record is created for Marvin Percival.
• The four contributor rows become membership rows pointing to the person record.
• commit_authority: true maps to the Operator designation.
• The TOTP secret moves from the admin-engagement contributor row to the person row.
• The multi-token auth bridge is replaced by passkey auth with engagement-scoped tokens derived from the membership.
• The dev-token bridge is retired.

What this Discovery does not settle

• The exact substrate schema for person, membership, and domain tables.
• The WebAuthn implementation details (registration flow, challenge-response, browser API integration).
• The invitation mechanism details (email delivery, invitation codes, link format).
• The welcome page's exact content and composition.
• Whether "create an engagement" is in scope for the same phase as the person layer.
• The domain-declaration agent's instruction set and domain-graph schema.
• How the existing four bearer tokens are retired during migration.

These are scoping decisions for the next session.

Platform research grounding

The person-layer and membership-layer separation is the universal pattern across Slack, Linear, Notion, GitHub, and every multi-tenant SaaS platform examined. The consistent structure: a person exists once (one identity, one set of credentials), memberships are scoped to workspaces/organizations, roles/designations live on the membership. Loomworks maps naturally: engagement = workspace, membership = per-engagement relationship, designations = per-membership role set.

All examined platforms support self-service account creation as the front door. Invitation is how people arrive in specific workspaces, not how they enter the system.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks person layer — Discovery record — v0.1 — 2026-04-25