{
  "id": "axiomao:reference-architecture",
  "edition": "0.1",
  "language": "en",
  "status": "proposed",
  "title": "Reference architecture",
  "description": "A proposed architecture connecting purpose, AI management, execution, state and evidence.",
  "canonical": "https://axiomao.org/en/reference-architecture/",
  "published": "2026-10-14",
  "sections": [
    {
      "id": "three-layers",
      "heading": "Three layers, one organization",
      "paragraphs": [
        "Axiom AO — Operating System for Autonomous Organizations — proposes three cooperating layers: an execution environment, an AI management engine, and organizational software with configured behavior. The intended environment is containerized; candidate engines include Claude Code, Codex and agy. The software preserves identity, authority, work and evidence. These responsibilities remain distinct even when a small prototype runs them on one machine."
      ],
      "code": {
        "language": "text",
        "text": "Illustrative target architecture; not a deployment command\nOwner mandate\n  -> Organizational software and behavior\n  -> AI engine: Claude Code | Codex | agy\n  -> Containerized execution environment\nPersistent state and evidence connect all layers"
      }
    },
    {
      "id": "control",
      "heading": "Separate decisions from recorded transitions",
      "paragraphs": [
        "The manager chooses work and evaluates results within a mandate. Workers produce artifacts; reviewers examine them against recorded criteria. A runtime records transitions, routes messages and preserves pending obligations. It does not become a second manager merely because it schedules a wake-up. An architecture should identify exactly which component can change every mutable record, including session ownership, accepted artifacts and event acknowledgements."
      ]
    },
    {
      "id": "continuity",
      "heading": "Follow one request through the system",
      "paragraphs": [
        "Consider a request for a literature review. The organization records the request, authorizes a bounded task, delegates source collection, checks the resulting report and records acceptance. It then links a reply to the original request and preserves unfinished questions. If execution stops after acceptance, recovery should discover the existing report rather than create a second task. This trace is more informative than a diagram showing only model calls."
      ]
    },
    {
      "id": "status",
      "heading": "Target architecture and current implementation",
      "paragraphs": [
        "The inspected AxiomAO documentation identifies a local native-session development prototype, currently described as v0.3.0-dev. It uses Python and SQLite with native client processes. A container image and automated container deployment are not implemented in the documented profile. Containerization is a target design choice, not evidence of isolation already delivered. Likewise, this reference architecture is an Axiom AO proposal, not a universal standard for all autonomous organizations."
      ]
    }
  ],
  "references": [
    {
      "label": "Axiom AO — source documentation excerpts (2026-10-14)",
      "url": "https://axiomao.org/reference/implementation-evidence.md"
    }
  ],
  "related": [
    "https://axiomao.org/en/governance-and-authority/",
    "https://axiomao.org/en/resources-tools-trust/",
    "https://axiomao.org/en/implementation-and-validation/"
  ]
}