Geo-fence compliance
Residency as a hard gate — evaluated before price, not alongside it.
problem it solves
Your cheapest destination is in the wrong jurisdiction. Without a gate, the router does what it is built to do and sends EU personal data or US PHI to whichever rung costs least — and you find out during an audit rather than during a deploy.
What it does
What it does: Tags each request with a data class and refuses any destination whose jurisdiction, retention posture or certifications do not satisfy it.
When it runs: Before cost is considered at all. Compliance, fit and region are hard gates; the merit order only ranks what survives them.
What it refuses: A request with nowhere compliant to go fails closed. It is not quietly downgraded to the nearest legal-ish option, because a silent downgrade is the outcome this skill exists to prevent.
The data classes it understands
- ·eu_personal — GDPR personal data. Requires an EU jurisdiction AND zero-retention on the destination.
- ·us_phi — HIPAA-covered health information. Requires a US jurisdiction and a HIPAA certification on the destination.
- ·unclassified — no residency constraint; every destination is a candidate.
How you see it work: A refusal is reported on the response as `x-ace-route-blocked-by`. The gate firing is visible to the caller rather than inferred from a latency change.
What we need from you
- A destination with declared compliance attributesrequired
Jurisdiction, retention and certifications come from the fleet registration. A destination that declares none is treated as satisfying no data class — fail-safe, so an unlabelled endpoint is never the one a regulated request lands on.
- A compliant destination for each class you userecommended
Tagging traffic eu_personal with no EU zero-retention destination registered means those requests have nowhere to go. Register the destination before you turn the class on, or shadow first and read the refusals.
What each mode does
| Mode | Effect on your request | What you can see |
|---|---|---|
| off | No residency gate. Every destination is a candidate for every request. | No geo_fence_compliance stage is recorded. |
| shadow | The gate is evaluated and nothing is blocked. The request goes wherever the merit order sends it, and the destinations that would have been refused are recorded. This is the mode to run for a week before enforcing: it tells you how much of your traffic currently lands somewhere it should not. | Stage with action=would_block and the refused destination ids. |
| prod | Non-compliant destinations are removed from the candidate list before ranking. If that empties the list the request fails rather than falling back — the one case in this product where an empty candidate list is not softened. | x-ace-route-blocked-by names the gate; the served destination is compliant. |
Current policy
| Default data class | unclassified | Untagged traffic is unconstrained. Turning the skill on changes nothing until you tag something. |
| Undeclared destination | satisfies nothing | Fail-safe. An endpoint with no compliance block is never a candidate for classified traffic. |
| Empty candidate list | fail the request | Deliberately not a fallback. A compliant-or-nothing gate that falls back is not a gate. |
Worth knowing before you enable it
- ·Turning this on with nothing tagged does nothing at all. The gate is per data class, and untagged traffic has no class.
- ·It gates the DESTINATION, not the prompt. It will not tell you that a prompt contains personal data — that is pii_ner's job, and the two are usually enabled together.
- ·A destination's compliance attributes are declared by whoever registered it. ACE stores and enforces them; it cannot verify that a provider's EU region really is one.
- ·Enforcing before you have shadowed will surface every gap at once, as failed requests.
What it replaces
- ·A second gateway deployment per region, existing only to keep traffic in one jurisdiction.
- ·Allowlists of model endpoints maintained by hand in application config.
- ·A compliance review of routing changes, because routing could previously move data across a border.
Custom data classes and per-key policy are available on the enterprise tier.
- ·Data classes beyond the built-in EU and US sets, with your own predicate over jurisdiction, retention and certs.
- ·Per-developer-key residency policy, so a regulated workload and an internal one can share a tenant.
- ·An exportable audit trail of every gate decision, keyed to the request id.