Choose a starting path

TrustPlane has two distinct planes: Auth enforces requests at the deployed API boundary, while Control governs sites, clients, policy, revocation, and Audit. For customer onboarding, start with the managed Auth Site guide, which links the full chapter sequence and its prerequisites.

Goal	Start here	What you need	What you will prove
Onboard a customer site	Start the Control journey	Control organization, new-site entitlement and capacity, DNS/TLS, Kubernetes, protected upstream, and site-scoped Control signer public key	Site ownership, target identity, Auth deployment and activation, client policy, a signed request and correlated Audit after a reviewed live installation.
Run a developer smoke	Local fixture smoke	A checksum-verified CLI archive, Python 3, localhost sockets	Disposable Auth behavior only: unsigned deny, signed allow, replay deny, changed-path deny. No Control Auth Site or Audit event.

Start with Install and verify. The CLI archive, adapter image, Helm chart, and SDKs have separate version numbers; the artifact reference lists the inspected pins. A published artifact does not by itself prove a new managed-site deployment.

The local exercise is an optional developer smoke. The managed guide’s pinned chart/image pair and first signed activation were validated on a disposable site in an existing tenant. For a new site, its tenant admin can pre-stage a narrow client and grant, publish and promote the first signed package in Control, then download the site’s signer public key before Auth starts. That pre-publication sequence is supported by the current code but still needs a fresh end-to-end rehearsal. Fresh-account signup was not part of the recorded exercise.