Reference architecture · v1.0 · 25 September 2026

AI Operating Layer Reference Architecture

An AI operating layer is the governance, audit and runtime engineered between foundation models and business workflows in a regulated enterprise. This document specifies its planes, its four testable controls, its evidence model and a one-day due diligence protocol. It is written for architects, CISOs, risk officers and auditors who evaluate or build one.

How to cite this document

0 · Status and conventions

A public, versioned specification, not a product sheet.

We publish this reference architecture so that any buyer, auditor or competitor can test an operating layer against the same criteria. It extends the canonical definition published on What is an AI operating layer? and never contradicts it.

In this document, "we" means Hikari Blue, the firm that operates this architecture on client engagements. The word "must" marks a requirement; a layer that fails one is not an operating layer under this specification.

The word "should" marks a recommended practice that a deployer may replace with an equivalent control, provided the substitution is recorded in the architecture decision record. Every requirement is phrased so that a third party can test it without our participation.

The regulatory hooks cite Regulation (EU) 2024/1689, the EU AI Act, as published on EUR-Lex (opens in a new tab). The application calendar of its high-risk obligations is tracked on the definition page, not repeated here, so that this document stays valid when the calendar moves.

1 · Scope and definitions

What the layer is, who acts on it, and what it is not.

The AI operating layer sits between foundation models and the workflows of the enterprise. It decides which model handles which task, under which policy, with which data residency, records every action, and stops any agent or model in one action.

  • Model providers

    Companies that train and serve foundation models, such as Anthropic, OpenAI, Mistral or Google, plus self-hosted open-weight models. The layer treats each provider as a replaceable supplier behind one governance.

  • The enterprise as deployer

    The regulated organization that uses AI under its own authority. Under the EU AI Act it carries deployer duties, so it must own the policy, the evidence and the stop path.

  • Agents

    Software actors that call models and tools to act inside a workflow. Each agent is a governed identity with a declared tool scope, a budget and an execution trace.

  • Human verifiers

    Named people who approve, reject or override an agent decision where consequence carries. Their identity and their decision are part of the record, not a comment beside it.

  • The operator

    The team that runs the layer day to day: on call, incident response, model changes, kill switch drills. During an engagement it may be Hikari Blue; after ownership transfer it is the client team.

  • Out of scope

    Model training, model evaluation research, end-user application design and legal qualification of a given use case. The layer produces the evidence a lawyer needs; it does not replace the lawyer.

Terms reused from the definition page: multi-model by architecture, audit by architecture, sovereign by construction, agent control by architecture, kill switch as architecture. The control tower analogy holds throughout: models are the aircraft, the layer clears, logs and grounds them.

2 · Reference model

Four planes, each with one responsibility and one artefact.

The layer is decomposed into four planes. Each plane owns a single responsibility and produces an artefact that a third party can inspect. A plane without an inspectable artefact is a claim, not a component.

  1. 01

    Policy and governance plane

    Holds the rules that decide which task may run, on which model, on which data, under whose authority. Policies are code, versioned and evaluated at runtime per tenant and per task, with engines such as Open Policy Agent or Cedar.

    Artefact: the versioned policy set, plus the architecture decision record that explains each deviation from the default.

  2. 02

    Routing and runtime plane

    Executes the work. It routes each task to a model by risk profile, cost and jurisdiction, and runs agents with scoped tool permissions. It exposes tools through a provider-neutral surface such as the Model Context Protocol.

    Artefact: the routing table and the model catalog, showing for each task class the primary model, the fallback and the residency corridor.

  3. 03

    Evidence and audit plane

    Records every prompt, output, tool call, operator action, model switch and kill switch trigger at the moment it happens. Records are append-only, queryable by client teams and exportable to a regulator without reconstruction.

    Artefact: the audit trail itself, plus the export formats described in section 4.

  4. 04

    Control plane: identity, scope and stop path

    Binds every agent and operator to an identity from the enterprise identity provider, declares what each agent may touch, and holds the stop path. Halt, throttle and rollback apply per workflow, per model and per user.

    Artefact: the agent register, the permission matrix and the kill switch runbook with its drill history.

The planes map onto the default layout published on the Engineering page. Identity and policy sit upstream; the multi-model orchestrator, immutable audit trail and kill switch sit in the layer; observability, residency and regulator export sit downstream. For a management-system view of the same duties, see ISO/IEC 42001:2023 and the NIST AI Risk Management Framework 1.0.

3 · The four properties as testable controls

Each property prevents one failure and passes one test.

The definition page names four properties. Here each one becomes a control with a failure it prevents, a test a buyer runs, a pass condition and a regulatory hook. A property that cannot be tested is marketing.

  • C1 · Multi-model by architecture

    Property. Several foundation models run under one governance, and model choice is a routing decision per task, reversible at any time.

    Failure prevented. Captivity to one provider's roadmap, pricing or jurisdiction, and a production outage when that provider changes or withdraws a model.

    Test. Remove the primary provider for one production task class and route the task to the declared fallback. Measure elapsed time, code changes required and whether the audit trail records the switch.

    Pass condition. The switch is a configuration change, not a code rewrite, and the trail shows the switch with its author and timestamp.

    Regulatory hook. DORA treats ICT third-party concentration as a risk to manage, and NIS2 requires supply chain security measures. A single-provider dependency is that concentration.

  • C2 · Audit by architecture

    Property. Every action is recorded at the moment it happens, append-only, with the context a regulator needs to reconstruct the decision.

    Failure prevented. An audit trail rebuilt from scattered logs in the week before an inspection, which is documentation, not audit.

    Test. Pick one past decision at random and export its record. Measure whether it names the actor, model and version, policy, human verifier and timestamp without manual assembly.

    Pass condition. The record is complete, exported from the trail itself, and any edit to it is detectable.

    Regulatory hook. EU AI Act Article 12 requires high-risk systems to record events automatically over their lifetime. Article 19 requires those logs to be kept, and Article 26 obliges deployers to keep the logs under their control.

  • C3 · Sovereign by construction

    Property. Data residency, model jurisdiction and key custody are decided by the enterprise and enforced by the layer per workload, with zero cleartext data server-side where the architecture demands it.

    Failure prevented. A sovereignty promise that lives in a policy memo while prompts and outputs cross borders at runtime.

    Test. Send a tagged workload through the layer and trace where compute, storage, inference and keys sit. Attempt to route it to a model outside its declared corridor.

    Pass condition. Every hop stays in the declared corridor, keys stay in client custody, and the out-of-corridor attempt is denied and logged.

    Regulatory hook. GDPR Article 35 requires a data protection impact assessment for high-risk processing. The residency trace is the factual input that assessment needs.

  • C4 · Agent control by architecture

    Property. Every agent runs under its own identity, with a declared tool scope, a budget and a stop path measured in seconds.

    Failure prevented. Agents that act under a shared service account, cannot be attributed, and cannot be halted without shutting down the whole workflow.

    Test. Ask an agent to call a tool outside its scope, then trigger the kill switch on that agent. Measure time from trigger to halt and confirm its tool permissions are revoked.

    Pass condition. The out-of-scope call is denied and logged, the halt lands in seconds, and other agents in the workflow keep running.

    Regulatory hook. EU AI Act Article 14 requires high-risk systems to be designed for effective human oversight, including the ability to stop them. Article 26 assigns that oversight to competent people at the deployer.

Where a decision produces legal or similarly significant effects on a person, GDPR Article 22 applies to solely automated decisions. The human verification field of the audit record, described in section 4, is how the layer evidences that a person actually reviewed the outcome. Article 4 of the EU AI Act adds an AI literacy duty for the staff who operate and verify; we deliver it through dated, role-resolved training paths

4 · Evidence model

One record per action, chained, exportable without reconstruction.

The audit trail is the primary output of the layer, not a by-product. Each action produces one record with the nine fields below. Records are append-only and chained by hash, so a deletion or an edit breaks the chain visibly.

Field Content Why it matters
Actor identity The agent or operator identity issued by the enterprise identity provider, never a shared service account. Attribution: every action has one accountable identity.
Model and version Provider, model name and exact version or snapshot used for this action. Reproducibility after a provider updates or retires a model.
Policy applied Identifier and version of the policy evaluated, with the decision it returned. Proves the action ran under the rule in force at that moment.
Residency corridor Declared region for compute, storage and inference, and the key custody reference. Turns sovereignty from a statement into a per-action fact.
Inputs reference Pointers to the input data and reference sources consulted, stored by reference or hash rather than in cleartext. Reconstructs what the system saw without copying sensitive data into the trail.
Action The output produced or the tool call made, with its target system and result. Links the model output to its consequence in the workflow.
Human verification Identity of the verifier, decision taken (approve, reject, override) and reason where given. Evidences human oversight as an event, not as an intention.
Timestamp Start and end time from a synchronized clock, in UTC. Establishes the period of use and the order of events.
Hash chain Hash of this record combined with the hash of the previous record. Makes tampering detectable by anyone holding the export.

  • The board report

    A periodic summary built from the trail: workflows in production, agents by identity, model mix by provider, policy denials, human overrides, kill switch drills and incidents. Every figure links back to the records it aggregates, so a director can ask for the underlying evidence.

  • The regulator export

    A scoped extract of raw records for one system and one period, with the policy versions and the agent register in force. It ships with the chain hashes so the recipient verifies integrity independently of the sender.

Our engagement baseline retains the trail per contract, twelve months minimum, as published in the Trust Center. Article 26 of the EU AI Act sets a floor of at least six months for logs kept by deployers, unless other law provides otherwise.

5 · Operating model

Who runs the layer in each phase, and who owns it after.

An architecture without an operating model decays within a quarter. Every engagement follows six phases: Diagnostic, Architecture, Build, Governance, Adoption, Run. Operation moves from us to the client team on a dated plan, written in the contract from day one.

Phase Who runs the layer What the client holds at the end of the phase
Diagnostic No layer yet. A named partner maps agents, obligations and the evidence gap. The risk map and the target architecture for one workflow.
Architecture Hikari Blue Engineering, with the client architecture and security teams. Architecture decision records, policy model, residency map, exit conditions.
Build Joint team, in the client environment, under the client identity provider. Code in client repositories, tests, observability, first runbooks.
Governance Joint team; client risk and compliance own the policy set. Signed policies, agent register, first kill switch drill on record.
Adoption Client operators on shift, Hikari Blue in support. Trained operators and verifiers, Article 4 literacy records.
Run The client team, with run support as a contracted option. The full layer: code, runbooks, evidence, drill history.

  • Ownership transfer

    Custom code, custom models, fine-tunes, prompt libraries, runbooks and operating documentation belong to the client at exit. Reusable components we retain are listed exhaustively in the MSA, so nothing arrives as a surprise licence.

  • Hikari Blue Ops, optional

    Hikari Blue Ops is our evidence product, the layer we run our own engagements on. A client may keep it after exit under its own control, or replace it with any component that passes the four controls.

  • Named accountability

    One of four partners, Engineering, Strategy, Talent or Run, signs every engagement from week one to exit. The decision log carries the name of the operator who signed each line.

The answer to "who operates the layer after transfer" is the client team. Run support and Hikari Blue Ops are options the client contracts, not dependencies it inherits. The six phases in detail

6 · Due diligence protocol

Six tests a buyer can run in one working day.

Run these tests on a staging copy of one real workflow, with the vendor's operator at the keyboard and your own auditor recording. The protocol applies to any operating layer, including ours.

  1. 01

    Provider switch

    Disable the primary model provider for one task class and let the layer fall back. Measure elapsed time and count the code changes needed.

    Pass: the task completes on the fallback through configuration only, and the switch appears in the trail.

  2. 02

    Trail export

    Name a past decision and a period, then request the regulator export. Verify the nine record fields and recompute the hash chain yourself.

    Pass: every field is present, the chain verifies, and nobody assembles the file by hand.

  3. 03

    Kill switch timing

    Start a running agent session, trigger the kill switch from the operations console, and time the interval from trigger to halt.

    Pass: the agent halts in seconds, its tool permissions are revoked, and the trigger, author and halt time are recorded.

  4. 04

    Scope violation attempt

    Instruct an agent, directly or through injected content, to call a tool or reach data outside its declared scope.

    Pass: the policy plane denies the call before execution, and the denial is logged with the policy version that fired.

  5. 05

    Residency proof

    Tag a workload with a residency corridor and trace compute, storage, inference and key custody. Then try to route it to an out-of-corridor model.

    Pass: every hop sits in the corridor, keys remain in client custody, and the out-of-corridor route is refused.

  6. 06

    Ownership rehearsal

    Ask the client operator, not the vendor, to perform tests 01 and 03 from the runbook alone.

    Pass: the client team completes both without vendor help, which shows the layer runs without its builder.

On our engagements, models switch in hours, never months, and kill switch behaviour is tested quarterly and documented in the engagement runbook. Incident timelines, including regulator notification windows under GDPR, DORA and NIS2, are published in the Trust Center

7 · Anti-patterns

Five designs that look like an operating layer and fail the tests.

Each anti-pattern below passes a demo and fails at least one control. They are common because each one is cheaper to build than the property it imitates.

  • The wrapper

    A thin interface around one model API. Removing the provider breaks the system, so it fails C1 and the provider switch test.

  • The retrofitted audit

    Logs collected from several systems and stitched together before an inspection. The record is assembled by hand and cannot prove it was not edited, so it fails C2.

  • Policy memo sovereignty

    Residency written in a contract clause while the runtime routes freely. Nothing denies an out-of-corridor call, so it fails C3 and the residency proof.

  • Shared-identity agents

    Several agents acting under one service account. No action is attributable and no single agent can be halted alone, so it fails C4.

  • The dashboard without a stop path

    A governance dashboard that shows activity but cannot halt it. Activity is not accountability; without a wired kill switch it fails C4 and the timing test.

Our stack policy lists what we will not ship, including black-box wrappers without exportable prompts and traces, and any agent in production without its own identity. Read the stack policy

8 · Versioning and citation

How to cite this document.

This URL is permanent and always serves the current version. Each change to a requirement increments the version and is listed in the changelog below, so a citation stays traceable to the text it quoted.

  • Preferred citation

    Hikari Blue, "AI Operating Layer Reference Architecture v1.0", 25 September 2026, https://hikariblue.com/reference-architecture

    Section anchors are stable: #scope, #reference-model, #controls, #evidence, #operating-model, #due-diligence, #anti-patterns, #cite.

  • Changelog

    v1.0 · 25 September 2026. First public version: scope and actors, four planes, four controls C1 to C4, nine-field evidence record, operating model by phase, six-test due diligence protocol, five anti-patterns.

    Licence. Published under CC BY 4.0: free to cite, quote and reuse with attribution to Hikari Blue and a link to this URL.

Corrections and challenges to a requirement are welcome from architects, auditors and regulators. Send them through the compliance channel; accepted changes are credited in the changelog.

For architects, CISOs, risk officers and auditors

Run the protocol against your own workflow.

Thirty minutes with a named partner. We map the four planes onto one workflow you already run and show where the six tests would pass or fail today. You leave with the diagram, whether or not we ever work together.

Book the diagnostic Or read the canonical definition of the AI operating layer