Policy as code & evidence

AXIOM

Encode compliance controls as machine-readable policy and produce evidence continuously. Controls stop being paragraphs in a document and become specifications your systems are evaluated against.

Explore the platform

The problem

Compliance requirements live in static documents

Evidence is collected manually before audits. Control mappings are maintained in spreadsheets. AXIOM treats compliance requirements as structured data: policy rules are defined in a declarative format, versioned alongside your code, and evaluated against your systems continuously. When controls are satisfied, evidence is captured automatically and bound to the relevant control implementations — a traceable chain from requirement to technical proof.

AXIOM exists to codify compliance — not document it.

Core capabilities

What it does

Versioned policy rules

Compliance defined as code, with full version history alongside the systems it governs.

·Declarative policy DSL and YAML rules
·Checks for code, IaC, configuration, and runtime
·Every rule change is itself auditable

Control crosswalks

One implementation, mapped across every framework that requires it.

·NIST 800-53 Rev 5 library with enhancements
·FedRAMP, CMMC, FISMA, DoD RMF, CNSSI 1253 overlays
·STIG mappings included

Inheritance engine

Classifies every control before anyone writes a narrative.

·Inherited, shared, customer-owned, manual, or N/A
·Cloud provider FedRAMP inheritance
·Resource graph links repos, services, and controls

Evidence binding

Timestamped, hashed evidence bound to control implementations at capture time.

·Automatic binding on control satisfaction
·Integrity hashes on every artifact
·Original scanner output preserved

Manual evidence workflow

For the controls automation cannot reach — PS, PE, and AT families.

·Evidence upload with expiry tracking
·ISSO digital attestation
·Human review queues

OSCAL generator

Machine-readable authorization artifacts, generated from live control state.

·SSP, assessment plan, assessment results
·POA&M artifacts
·Schema-valid OSCAL 1.0 export

How it works

Step-by-step lifecycle

01
Policy defined
Compliance rules are encoded as structured, version-controlled policy code — reviewed and merged like any other change.
02
Controls mapped
Technical implementations are linked to compliance controls across frameworks through the control library and overlay crosswalks.
03
State resolved
The control-state resolver aggregates scanner outputs, runtime state, attestations, and inherited controls into a single control status.
04
Evidence captured
Satisfied controls bind evidence automatically — timestamped, hashed, and stored in the vault with provenance intact.
05
Packages exported
Auditor-ready OSCAL bundles with integrity verification: SSP, assessment results, and POA&M, generated rather than assembled.

Example scenario

Live control status, not a quarterly spreadsheet

An ISSO opens the control baseline mid-sprint. Status reflects the running system as of minutes ago — automated checks, inherited controls, and manual attestations resolved into one view.

Illustrative example. Not real customer data.

Demo · Illustrative only

AC-3 · Access enforcement

Automated checkPASS

CM-6 · Configuration settings

Drift detected by PHAROSFAILING

PE-3 · Physical access control

ISSO attestation currentMANUAL

Inherited from cloud provider

42 controlsINHERITED

OSCAL SSP

Regenerated from live stateCURRENT

Audit output

What AXIOM generates

Evidence packages with integrity hashes
Control crosswalk mappings
Control implementation statements
OSCAL SSP, assessment plan, and results
POA&M artifacts
Audit-ready documentation bundles

The boundary

Policy in AXIOM feeds enforcement in RAMPART.

AXIOM defines. RAMPART enforces. PHAROS observes. Every policy decision is traceable, versioned, and auditable — and no engine asserts a status another engine can't verify.

The other engines