Auth-to-Control adoption

TrustPlane Auth is the customer-side data plane. It is a deployable runtime that protects requests locally at adapters, gateways, sidecars, middleware, and services. Auth must remain useful by itself for local development, offline verification, signed local bundles, and manually operated deployments.

TrustPlane Control is SaaS-first fleet governance. It manages lifecycle, distribution, evidence, approvals, and status for many Auth deployments across clusters, regions, environments, edge nodes, teams, and business units. Control is not a hot-path runtime dependency and is not paired one-to-one with a single Auth instance.

Adoption path

1. Protect one API with the adapter.
2. Add signed trust and policy bundles.
3. Expand to more routes, sources, agents, teams, and environments.
4. Feel the operational pain of manual signing, source lifecycle, revocation, audit evidence, ownership, approvals, RBAC, compliance posture, and fleet status.
5. Connect Auth fleets to Control when governance and managed lifecycle become valuable.

This path preserves Auth usefulness. A team can continue to operate Auth manually with local signed bundles. Control improves governance and operations; it is not required for local/manual operation.

Product packaging

Package	Role	Boundary
TrustPlane Auth	Deployable customer-side runtime	Protects requests locally with adapters, verifiers, brokers, signed bundles, route/source policy, replay checks, and audit-ready allow/deny outcomes. It can run without Control.
TrustPlane Control	SaaS-first governance for many Auth deployments	Manages bundle distribution, revocation, audit ingestion, approvals, RBAC, policy history, fleet inventory, heartbeat, and status across Auth fleets. It is not called synchronously for each protected request.
TrustPlane Enterprise	Commercial packaging	Control plus support, hosted distribution, audit/compliance evidence, SSO/RBAC/approvals, policy history, fleet status, and SLA posture.

The packaging narrative is not "one Auth instance gets one Control Plane." A Control tenant can govern many Auth fleets and deployments.

Hot-path boundary

Protected request handling remains local:

request -> local Auth -> upstream

An acceptable Control integration is asynchronous or out-of-band for the request path:

Control -> signed bundles / revocations / policy history -> Auth deployments
Auth deployments -> audit events / heartbeat / status -> Control

This keeps the runtime portable across clusters, VMs, edge nodes, restricted networks, and customer-managed environments.

OSS boundary

• Auth remains independently useful without Control.
• Control does not become required for local or manual operation.
• No enroll, onboard, control, or Control administration commands are added to the OSS trustplane CLI by this docs foundation.
• No Control runtime implementation is added here.
• No SDKs, deployment repository changes, infrastructure changes, workflow changes, cloud changes, release, tag, push, or PR are part of this docs task.