Orcher · Component 05 of 07
Data Control Gateway
Training exclusion and residency verified before routing.
Layer 2 — continuous, non-blocking

Before a single token leaves the enterprise, the Data Control Gateway verifies the destination's training policy and residency posture against the classification of the payload. Vendor terms change; defaults flip. The gateway treats every provider's policy as a runtime condition to be checked, not a contract to be trusted.
- Classifies payloads and enforces egress rules per provider and per jurisdiction.
- Verifies training exclusion and data residency before routing, on every call.
- Blocks or re-routes when a provider's posture no longer satisfies the policy.
- Records the data-control decision in the ledger alongside the action.
Without it, exclusion is a checkbox
De-identification is not anonymization, and a default that changed last quarter is not a control. Roughly 300,000 organizations were affected by a single default change in August 2026.
What it emits
A per-call data-control verdict, attached to the execution record.
Evidence
What the record shows
Figures drawn from the Enterprise Superintelligence Report, Vol. I, August 2026.
34.8%
share of enterprise AI traffic carrying sensitive data
from 10.7% — Vol. I, p.24
410M
DLP violations recorded across enterprise AI channels
Vol. I, p.24
7 yrs
maximum retention exposure under the policies surveyed
Vol. I, p.24

Mechanism
How it works
Four stages, in order. Layer 1 components gate execution; Layer 2 components run continuously and never block.
01
Classify the payload
Every outbound payload is classified before routing: regulated personal data, protected health information, privileged material, trade secrets, or unrestricted content.
02
Check the destination posture
The candidate provider's current training policy, retention window, and processing region are evaluated as runtime conditions — not as a contract signed eighteen months ago.
03
Permit, re-route, or block
If the destination satisfies the classification, the call proceeds. If it does not, the gateway re-routes to a permitted provider or region, or blocks the call outright.
04
Record the verdict
The data-control decision is attached to the execution record, so the question of where a given payload went, and under what policy, is answerable per call.
Operational contract
- Input
- Outbound payload plus candidate routing destination
- Output
- Per-call data-control verdict attached to the execution record
- Mode
- Layer 2 — continuous, non-blocking
- Checks
- Training exclusion, retention window, residency, sub-processor posture
- Cadence
- Every call; provider posture is re-evaluated, never cached as trusted
- Failure mode
- Fail closed — block rather than route under an unverified policy
What it is not
It is not a DLP replacement
DLP inspects content leaving the network. The gateway governs which model, operated by whom, in which jurisdiction, under which training policy, may see that content at all.
It is not de-identification
De-identification is not anonymization, and treating it as such is how sensitive material ends up in a training corpus. Classification plus destination control is the actual control.
Failure behaviour
If a provider's posture cannot be verified at call time, the gateway treats it as non-compliant and blocks or re-routes. A default that changed last quarter is not a control.
Questions
What enterprises ask first
- Vendor terms change constantly. How do you keep up?
- Posture is a runtime input, refreshed and re-checked rather than assumed. A single default change in August 2026 affected roughly 300,000 organizations — that is precisely the event this component exists to absorb.
- Can we pin certain workloads to a region?
- Yes. Residency is a first-class routing constraint, and a payload classified for one jurisdiction will not leave it even if a cheaper or faster provider is available elsewhere.
- Does this block us from using frontier models?
- Only for payloads whose classification forbids the destination. Unrestricted work still routes anywhere the cost governor prefers.
- How is the verdict evidenced?
- Each verdict is part of the hashed execution record, so a data-protection enquiry is answered from the ledger rather than from a vendor's dashboard.
Where it shows up
Solutions and industries that depend on this
Surfaced automatically from the components each solution engages and each industry relies on.
Solution
Data control & residency
Verify where data goes before it goes there.
Use case
Healthcare
Clinical authority cannot be delegated to a process.
Use case
Manufacturing
Physical consequence closes the loop on digital authority.
Use case
Government & Public Sector
Public decisions must be explainable to the public.
The other six
Orcher is one control plane
Layer 1
Directive Interface
Plain language becomes the permanent record of what was asked.
Layer 1
Role Identity Fabric
Binds the directive to a human and a role, cryptographically and revocably.
Layer 1
Logic Scrubber
Verifies the proposed action against systems of record before commit.
Layer 1
Immutable Audit Ledger
Hashes the verified action permanently. Evidence, not logs.
Layer 2
Cost Governance
Routes by stakes and halts runaway loops.
Layer 2
Observability
Real-time cross-provider trace: which model, which role, what cost, what outcome.
Verified execution, or none at all.
Orcher is deployed with named enterprises under the Human-in-the-Role model. Request a technical briefing with the founding team.
