Reference architectureVersion 1.025 September 2026
AI Operating Layer Reference Architecture
An AI operating layer is the software and operating discipline between AI models and a company’s systems, built with the rigor regulated industries demand. This document specifies its planes, its 4 testable controls, its evidence model and a 1-day due diligence protocol. It is written for architects, CISOs, risk officers and auditors who evaluate or build one.
On this page
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.
What the layer is, who acts on it, and what it is not.
The AI operating layer is the software and operating discipline between AI models and the company’s systems. It decides which model handles which task, under which policy, with which data residency, records every action, and holds a stop path designed to halt 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.
4 planes, each with one responsibility and one artefact.
The layer is decomposed into 4 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.
One operation across the 4 planes.
Read it from the top: Control holds the identity and the stop path (C4), Policy and governance applies the rule in force (C3), Routing and runtime sends the task to a model (C1), and Evidence and audit records the action (C2). Each plane produces the artefact named below.
- Enterprise systems
- Enterprise identity provider
- ERP · payment request
C4Control- Agent register
ap-pay-02 - Permission matrix: payment release, ERP
- Kill switch runbook
C3Policy and governance- Policy set
P-04 v3 - Human approval required above threshold
C1Routing and runtime- Routing table: Provider A, pinned snapshot
- Fallback model, declared
- Human approval
- A. Moreau, treasury operator
C2Evidence and audit- Record #4126
- Record #4127, hash-linked
- Oversight
- Regulator export
- Board report
- ERP · payment release
- Enterprise systemsEnterprise identity provider · ERP · payment request
C4ControlAgent registerap-pay-02· Permission matrix: payment release, ERP · Kill switch runbookC3Policy and governancePolicy setP-04 v3· Human approval required above thresholdC1Routing and runtimeRouting table: Provider A, pinned snapshot · Fallback model, declared- Human approvalA. Moreau, treasury operator
C2Evidence and auditRecord #4126 · Record #4127, hash-linked- OversightRegulator export · Board report · ERP · payment release
Text version
- A payment request enters from the ERP; the agent ap-pay-02 acts under an identity issued by the enterprise identity provider.
- Control (C4) checks the agent register and the permission matrix, and holds the kill switch runbook and the stop path.
- Policy and governance (C3) applies policy set P-04 v3: human approval is required above the threshold.
- Routing and runtime (C1) sends the task to Provider A on a pinned snapshot, with a declared fallback model.
- A. Moreau, treasury operator, approves at the human approval gate.
- Evidence and audit (C2) appends record #4127, hash-linked to #4126.
- Oversight receives the regulator export and the board report; the ERP releases the payment.
- 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.
- 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.
- 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.
- 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 are designed 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, append-only 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.
Each property prevents one failure and passes one test.
The definition page names 4 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 designed to act in seconds, timed in the engagement.
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 acculturation paths
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 9 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. |
4 records, chained by hash.
The evidence plane, drawn: each record carries the hash of the previous one, so an edit or a deletion breaks the chain visibly, and the board report and the regulator export are read from the same records.
- Evidence and audit planeC2 in Reference Architecture v1.0: one record per action.
- Records #4124 to #4127Append-only, 9 fields each; #4127 is the action of this example.
- Hash linksEach record carries the hash of the previous one: an edit or a deletion breaks the chain visibly.
- Regulator exportA scoped extract for one system and one period, shipped with the chain hashes (seal).
- Board reportBuilt from the trail; every figure links back to its records.
Text version
The evidence and audit plane holds 4 records, #4124 to #4127, each linked to the previous one by its hash. Below it, the oversight zone receives a regulator export carrying the chain hashes under a seal, and a board report built from the same records.
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, 12 months minimum, as published in the Trust Center. Article 26 of the EU AI Act sets a floor of at least 6 months for logs kept by deployers, unless other law provides otherwise.
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 6 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. |
What the client owns at exit.
Ownership transfer, drawn: custom code, models, prompt libraries and runbooks sit on the client plane, and the reusable components Hikari Blue retains are listed in the MSA.
- Retained componentsReusable components Hikari Blue keeps, listed exhaustively in the MSA.
- Named partnerOne of 5 partners signs the engagement from week one to exit.
- Ownership transfer at exitWritten into the contract from day one.
- Custom model or fine-tuneOwned by the client at exit.
- Custom codeIn client repositories, owned by the client.
- Prompt librariesThe prompts of each workflow, owned by the client.
- Runbooks and operating documentationHanded to trained owners on the client team.
- Client operatorsThe client team runs the layer after transfer.
Text version
2 planes. On the Hikari Blue plane: the reusable components it retains, listed in the MSA, and the named partner who signs the engagement. An arrow marks the ownership transfer at exit. On the client plane: the custom code in client repositories, the custom model or fine-tune, the prompt libraries, the runbooks and operating documentation, and the client operators who run the layer after transfer.
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.
The evidence and control layer, optional
It is the layer we run our own engagements on, and the one we engineer and run for clients. A client may keep it after exit under its own control, or replace it with any component that passes the 4 controls.
Named accountability
One of 5 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 AI Governance Operations are options the client contracts, not dependencies it inherits. The 6 phases in detail
6 tests a buyer can run in 1 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.
- 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.
- 02
Trail export
Name a past decision and a period, then request the regulator export. Verify the 9 record fields and recompute the hash chain yourself.
Pass: every field is present, the chain verifies, and nobody assembles the file by hand.
- 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.
- 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.
- 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.
- 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.
In our reference architecture, switching models is a routing change, not a rebuild, and kill switch behaviour is documented and tested in the engagement runbook. Incident timelines, including regulator notification windows under GDPR, DORA and NIS2, are published in the Trust Center
5 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
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, 4 planes, 4 controls C1 to C4, 9-field evidence record, operating model by phase, 6-test due diligence protocol, 5 anti-patterns.
Editorial correction · 25 October 2026: license sentence aligned, scope and reservations stated.
License. Published under CC BY 4.0: free to cite, quote and reuse with attribution to Hikari Blue and a link to this page. The license covers Hikari Blue’s text, tables and diagrams on this page; it does not cover third-party data, quotations or legal texts, which keep their own terms, nor the Hikari Blue name and logo, trademarks of UNITED4 LLC.
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.
Next step: who decides, who owns and what evidence the board sees, in 15 controls. Enterprise AI Governance Framework v1.0
Run the protocol against your own workflow.
30 minutes with a named partner. We map the 4 planes onto one workflow you already run and show where the 6 tests would pass or fail today. You leave with the diagram, whether or not we ever work together.
- Your workflow mapped onto the 4 planes
- Where the 6 tests would pass or fail today
- The diagram, whether or not we work together
