The Orkena architecture.

01 · Executive summary

Orkena is a governed agent runtime — a Python-and-TypeScript system that executes agent workflows and enforces your controls as part of that execution. Four properties define it:

• Authorization before execution. Every edge traversal, tool call, credential use and model call is evaluated against policy-as-code in-process — Cedar's Rust evaluator via cedarpy bindings, measured at p50 110 µs / p99 352 µs — before any output reaches a system of record.
• Evidence in the same transaction. The audit record commits atomically with the step that produced it, into a per-tenant hash-chained ledger with Ed25519-signed anchors. There is no window in which an action exists without its evidence.
• Deterministic replay. Runs are event-sourced. Every non-deterministic interaction is recorded, so any run can be replayed byte-for-byte or forked from any checkpoint to interrogate a decision.
• Evaluation-gated change control. No version reaches production without passing its regression evaluation suite. Self-proposed rules stay inert until they pass the same suite and a human declines to veto them.

The thesis is that these four properties must live in one system: the moment they are separated across vendor boundaries, the seams between them are exactly where the assurance leaks. This brief justifies that claim at the architecture level.

Audience: platform engineers evaluating the runtime, security reviewers working through the vendor questionnaire, and model-risk officers who need to know what the evidence will actually say. Each section states its question and answers it from the design — claims that rest on tests are identified as tested, and claims that rest on plans are identified as plans.

02 · The problem in one diagram

Today's options for a regulated institution are to assemble a stack or buy a dashboard:

Option A fails on seams. The workflow engine writes execution state in its own store; the policy service evaluates in its own process; the audit system ingests after the fact, best-effort. Between each pair sits a network boundary, an ordering question, and a failure mode that no single component can answer: was the evidence committed before the action, or reconstructed after it? The integration team spends quarters reconciling exactly these questions, and the answer they land on is still an assertion, not a property.

Option B fails on the direction of control. A dashboard observes agents and reports; it does not sit in the execution path, so the report describes what happened after it was too late to prevent. Observability after the fact is valuable — and it is not governance. A supervisor reading the artifact of Option B learns what the agent did; they cannot verify the agent was authorized to do it.

Neither is a substrate. Neither produces the artifact a supervisor asks for: proof that the agent was authorized to do what it did, at the moment it did it, in a form that survives adversarial inspection. That artifact is the design target of everything that follows.

The third option — the one this brief documents — collapses the diagram to one box: the runtime that executes, the policy that authorizes, the ledger that records, and the gates that bring humans in, as four layers of one system. The problem statement then reduces to a set of constraints. The authorization decision must precede the effect, in the same process as the executor. The evidence must commit in the same transaction as the step. The record must survive adversarial inspection after the fact, and verify without the vendor. The human control points must be structural, not advisory. Sections 04 through 07 take each constraint in turn.

03 · System overview

Six components, one deployment:

The control plane is the tenant surface: organizations, workspaces, graph versions, approvals, exports. The engine is the execution core — a durable state machine that checkpoints every step. The policy engine is not a service; it is a library evaluated inside the worker's process, so a policy decision can commit in the same database transaction as the step it authorized. The ledger is the evidence store: append-only, hash-chained, per tenant. Memory is the cross-run learning layer, with consolidation and human veto.

Underneath sit three data stores. Postgres is the single source of truth, with row-level security enforcing tenancy at the query layer — the application role connects with NOBYPASSRLS, so a missed predicate in application code fails closed rather than leaking across tenants. Redis carries the lease queues that distribute work. An object store (MinIO or S3-compatible) holds artifacts from sandboxed code execution. Code that runs during execution — tool implementations — executes in a sandbox with deny-by-default egress, resource limits, and secret scrubbing.

All six components ship as a single Helm chart. There is no separate workflow orchestrator, no external policy service, no separate audit store — each coupling that must not break is inside the process boundary. That is the architectural claim this brief defends: the transaction boundary is the control.

A request moves through the system in a fixed order. A trigger arrives — webhook, schedule, API. The graph loads; the policy pack evaluates the first action and returns permit, deny, or hold. On permit, the step executes, its checkpoint and its ledger events commit in one transaction, and the non-deterministic inputs are recorded. On hold, the run parks at a gate — holding no compute — and resumes when a human resolves it. On deny, nothing downstream happened, and the denial itself is evidence. Repeat to the terminal node. Every step leaves two artifacts: the state change, and the record of why it was allowed. The ordering is the product.

04 · Runtime — durable execution

The executor is Postgres-backed by choice, not by accident. A separate workflow orchestrator (Temporal and its peers are excellent products) introduces a boundary we cannot cross: the audit record and the execution step must commit in the same transaction, and an orchestrator that owns execution state outside the database makes that impossible. In Orkena, "the step ran" and "the evidence of the step exists" are one commit, or neither happened.

The model:

• Every step is checkpointed into Postgres. A run is a durable state machine; the checkpoint is the truth. A run paused at a human approval gate holds no compute — its state is rows, not processes — and resumes when the gate resolves, days or weeks later.
• A Redis Streams lease queue distributes work. A worker claims a step under a lease; if the worker dies, the lease expires and the step re-runs. The chaos suite proves the two invariants under induced failure (Postgres failover, Redis flush): no duplicate effects, no lost audit.
• Structural limits, not promises. A graph without a maximum iteration count is rejected at validation, before execution. Run budgets are enforced the same way — a runaway loop is a validation error, not an ops incident. The kill switch pauses or cancels runs at four levels: org, workspace, graph, agent.
• Non-determinism is captured at the source. Model responses, tool results, timestamps, retrieval hits are recorded in the ledger as they occur — every input that could not be regenerated from the graph alone. Replay reproduces the run from these records, byte for byte.

Deterministic replay is not a developer convenience. It is the primary artifact a model-risk officer uses to answer "under what exact conditions did this decision get made, and what would have happened if a variable had been different?" — without altering the original run. Forking from any checkpoint produces a linked alternate run in the same ledger, so counterfactuals inherit the same evidence properties as the original. The mechanics — checkpoints, capture, fork — are in Runs: durable execution.

Replay is also the supervisory-reporting answer: an algorithmic decision under MiFID II is replayed, step by step, for exactly the questions a trading supervisor asks — which data entered the decision, under which rule, at which time — and forked to test the counterfactual without touching the original. The replay is the evidence; the fork is the analysis.

The cost of this design is visible and published: on null-load tests, the governed substrate is 12–61× slower than a bare orchestrator (see the benchmark page). On LLM-bound workloads the engine is 3.9% of wall-clock. The trade is explicit: every step pays for its own evidence, and the price is published rather than hidden.

What fails, and how. Worker death: the lease expires, the step re-runs, no duplicate effects — proved by the chaos suite, not asserted in a manual. Region failure: the HA/DR runbook covers standby region and ledger quorum, drilled to a failover target under 15 minutes. Database restore: the backup/restore drill re-verifies the ledger chain after every restore. Operator error: every administrative action is itself a ledger event, so the error and its correction are both on the record. The design assumption is that infrastructure fails; the controls are tested against induced failure.

05 · Policy — authorization before execution

Policies ship as Cedar policy packs — the AWS-published authorization language, evaluated in-process by Cedar's Rust evaluator via cedarpy bindings (BE-17, landed 2026-08-16). Packs validate against a canonical schema (meridian-v1.cedarschema.json) and pin it via a // schema: header; every policy.decision ledger event records which engine produced it. Measured on the acceptance run: p50 110 µs, p99 352 µs per evaluation, pre-parsed policy set.

Cedar was chosen over inventing a DSL for three reasons. First, it is an audited, published language with formal semantics — policy text is reviewable by a security team that has never seen Orkena. Second, it is fast: the Rust evaluator over a pre-parsed policy set keeps the policy decision a rounding error inside a step. Third, it forces honesty: a rule either exists in the pack or it does not, and the pack is the artifact your auditor reads.

Packs rule over principals (each agent is its own principal), actions (invoke_tool, call_model, credential use, edge traversal), resources with declared attributes (side_effects, data_labels), and context (tainted, secrets_present, region, time). forbid takes precedence over permit, and a third verdict — hold — routes to a human approval gate with quorum rules, an SLA and an escalation path. A denial is a control that fired, not an incident that was noticed: nothing downstream happened, and the denial itself is a ledger event.

The baseline security pack encodes three rules that fire on every action:

• Irreversible + tainted → deny. An irreversible action (payment, credential change, data deletion) derived from untrusted input is denied by default.
• Secrets in prompt → deny. A model call carrying secrets it was not authorized to see is denied.
• Four-eyes → hold. High-impact actions open an approval gate with quorum, SLA and escalation.

What-if simulation evaluates a proposed policy change against past runs before activation — the simulator reports the verdicts the pack would have produced, without touching the historical ledger. The same eval-gated path applies to any other change, so a policy edit cannot degrade a previously passing run silently.

Packs have a lifecycle that is itself on the record. A pack change is proposed, simulated, reviewed, then activated — and the activation is a ledger event, so the policy in force at any historical moment is recoverable as exact text: the auditor asks "what did the pack say at 14:03 on Tuesday?" and gets the pack, not a recollection. Packs are versioned and immutable; there is no in-place edit path that skips the record.

Full grammar and worked examples: Policy packs, Policy DSL reference, and Build your first policy pack.

06 · Evidence — the hash chain

The ledger is the load-bearing artifact: the thing a supervisor, auditor or opposing counsel can hold. Its structure:

• Per-tenant append-only ledger. Each organization's chain starts at SEQ 1 and grows monotonically. A modification in one tenant's chain cannot affect another's. Entries are categorized — run, admin, gate, export, budget, auth — so every authorization, execution, approval and administrative action has a named place in the record.
• Hash chain. Each entry carries the hash of the one before it: SEQ N ← prev = H(entry{N-1}). Any alteration, deletion or reordering invalidates everything downstream.
• Anchors. Periodically, the chain head is signed with an Ed25519 private key. The public key travels with exports, so an auditor verifies the signature without depending on Orkena — online, available, or in business. Anchors make the tamper-evidence time-stamped: the chain up to an anchor cannot be modified without modifying the anchor.
• Bundles. An evidence bundle for any run or date range exports as a signed archive: ledger slice, anchors, public key, a readable report, and a dependency-free verify.py. Your auditor runs it on their own machine — the verification requires nothing from Orkena.

Bundles scope to the question being asked, not to a predefined export shape: a single run, a date range, a breach window, or a data subject's footprint across the workspace. The export contains exactly the slice that answers — with the same verification properties as a full export, because the chain and the anchors travel with it either way.

The transaction boundary is what makes the log the evidence, and not a report about the evidence. The hash chain makes it tamper-evident; the anchor makes the tamper-evidence time-stamped; the verifier makes it independent of Orkena's continued cooperation. Chain integrity is itself drilled: the backup/restore exercise re-verifies the chain after every restore, so "the record survived the restore" is a demonstrated property, not an assumption. Bit-flip and truncation mutations of a bundle fail verification — by construction, and by test.

The same discipline applies to the other failure shapes. The chaos suite proves no duplicate effects and no lost audit under induced database and queue failure; the DR drill proves the chain survives a region failover; the game-day runbook rehearses the kill switch against a live environment. Verification is a practice, not a claim — and because the verifier is dependency-free, the practice transfers to your auditor's machine unchanged.

Structure and worked examples: The hash-chained ledger and Evidence bundles; the export walkthrough is Export an evidence bundle.

07 · Memory — governed learning

Agents accumulate signal across runs. Left alone, that accumulation is drift — an agent that behaves differently next quarter for reasons no one can trace. Governed, it becomes controlled improvement.

• Consolidation runs overnight (or on demand): duplicate memories are merged, contradictions between agents' understandings are surfaced, and rule refinements are proposed.
• Nothing proposed activates. A human reviews or ignores the proposals during a veto window; survivors are promoted through the same eval-gated path as any other change. The system can propose; it cannot enact.
• Every read, write and consolidation is a ledger event. Memory access is purpose-tagged — which agent read what, under which purpose, is on the record, so data-governance questions ("who used this customer's data, and for what?") answer from evidence rather than recollection. The system's own learning is on the record.

Concretely: three agents in a claims workspace have accumulated overlapping guidance about refund thresholds. Consolidation merges the duplicates and surfaces the contradiction — agent A learned "deny above €500", agent B "deny above €250" — then proposes one rule. A human reviews the proposal with its evidence trail and accepts or ignores it; accepted rules promote through the eval gate like any other change. Nothing in the loop is invisible, and nothing in the loop is automatic.

Memory is scoped per workspace and governed like every other resource: policy decides which agent may read which memory, under which purpose, and the purpose tag travels into the ledger. What one workspace's agents learn does not leak into another's — tenancy applies to learning, not just to data.

Full mechanics — the veto window, the eval-gated promotion path, the purpose-tagged ledger record — in Memory consolidation and gated reflection.

08 · Interop — MCP + A2A + adapters

Orkena does not invent protocols it doesn't need to. MCP is the tool interop layer — a tool call like tool.payments.issue_refund is an MCP invocation, evaluated by policy before it fires. A2A is the agent-to-agent layer: an Orkena agent and an external agent negotiate work through a protocol both sides already speak.

Existing workflows import rather than re-implement. LangGraph, CrewAI and AutoGen workflows import as first-class graphs through adapters — you do not throw away what you already built, and the imported graph inherits the same policy, ledger and replay properties as a native one. Model providers are bring-your-own-key across Anthropic, OpenAI, Azure OpenAI and Bedrock; the runtime is model-agnostic and records which model served each step.

OpenTelemetry emits the events; your existing Datadog / Grafana stack graphs them. The ledger is not a log, and observability is not governance — the two integrate, but they do not substitute.

The HTTP tool surface gets the same treatment as every other surface: an outbound call from tool code is a policy decision before it is a network request, and the SSRF matrix — metadata endpoints, link-local and private ranges blocked, DNS pinning, per-hop redirect revalidation — runs in CI on every change. An agent that can call tools is an agent that can be pointed at URLs; the runtime treats that as a security surface, not a feature gap.

09 · Deployment — VPC / air-gap today, managed tier on the roadmap

One Helm chart, feature parity across all three modes:

• Customer VPC. Shipping today. Your Kubernetes, your key management, your network. The chart's secure defaults: NetworkPolicy with deny-unless-allowed egress on every workload (each workload may reach only its documented peers — Postgres, Redis, the object store, and the LLM endpoints you declare), non-root containers with read-only root filesystems, capabilities.drop: [ALL] and the runtime-default seccomp profile, images pinned by digest, KMS driver passthrough for your key provider (AWS KMS, GCP KMS, Azure Key Vault, or HashiCorp Vault), and telemetry to Orkena off by default.
• Air-gapped. Shipping today. An offline installation bundle — every image, checksum-verified — including local models for embeddings and classifiers. No outbound connectivity required, ever. The verification story was designed for it: verify.py is dependency-free and offline-first.
• SaaS, region-pinned — roadmap (2027). Data at rest never leaves the region you select; the topology plans three-region high availability validated in a controlled test environment, with RPO/RTO commitments documented in the DPA rather than asserted on a page. Orkena operates the infrastructure; you consume the API. Design partners first; GA follows the first VPC deployments and SOC 2 Type II.

Air-gap is not a downgrade; it is the primary path for public-sector engagements, and the zero-sub-processor default makes the register question trivial. Every mode ships the same six components and the same evidence properties; only who operates them changes.

Operations in the air-gap are the same drills, offline. The bundle's pack manifest pins every image digest and checksum, verified before deploy; upgrades arrive as a new bundle rather than a network pull. The drills that prove the system — backup restore with ledger re-verification, failover rehearsal, game-day kill switch — all run without a connection to anything, which is the point.

10 · What the runtime does NOT do

• Not a model gateway. Orkena is model-agnostic; it does not sit in the inference path deciding which model to route to, and it does not hold model credentials beyond what an agent is scoped to use.
• Not an observability replacement. It integrates with your OTel + Datadog + Grafana stack. The ledger is evidence, not logs; SLO dashboards are operational, the chain is evidential, and the two serve different questions.
• Not a compliance certifier. "We produce the evidence; your certifier interprets it." Certification is between you and your auditor. No claim on this site asserts otherwise.
• Not a dependency you must trust forever. Exports verify without Orkena's cooperation. The evidence outlives the contract — that is the design intent, not an accident.
• Not a replacement for your identity provider. Orkena federates to your SAML/OIDC IdP; it does not become one. Your directory stays the system of record for people; Orkena's principals are for agents.

11 · References

• Benchmark — the 3.9% overhead measurement with method, raw results and caveats
• Security — architecture, tenancy, encryption, SDLC, disclosure
• Compliance — regime-by-regime mapping with evidence artifacts
• What is a Governed Agent Runtime — the category essay
• Docs — concepts, quickstarts, reference

Docs that go deeper on each section above:

• Runs — durable execution · Graphs and versions (§03–04)
• Policy packs · Policy DSL reference · HITL gates and four-eyes (§05)
• The hash-chained ledger · Evidence bundles (§06)
• Memory consolidation and gated reflection (§07)
• Import from LangGraph · Model provider setup (§08)
• Deployment options · Air-gap deployment (§09)