Executive Summary
JIL Sovereign's verticals run services inside sandboxed compute substrates - managed data-cloud container services and lakehouse app runtimes - that intentionally hold no L1 private key material and are not permitted to move raw personally-identifiable or protected information into the external environment where L1 consensus actually operates. The policy that "only hashes, counts, and control-plane metadata may cross that boundary" is easy to state and easy to violate if every service in the substrate is independently trusted to honor it. The substrate-isolated anchor gateway instead makes that policy an enforced software choke point: a single, narrow gateway service is the only network path by which any service in the sandboxed substrate can get a computation anchored to L1 validator consensus, and its request schema simply has no field capable of carrying a content payload.
A downstream service cannot leak raw content through the gateway even by mistake, because the schema itself only accepts a content hash, engine identity and build metadata, and a set of validator signatures with their jurisdictions - there is no field to put anything else in.
Problem Statement
Multi-cloud and compute-isolation architectures commonly rely on network-level controls - PrivateLink, VPC peering - to keep a sandboxed substrate's traffic contained, but network isolation alone says nothing about the shape of what is allowed to leave: a peered or allowlisted network path can still carry an arbitrarily large content payload if the calling service's own code permits it. A general-purpose API gateway routes arbitrary payloads and does not, by itself, enforce that anchoring requests specifically exclude content. Direct database write access from a substrate service is even less constrained. Each of these leaves the data-boundary guarantee resting on the correctness of every individual downstream service, rather than on one enforced interface.
Why Existing Approaches Fall Short
- VPC PrivateLink / peering alone: restricts which network endpoints are reachable, but not the shape or content of what traverses an allowed path.
- General-purpose API gateway: routes arbitrary payloads to arbitrary backends; nothing structurally prevents a content field from being added later.
- Direct database write access from the substrate: no choke point at all - any service with credentials can write anything the schema of the target table permits.
- Policy-as-documentation: a written data-boundary policy that every engineer is expected to honor, with no software enforcement backing it.
Technical Architecture
The Anchoring Request Schema
| Field Category | Contents |
|---|---|
| Content identity | A 64-character hex SHA-256 content hash and a subject type/subject identifier |
| Engine metadata | Engine name, engine version, engine commit SHA, engine build timestamp, ruleset version |
| Validator attestation | An array of base64url Ed25519 signatures, validator identifiers, and validator jurisdictions |
No field in this schema is capable of carrying a content payload - the schema's shape is itself the enforcement mechanism, not a policy layered on top of a more permissive schema.
Quorum, Authentication, and Idempotency
| Control | Enforcement |
|---|---|
| validator quorum threshold | The gateway rejects any request whose submitted signature count is below the configured Byzantine-fault-tolerant threshold before accepting it |
| Per-tenant authentication | A bearer token is compared against a registry of per-substrate-tenant tokens using a constant-time comparison, closing timing side-channels |
| Idempotency | An anchoring request whose content hash has already been anchored is treated as a no-op insert, returning the existing anchor record rather than creating a duplicate |
A Single Enforced Choke Point
Because every anchoring path from every service in the sandboxed substrate must pass through this one gateway, the data-boundary policy is enforced exactly once, in one place, rather than depending on every current and future downstream service independently reimplementing the same restriction correctly.
Prior Art Differentiation
| Approach | Content-Shape Enforcement? | Single Choke Point? | Idempotent? |
|---|---|---|---|
| VPC PrivateLink / peering alone | No - network-level only | No | N/A |
| General-purpose API gateway | No - routes arbitrary payloads | Possibly, but not content-restricted | Depends on backend |
| Direct database write access | No | No | Depends on schema |
| JIL Sovereign substrate-isolated anchor gateway | Yes - schema has no content field | Yes - the only anchoring path | Yes - content-hash keyed |