designed to support This methodology uses the calibration register per REV-5: claims describe intent and risk-reduction, not guaranteed compliance outcomes.

Regulated Encoder

A deterministic, pure-function rule encoder that enforces regulatory boundaries on AI outputs without LLM reasoning — auditable by design, not by aspiration.

A probabilistic model cannot be the last gate on a regulated decision. The Regulated Encoder is the deterministic gate that sits downstream of the model — and upstream of the regulator.

What it is

The Regulated Encoder is a pure-function rule-enforcement architecture engineered for regulated-sector AI systems operating under DORA, the EU AI Act, and sector-specific regulatory frameworks (FCA, PRA, SEC, ESMA, SEBI, and others). It is the implementation pattern that separates what an AI model recommends from what the system is permitted to act on — enforcing regulatory boundary conditions deterministically, without LLM reasoning, without network calls, and without evidence-text reasoning.

Three structural properties make it auditable where probabilistic systems cannot be. It is a pure function: same inputs, same outputs, no sampling, no temperature. It is non-lossy: every input row produces exactly one output row — the rows-in-equals-rows-out invariant ensures no relationship is silently dropped and the audit trail is complete by construction. It uses a closed predicate vocabulary: every relationship type is explicitly enumerated, and any type not in the vocabulary is automatically downgraded to human-approval-required. Unknown inputs cannot pass through.

The rule taxonomy uses three action types: pass-through, downgrade-to-approval-required, and annotate — each producing a per-edge applied-rules array so a regulator or audit committee can trace exactly which rule governed each decision. The boundary between the encoder and any upstream probabilistic classifier is an architectural authority boundary: the encoder does not reason about the classifier’s outputs; it enforces policy on them.

Our architects deploy this architecture in production at Tier-1 regulated-sector clients — forty-five modelling rules across six categories, an eight-jurisdiction regulatory boundary table, and a deterministic test suite including an anti-LLM-leakage self-test that asserts the encoder source contains no LLM SDK imports, no network call sites, and no evidence-text field references.

When you reach for it

The Regulated Encoder applies when a probabilistic output must be filtered against a regulatory boundary before reaching a downstream action — and when “the model usually gets it right” is not an acceptable compliance posture.

Specific triggering conditions: DORA Article 28 ICT third-party risk management; EU AI Act Article 9 risk management system documentation; sector-specific information-barrier requirements where logical separation between regulated and commercial functions must be auditable without physical ring-fencing.

What you ship

  • A deterministic rule pack — a set of encoded boundary rules, tested against a representative sample of the client’s AI outputs, with the classification rationale for each rule stated and the applicable regulatory provision cited. Engineered to support conformity assessment, not aspirational compliance posture.
  • A non-lossy filter implementation — the encoder module itself, with the rows-in-equals-rows-out invariant verified by a test suite, the closed predicate vocabulary documented, and the per-edge audit-trail array present in every output.
  • An anti-LLM-leakage self-test — a test that asserts the encoder source contains no LLM SDK imports, no network call sites, and no evidence-text reasoning — making the determinism claim mechanically verifiable by any reviewing party, including a regulator.

Linked methodologies

The Regulated Encoder is typically preceded by AI-Act-in-a-Box, which establishes the risk-tier classification and the specific obligations the encoder must enforce. It depends on Service Awareness having established the CSDM service chain correctly, since the encoder’s jurisdictional and divisional rules operate on Service Instance attribution.

The Karpathy-6 Adversarial Verification gate applies to the rule-pack documentation — checking that every regulatory claim in the documentation is grounded in the cited provision, with no FM-3 Inference Leakage of general regulatory knowledge presented as client-specific compliance analysis.

Start here

Regulated Encoder engagements are available as standalone implementations or as the technical delivery tier within an AI-Act-in-a-Box programme. Book a discovery conversation.