Control plane
ENI6MA Control
AvailableControl (the control plane: a registry of active identities plus the durable nonce ledger; conceptually the token-issuer, revocation registry, and audit log for one-shot proofs combined) is where identity lifecycle and per-request state live. It is how Gate knows which identities are alive, which nonces are spent, and what just happened at the boundary. If Gate is the door, Control is the guest list and the ledger the guests sign as they go through.
Three pieces, one control plane
Registry, ledger, and visibility ship together because they are the same problem seen from three sides.
Control plane triad
Control plane triad: registry, nonce ledger, and observability
Registry
AvailableActivate, deactivate, and resolve identity handles. Revocation is a single state change on the handle in the registry, not a rotation campaign across every workload that once trusted a shared secret.
Nonce ledger
AvailableReserve, respond, commit. The nonce ledger (a durable append-only log that hands out single-use request tokens and records the moment each one is spent) burns the nonce before proof validation with a configurable TTL, defaulting to 300 seconds.
Visibility
AvailableBurn events, reject reasons, and access logs from Gate, surfaced for operators and auditors on the same channel a security team already uses.
What Control guarantees
Ledger burn flow
Reserve then burn then validate with duplicate reject at ledger
ENI6MA Control registry activates, deactivates, and resolves circuit handles for Gate checks.Shippingregistry-service at registry.eni6ma.net.
The Control ledger reserves and burns nonces before proof validation, so every submission spends the nonce.Shippingledger-service reserve/response/commit with NONCE_TTL_SECONDS 300.Holds under the reference architecture
Control visibility surfaces burn events and access logs from Gate for operational review.Shippingledger-visibility-service at ledger.eni6ma.net.
The burn-before-validate (the ledger records the nonce as spent before the cryptographic proof is checked, so a captured request cannot be re-submitted even if validation later rejects it) property is why replay does not survive the boundary, and it is why the ledger has to be durable, not a cache.
Deployment shape, failure mode, observability
For a sysadmin or SRE who needs to run Control in production.
Managed or self-hosted
Managed Control ships with the Team and Enterprise Gate subscriptions and lives at registry.eni6ma.net and ledger.eni6ma.net. Self-hosted Control is the Sovereign path, and is required for air-gapped estates.
Durable ledger
The nonce ledger is append-only, durable, and records τ (tau, the microsecond timestamp the ledger records when a nonce is reserved, bound into the proof so a captured envelope goes stale within seconds) at reservation, which is what makes the freshness window meaningful.
Failure mode
Gate is fail-closed against Control by default, so a Control outage becomes a reject storm rather than a silent-open estate. Break-glass paths are configured per route and are logged like any other traffic.
Visibility
Burn events, reject reasons, and access logs from every Gate deployment land in Control visibility, so an operator can see the state of the estate in one place without stitching logs across services.
- Registry and ledger are separate services (registry.eni6ma.net and ledger.eni6ma.net on the managed path) so they can be scaled and secured independently.
- A durable ledger deployment is a reference-architecture requirement for the absolute claims to hold; a cache-only ledger is explicitly not the shipping shape.
- Sovereign deployments run Control self-hosted and can be fully air-gapped against Foundry (the minting appliance that manufactures per-identity circuit binaries in cohorts; the ENI6MA equivalent of a certificate authority, but for one-shot identities instead of long-lived X.509 certs).