Your Stack, Their Brand
White-labeling is the quietest business model in sovereign infrastructure: you build the stack, someone else puts their name on it, and both of you win. The customer gets a product without building infrastructure; the fleet gets revenue without building a brand. But white-labeling a sovereign stack is not the same as white-labeling a generic SaaS product. The stack’s core promise — verifiable, sovereign, local-first operation — is exactly what the white-label partner’s customers care about, and the label change must not dilute the verification.
What the white-label partner actually buys
The partner is not buying software. They are buying the ability to offer their customers a sovereign product — local-first AI, agent services, verifiable operation — without building any of it. The fleet’s job is to make the product theirs: their logo, their dashboard, their documentation, their support channel — with the fleet’s machinery underneath.
The S6.7 customer dashboard becomes the white-label surface. The partner’s customers see the partner’s brand; the dashboard’s internals — the agent status, budget, audit slice — remain the fleet’s. This is the same multi-tenancy boundary described in S7.14, extended by one level: the fleet serves the partner, the partner serves the customer, and both boundaries are enforced by the same key architecture.
The brand boundary is a trust boundary
The critical design rule is that the white-label surface never touches the fleet’s own identity. The partner’s dashboard is served from the partner’s domain, backed by the partner’s keys, showing the partner’s branding. The fleet’s identity appears nowhere in the customer’s experience — not in the URL, not in the emails, not in the audit records the customer can inspect. The S7.8 email perimeter is configured per white-label domain: SPF, DKIM, and DMARC for the partner’s domain, signed by the partner’s keys, administered by the fleet’s automation. The partner’s customers verify the partner’s identity, not the fleet’s.
This is not cosmetic. If the fleet’s identity leaks into the white-label experience, the partner’s customers discover they are actually buying from someone else, and the trust the partner built with them transfers — badly — to the fleet. The brand boundary is a trust boundary, and the key architecture is what enforces it.
What the fleet gives up
White-labeling has a real cost: the fleet does not build customer-facing brand equity. The customers of a white-label partner never learn the fleet’s name. This is a deliberate trade. The fleet’s brand is the audit layer and the verification story — the claim “we can prove what our agents did.” A white-label partner amplifies that claim without the fleet having to run a consumer brand. The trade is revenue now for visibility later, and it is a good trade when the underlying machinery is strong enough that verification is the product.
The verification story survives the label
The white-label partner’s most valuable asset is the audit slice. The partner can show their customers the same immutable ledger the fleet shows its own — chained, verifiable, tenant-scoped (S7.15). The label changes; the ledger does not. A customer who verifies a ledger entry signed by the partner’s key is verifying the partner’s operation, and the verification works because the machinery underneath is real. This is white-labeling done right: the partner is not reselling a promise, they are reselling a mechanism.
Operational reality: support, upgrades, incidents
White-label agreements live and die on operations. Three realities shape the contract:
- Support tiers. The partner’s customers contact the partner; the partner escalates to the fleet. The escalation is a handoff, and it follows the same discipline as agent handoffs (S7.3): signed, scoped, recorded. The partner can always verify what the fleet did on their customers’ behalf.
- Upgrades. When the fleet ships a new capability, the white-label partners decide when to adopt it. The catalog (S6.4) gives them the choice: each capability is a catalog entry they can enable, priced and evidenced. Upgrade is a business decision, not a forced migration.
- Incidents. When something fails on a white-label tenant, the recovery discipline (S7.11) applies with the partner’s brand on the front. The partner’s customers see the partner’s incident response; the fleet’s runbook runs underneath. The audit slice is the shared source of truth both sides use.
Why white-label is a sovereign business
The white-label model fits sovereign infrastructure because it does not require the fleet to compromise its architecture for market fit. The stack stays local-first, key-scoped, and audited; the brand layer is configurable by design. The S6.8 tiered pricing maps cleanly: each white-label partner is a tenant with a tier, and each tier’s geometry defines what their customers can reach. The fleet’s doctrine — one gate, one board, one orchestrator — holds for every partner simultaneously, because the multi-tenancy boundary (S7.14) was built for exactly this.
Grounded in wiki concepts white-label, multi-tenancy, subscription-model, platonic-solid-access-architecture, immutable-logging, and the S6 + S7 series. Design notes on a running system.
