Start here · Architecture

Architecture overview.

A 10-layer architecture: provider adapters, cloud snapshots, signal engine, reasoning, execution planning, approval/governance, audit, monitoring/drift, operational memory, ReleaseOps. Web today, desktop preview, multi-cloud expanding.

Read this if

You're evaluating Axiom for enterprise deployment, considering acquiring or building integrations, or need to explain Axiom internally to security/IT/compliance.

01 · Form factor

The platform form factor

Axiom runs as two surfaces that share the same operational data:

  • Web platform — available today. Browser-based operational command center, full feature set across cloud ops + ReleaseOps + topology + memory + workflows + approvals.
  • Desktop application — macOS preview today. Windows Q2 2026. Linux Q3 2026. Adds local Terraform execution, OS keychain credential storage, native notifications, workstation mode (no outbound network).
  • CLI binary — available now via brew/scoop/npm. Headless scans, plans, approvals, applies for CI/CD pipelines.

All three share the same operational memory and audit fabric.

02 · Layers

The 10 architectural layers

From bottom (cloud APIs) to top (release coordination):

  1. 01

    Provider adapter layer

    Read-only connectors for AWS (live), Azure (scan + topology live, reasoning Q2 2026), GCP (scan + topology live, reasoning Q3 2026). Each adapter normalizes provider-specific responses into a typed snapshot.

  2. 02

    Cloud snapshot layer

    Typed resource graph per scan — compute, storage, network, identity, observability — with provider tags and region scoping. Snapshots persist immutably and feed every downstream layer.

  3. 03

    Signal engine

    Pure functions over snapshots that produce findings: cost waste, security exposure, drift, performance, compliance gaps. Each signal is deterministic, testable, and traceable.

  4. 04

    Reasoning layer

    12-step cognitive loop (observe → interpret → reason → plan → verify → execute) that turns findings into prioritized, dependency-aware recommendations. Every step is auditable.

  5. 05

    Execution planning

    Phased Terraform / CLI generation with blast-radius classification, pre-flight snapshot capture, measured rollback RTO, and safety check pre-conditions per item.

  6. 06

    Approval + governance

    Multi-tier approval gates (low / medium / high risk). Trust Ladder model for measured autonomy escalation per action class. Cannot self-escalate.

  7. 07

    Audit fabric

    Immutable AxiomAuditEvent ledger for every action — provider mutations, approvals, rollbacks, user operations. SOC 2 / ISO 27001 control mapping built in.

  8. 08

    Monitoring + drift

    Continuous detection of out-of-band changes. Recurring workflows for cost anomaly watch, compliance sweep, post-execution verification, and rollback orchestration standby.

  9. 09

    Operational memory

    90-day persistent history of scans, recommendations, executions, approvals, outcomes. Per-service confidence calibration. Powers the agent's recalibration over time.

  10. 10

    ReleaseOps layer

    Deployment intelligence + governance above CI/CD systems (GitHub, GitLab, Azure DevOps, Jenkins, ArgoCD, ServiceNow). Shares topology, memory, reasoning, audit with cloud ops.

03 · Data flow

How data flows

A typical scan-to-execute lifecycle traces all 10 layers:

  1. Connector adapter (01) assumes IAM role, enumerates resources, normalizes responses
  2. Snapshot (02) persists the typed resource graph
  3. Signal engine (03) produces deterministic findings
  4. Reasoning (04) prioritizes findings + builds recommendations
  5. Execution planner (05) generates phased Terraform with rollback paths
  6. Approval gate (06) routes to the right approver tier
  7. Apply happens — audit fabric (07) records every step
  8. Monitoring (08) verifies the outcome and watches for drift
  9. Memory (09) records the outcome for future confidence calibration
  10. ReleaseOps (10) overlays release events onto this same operational graph

04

Multi-tenant isolation

Multi-tenant on shared infrastructure, isolated at every layer:

  • Database rows are scoped to organizationId; queries always filter through tenant scope
  • Operational memory is per-org; confidence in one org never influences another
  • Per-connection External IDs prevent cross-tenant role assumption
  • Audit log export is org-scoped at the API layer

See security model for the full isolation breakdown.

05

Deployment patterns

  • SaaS multi-tenant — default; available on all tiers
  • Single-tenant SaaS — Enterprise tier; dedicated database, dedicated reasoning quotas
  • Customer-hosted control plane — Enterprise tier; deploys via Helm/Terraform into your own cloud; all data stays in your VPC
  • Air-gapped workstation — Desktop Enterprise tier; local reasoning model + workstation mode; no outbound network whatsoever

Trust questions

What is this architecture optimized for?

Auditable autonomy — the system can act, but every step is observable, reversible, and policy-bounded.

Why 10 layers?

Each layer is independently auditable and replaceable. Signal engine can be tuned without touching reasoning. Reasoning can evolve without affecting audit.

Is the data flow safe?

Yes — read-only at provider layer; reasoning runs server-side in your tenant; execution requires approval; audit captures everything.

What does Axiom store across layers?

Snapshots, findings, plans, audit events. Never credentials, never object contents, never secret material.

What if I need air-gapped?

Desktop Enterprise tier with workstation mode + local reasoning model. No outbound network beyond direct AWS API.

How do I integrate?

REST API for read paths (operational memory, audit export, readiness scores). Webhook delivery for events. Connector framework for new providers.

Need a human?

Most flows are documented — but we'll help if anything is unclear.

Talk to Vision XIX Labs