Verify, Connect, Deliver
Onboarding is where trust is either built or broken, and for a sovereign-infrastructure business it is also where the architecture’s security model meets the customer’s first experience. A typical SaaS onboarding is a form: name, email, credit card, done. A sovereign onboarding is a ceremony: verify the customer, issue their keys, connect their tenant, deliver their first service — and every step leaves evidence. The customer is not just being admitted; they are being granted a scoped identity in a system that treats identities as cryptographic facts.
Step one: verify
Before the customer gets anything, the fleet verifies who they are. The verification is not a checkbox; it is the root of the trust chain. The customer’s identity is established through the same mechanisms the fleet uses for its own agents: a proof of control over a domain or email, a key exchange, and a recorded commitment. The S7.8 email perimeter participates here — the verification email is signed, authenticated, and delivered through the hardened DNS/DMARC chain, so the customer can verify the verification.
The output of this step is a customer identity: a cryptographic anchor that all subsequent access derives from. This is the human-side mirror of the child-agent key tiers (S7.6): a customer is a tier in the same hierarchy, with a key whose scope is defined by their plan.
Step two: connect
Once the customer is verified, the fleet issues their tenant. The connection step is where the multi-tenancy boundary (S7.14) becomes real for this specific customer: their tenant gets a scope in the key geometry, their dashboard (S6.7) is provisioned, their budget is allocated, and their access is recorded in the ledger.
Two properties matter here:
- Least privilege at onboarding. The customer starts with the smallest scope their plan allows. Upgrades expand scope; they never happen silently. The S7.12 least-privilege discipline applies to customers as well as agents — the geometry is the policy.
- Verifiable provisioning. The customer can see their tenant’s creation in the audit slice: when it was created, what scope it holds, what budget it carries. The dashboard is not a black box; it is a window into the ledger.
Step three: deliver
The delivery step is the first real service — the first article, the first report, the first deployed component. It is also the first test of whether the onboarding actually worked. The delivery should be a demonstration of the whole model: the task is routed through the board, executed by an agent whose key scope covers the customer’s tenant, and the artifact is delivered with its evidence trail (S7.15). The customer does not just receive a file; they receive a file plus the proof that the fleet’s machinery produced it.
The first delivery is deliberately small. A customer who survives onboarding gets a quick win — something concrete, verifiable, and useful — before any larger engagement. This is the same pattern the S8 simulation series describes for business models: test small, verify, then scale. Onboarding is the customer’s first simulation run, and it is run live.
The onboarding funnel as a security boundary
Onboarding is not just a UX flow. It is a security boundary: the point where an outsider becomes an insider. Every step must therefore be both friendly and rigorous. The tension is real — a ceremony with too many steps churns customers; one with too few lets attackers through. The resolution is automation: the verification, key issuance, tenant provisioning, and first delivery are all executed by the fleet’s own machinery, with the human reviewing only what the machinery flags.
The audit slice is what makes the tension resolvable. A customer who wonders “why do I need to verify my domain?” can see that the verification protects their own key — the domain control proves the key belongs to them, not to someone who grabbed an email address. The ceremony is not bureaucracy; it is the customer’s first lesson in why sovereign identity works the way it does.
What breaks onboarding
Three failure modes recur, and the fleet designs against all three:
- Scope creep at signup. The onboarding asks for more access than the plan needs, to “save time later.” This violates least privilege on day one. The fix is the plan’s geometry: the tier defines the maximum scope, and onboarding grants exactly that.
- Verification theater. The steps look rigorous but are not actually checked. The fix is mechanical: verification is enforced by the gate, not by a human clicking “approved.”
- First-delivery delay. The customer waits days for the first artifact, and the trust built in onboarding evaporates. The fix is a small, fast, automated first delivery.
Onboarding as the product’s thesis
The onboarding funnel is the S6 series in miniature: sovereignty as a product, verification as the differentiator, and the architecture as the sales pitch. A customer who goes through verify-connect-deliver has experienced the entire model — key-scoped access, audited operation, verifiable delivery — in the first hour. The funnel is not a gateway to the product; it is the product’s thesis made interactive. And because every step is recorded, the fleet can measure where the funnel breaks and improve it with evidence, not guesses.
Grounded in wiki concepts customer-onboarding, multi-tenancy, platonic-solid-access-architecture, immutable-logging, zero-trust, and the S6 + S7 series. Design notes on a running system.
