Axiom — Organizational Policy

Given this organization's rules, its risk tolerance, the agent's trust profile, the current operating environment, and the specific action requested — should this action proceed? Axiom answers with one of four dispositions: ALLOW, BLOCK, ESCALATE, or DEFER.

Authority is not permission

An agent holds valid authority and has passed the identity interlock. But authority is not permission. The question Axiom answers is: given this organization's rules, its risk tolerance, the agent's trust profile, the current operating environment, and the specific action requested — should this action proceed?

The answer is not yes or no. It is one of four dispositions — each carrying a specific consequence and a verifiable governance trace.

The governance engine for autonomous systems

Axiom is the governance engine of the Ardyn platform — the Ardyn Axiom product, delivering Decision Trust. It evaluates organizational policy rules against structured inputs and renders a binding, auditable decision. Every decision produces a governance trace: an immutable, replayable record of which rules were evaluated, which matched, and why.

Five operating principles

  1. Organizations define policies. Each organization writes its own rules. No two organizations need share the same policy.
  2. Policies are versioned. Every change to a policy is recorded with a version number and hash. Decisions reference the policy version that produced them.
  3. Policies are scoped by role. Rules can target specific principals, agent types, departments, or resource classes.
  4. Policies are evaluated with context. Axiom reads the agent's ATP, the current authority state from Forge, environmental risk factors, and the specifics of the requested action.
  5. Decisions are replayable. Any party can re-run the same policy version against the same inputs and produce the same decision.

The Four Dispositions

DispositionMeaningConsequence
ALLOW The action satisfies all applicable policy rules Action proceeds to execution
BLOCK A policy rule explicitly prohibits the action Action is rejected with a reason trace
ESCALATE Policy requires human review before proceeding Action is held pending human decision
DEFER Policy cannot resolve; delegated to another governance layer Action is routed to the specified deferral target

Three-layer policy evaluation

Axiom's policy evaluation engine uses a three-layer architecture. Rules are evaluated in order within each layer. The first matching rule determines the disposition.

Layer 1
Business Rules
Strategic thresholds, financial limits. e.g. "Block payments above $50,000 without quorum."
Layer 2
Operational Rules
Vendor constraints, tool restrictions, time-of-day limits. e.g. "Allow read_ledger for all agents; block delete_production_data."
Layer 3
Technical Rules
Confidence thresholds, attestation tier requirements. e.g. "Require hardware-attested execution for all transfer_funds actions."

Evaluation Flow

  Action Request
       │
       ▼
  ┌──────────────────────────────────────────────────┐
  │              Axiom Policy Engine                  │
  │                                                   │
  │  Inputs:                                          │
  │   ├─ Action: tool, parameters, resource, amount   │
  │   ├─ Principal: identity, role, ATP               │
  │   ├─ Authority: Forge grants, delegation chain    │
  │   ├─ Environment: time, risk level, threat flags  │
  │   └─ Policy: versioned, hash-pinned rule set      │
  │                                                   │
  │  Evaluation:                                      │
  │   1. Business rules ──► match? ──► disposition    │
  │   2. Operational rules ──► match? ──► disposition │
  │   3. Technical rules ──► match? ──► disposition   │
  │   4. No match ──► default_disposition             │
  │                                                   │
  │  Output:                                          │
  │   ├─ Disposition: ALLOW / BLOCK / ESCALATE / DEFER│
  │   ├─ MatchedRule: policy_hash, rule_id, layer     │
  │   └─ Governance Trace: full evaluation record     │
  └──────────────────────────────────────────────────┘

Policy Sovereignty & Default Disposition

Axiom's foundational principle is policy sovereignty: each organization controls its own rules. Ardyn does not impose a default policy. Different tenants, departments, and workflows within the same organization can have different policies. A policy is a JSON document with a cryptographic hash — versioned, signed, and immutable once activated.

Default Disposition

When no rule matches an action, the policy's default_disposition field determines the outcome:

  • Allow (blocklist model): everything not explicitly blocked is allowed
  • Deny (allowlist model): everything not explicitly allowed is blocked
  • Escalate: unmatched actions require human review

Healthcare policy in action

A healthcare organization operates autonomous agents that process patient records, schedule appointments, and authorize insurance claims.

{
  "policy_id": "healthcare-v3",
  "policy_hash": "sha256:9a8b7c...",
  "default_disposition": "Deny",
  "rules": {
    "business": [
      {
        "rule_id": "claim-limit",
        "condition": "action == 'authorize_claim' AND amount > 100000",
        "disposition": "ESCALATE",
        "reason": "Claims above $100k require medical director review"
      }
    ],
    "operational": [
      {
        "rule_id": "phi-access",
        "condition": "action == 'read_patient_record' AND agent.role == 'scheduling'",
        "disposition": "ALLOW"
      },
      {
        "rule_id": "phi-admin",
        "condition": "action == 'modify_patient_record'",
        "disposition": "BLOCK",
        "reason": "Only human clinicians may modify patient records"
      }
    ],
    "technical": [
      {
        "rule_id": "hardware-requirement",
        "condition": "action == 'authorize_claim' AND agent.atp.hardware_tiers.hardware_attested < 95",
        "disposition": "ESCALATE",
        "reason": "Agent attestation rate below threshold"
      }
    ]
  }
}

Scenario 1: Scheduling agent reads a patient record

  1. The agent requests read_patient_record for patient #89012.
  2. Business layer: no rule matches.
  3. Operational layer: phi-access matches — agent.role == 'scheduling'. Disposition: ALLOW.
  4. Governance trace recorded: policy healthcare-v3, rule phi-access, inputs snapshot, decision ALLOW.

Scenario 2: Claims agent authorizes $150,000 claim

  1. Business layer: claim-limit matches — amount exceeds $100,000. Disposition: ESCALATE.
  2. The claim is routed to the medical director's review queue.
  3. Upon human approval, the human's authorization is recorded as an AEA, and the claim proceeds.

Boundaries of Axiom's domain

Axiom is a governance engine, not an authority manager or execution platform.

Define authority

Axiom checks whether policy permits an action. It does not determine whether the agent holds the authority to perform it. That is Forge's domain.

Execute actions

Axiom decides; AAECP executes. The decision and the execution are separate events, each producing its own AEA.

Record execution evidence

Axiom produces governance decision AEAs. Execution evidence (tool execution AEAs, DDCs) is produced by the attestation pipeline.

Assign trust profiles

Axiom consumes ATPs as input. It does not produce them.

Replace organizational governance

Axiom is a technical governance engine. It does not replace a board of directors, a compliance committee, or a regulatory framework. It operationalizes their rules.

Operate without policy

Fail-closed behavior is enforced: an agent with a policy that cannot be loaded returns 500 POLICY_NOT_FOUND.

Axiom in the Ardyn architecture

Upstream

Decision Inputs

Forge provides authority state. ATP provides trust profiles. AEA provides the evidence substrate for trust evaluation.

Downstream

AAECP & ACTA

AAECP receives Axiom's decision and proceeds with governed execution or halts. ACTA records Axiom decisions as organizational cognition.

Lateral

Verification

Any party can replay Axiom decisions: given the policy version hash, input snapshot, and decision output, a verifier re-runs the policy engine and confirms correctness.

Independently verifiable governance decisions

Axiom decisions are independently verifiable — the governance trace is itself an AEA, making it self-contained, signed, and chain-linkable.

Policy Integrity

The policy version used to render a decision is recorded by its cryptographic hash. A verifier can confirm that the policy has not been modified since the decision was rendered.

Decision Replay

Given the policy, the input snapshot (principal identity, ATP, authority state, action parameters, environment), and the decision output, a verifier can re-run the policy evaluation and confirm that the same rules matched in the same order and produced the same disposition.

Governance Trace Completeness

Every decision carries a governance trace: the full list of rules evaluated, which matched, which did not, and why. A verifier can walk the trace and confirm that no rule was skipped and no disposition was changed.

LIVE — In-Process Policy Evaluation

LIVE IMPLEMENTED

The policy engine is implemented in crates/policy-engine and runs in-process within the Ardyn Core gateway. The 3-layer evaluation architecture (business/operational/technical, first-match-wins) is production-deployed.

Per-agent policy enforcement is wired through PUT /v1/agents/:id/policy — each agent is assigned a policy_id, and the handler path loads and evaluates the correct policy for each request. The default_disposition field (Allow/Deny/Escalate) is implemented and tested, making the no-match case explicit rather than an implicit fall-through. Fail-closed behavior is enforced.

The standalone Axiom gateway (axiom-gateway, a separate binary on ardyn-axiom:3101) provides governance services including simulation, confidence scoring, reconciliation, and the full 7-layer governance trace. The cross-service integration between Core's in-process policy engine and the standalone Axiom gateway is a planned future enhancement.

Next layers in the governance stack