How it works
Deployment models
Clients assemble the same envelope whether the gate validates locally or via the registry. Ops and revocation differ; the authority object does not.
Model A: local
Gate spawns validate-proof against a local circuit binary. Low latency, air-gap friendly, minimal control-plane dependency.
Model B: registry
Gate POSTs to Control/registry for manifest checks and validate-proof. Centralized lifecycle, revocation, and visibility (what operators need for fleet control).
Connected Team/Enterprise deployments typically run managed or self-hosted Control with a durable nonce ledger. Sovereign deployments license Foundry, host Control, and may prefer Model A at the edge with registry sync on approved paths. Kubernetes/Envoy/Istio sidecars are not offered as first-class products today, use reverse proxy or SDK middleware, and track sidecar as roadmap.
Mechanism claims
Model A (local validate-proof) and Model B (registry validate-proof) are security-equivalent at the envelope layer.ValidatedThe client assembles the same envelope either way; only verifier acquisition differs.
Foundry minting and Model A local verification can run without a network path to ENI6MA cloud services.ValidatedAir-gappable Foundry license path and local validate-proof acquisition.