Axiom Sovereign Engine - ISSM User Guide

1. Getting Started

Prerequisites

Before installing the Axiom collector, you must have:

An active Axiom tenant - provisioned by your Axiom administrator via the dashboard at /tenants. You will receive a tenant ID (e.g., YOUR_ENCLAVE) and an authentication key.
Environment variables configured - the collector requires these variables to communicate with the Axiom adjudication engine:
```
export AXIOM_AUTH_KEY="your_webhook_auth_key"
export AXIOM_DB_URL="https://your-project-url"
export AXIOM_DB_KEY="your_database_key"
```
Your Axiom administrator will provide these values. Add them to your Axiom configuration file and source it before running scans.
Network access - the collector sends evidence to the Axiom adjudication engine via webhook. Ensure outbound HTTPS is available, or use Air-Gapped Mode for disconnected environments.

1.1 Installing the Axiom Binary

Axiom ships as a single statically-linked binary. On any Linux host with internet access, run the installer script:

Cross-Platform Note: The Axiom binary runs on Linux x86_64. For Windows Server 2022 environments, Axiom's cross-platform collector automatically detects the host OS and executes PowerShell-based STIG probes for 44 Windows-specific controls across 5 families (IA, AC, CM, SC, SI).

curl -sL https://sovereign.tenova.io/install.sh | bash

The installer places the axiom binary at /usr/local/bin/axiom, creates the configuration directory at ~/.axiom/, and writes an initial config file at ~/.axiom/config.yaml. Verify the installation:

axiom --version
# Axiom Sovereign Engine v5.41.0

Tip

For air-gapped environments, see Section 7: Air-Gapped Operations for offline installation procedures.

1.2 Running Your First Scan

Once installed, execute a full-spectrum scan with provenance tracking enabled:

axiom scan --all --provenance

This command performs the following actions:

Enumerates all STIG-applicable baselines on the target host
Evaluates every applicable check across all loaded frameworks
Generates provenance anchors (SWT3) for each finding
Writes results to the local results store at ~/.axiom/results/
Pushes results to the Axiom dashboard (if connectivity is available)

A typical first scan takes 3-8 minutes depending on the number of applicable STIGs. Output includes a summary line showing your initial Sovereign Score.

1.3 Dashboard Login

Open your browser and navigate to your Axiom dashboard instance:

https://<your-axiom-host>/login

Log in with the credentials provided by your Axiom administrator. On first login you will be prompted to change your password and enroll in multi-factor authentication.

1.4 MFA Enrollment

Axiom requires MFA for all ISSM-level accounts. During enrollment:

Navigate to /settings and select MFA Enrollment
Scan the QR code with your TOTP authenticator app (e.g., Google Authenticator, Authy, or a CAC-linked authenticator)
Enter the 6-digit code to verify enrollment
Store the recovery codes in a secure location - these are single-use and cannot be regenerated

Important

MFA enrollment is strongly recommended for all ISSM-level accounts. Enroll via the /settings page after first login.

1.5 Initial Configuration Checklist

Step	Action	Verification
1	Install binary	`axiom --version` returns version string
2	Run first scan	`axiom scan --all --provenance` completes without errors
3	Log in to dashboard	Command Center loads with scan data
4	Enroll MFA	Settings page shows "MFA: Active"
5	Verify framework load	Framework selector shows all 13 frameworks
6	Set notification preferences	`/settings` page configured

2. Daily Operations

2.1 Running Scans

The primary scan command evaluates all applicable baselines:

axiom scan --all

For production environments, configure automated scanning via cron. The recommended interval is every 4 hours (CA-7 continuous monitoring):

# Add to crontab (crontab -e)
0 */4 * * * /usr/local/bin/axiom scan --all --provenance --quiet 2>&1 | logger -t axiom-scan

Targeted scans for specific STIGs or baselines are also supported:

# Scan a specific STIG
axiom scan --stig RHEL_9_STIG

# Scan a category of controls
axiom scan --family AC

# Scan with verbose output for troubleshooting
axiom scan --all --verbose

2.2 Understanding the Sovereign Score

The Sovereign Score is the central compliance metric in Axiom. It is a weighted composite score from 0 to 100 that reflects the overall security posture of an enclave. The score accounts for:

Technical control pass rate - automated check results from STIG scanning (weighted highest)
Attestation coverage - percentage of human-validated controls with current attestations
POA&M health - age and status of open Plan of Action and Milestones items
Drift status - whether the enclave has drifted from its last known-good state
KEV exposure - whether any CISA Known Exploited Vulnerabilities are present

Score Range	Status	Interpretation
90-100	Green	Assessment-ready. Minimal findings, strong attestation coverage.
70-89	Yellow	Needs attention. Open POA&Ms or gaps in attestation coverage.
50-69	Orange	Significant gaps. Active remediation required before assessment.
0-49	Red	Critical posture issues. Immediate action required.

2.3 Command Center Dashboard

The Command Center is the primary operational view in the Axiom dashboard. It provides at-a-glance visibility into:

Sovereign Score gauge - current score with trend indicator (up/down/stable)
Framework compliance cards - per-framework pass/fail/N-A counts
Recent scan history - timeline of the last 30 days of scan results
Open POA&M count - active items with aging indicators
KEV alert banner - appears when CISA KEV matches are detected
Drift indicator - shows time since last drift check and current status

Use the framework selector in the top-right corner to switch the compliance lens. All dashboard panels update to reflect the selected framework's control structure and terminology.

2.4 Drift Detection

Drift detection identifies configuration changes that have occurred since the last scan. This is critical for maintaining continuous compliance between scheduled scans.

# Run a drift check
axiom drift

# Run drift check with detailed output
axiom drift --verbose

# Compare against a specific baseline snapshot
axiom drift --baseline 2026-03-20T14:00:00Z

When drift is detected, Axiom categorizes changes by severity:

Critical drift - changes to security-relevant configuration (e.g., firewall rules, SELinux policy, authentication settings)
Warning drift - changes to monitored but non-critical configuration (e.g., service parameters, log settings)
Informational drift - benign changes captured for audit trail purposes

Tip

Add axiom drift to your cron schedule immediately after each scan to maintain continuous drift awareness. Pair it with a notification hook to receive alerts on critical drift.

2.5 CISA KEV Monitoring

Axiom integrates with the CISA Known Exploited Vulnerabilities catalog to provide real-time alerting when your enclave is exposed to actively exploited vulnerabilities.

# Sync the local KEV database with CISA
axiom kev --sync

# Check current scan results against the KEV catalog
axiom kev --check

# Boost the priority of KEV-matched findings
axiom kev --boost

KEV Workflow

axiom kev --sync downloads the latest KEV catalog from CISA and stores it locally. Run this daily or after CISA publishes updates.
axiom kev --check cross-references your scan findings against the KEV catalog. Matches are flagged with a KEV indicator in the dashboard and CLI output.
axiom kev --boost elevates the severity weighting of KEV-matched findings, which directly impacts the Sovereign Score. This ensures KEV items surface as top-priority remediation targets.

Critical

CISA BOD 22-01 mandates federal agencies remediate KEV entries within the specified deadline. Axiom tracks KEV due dates and will flag overdue items as Sovereign Score penalties. Run axiom kev --sync at least daily.

3. Framework Management

3.1 Supported Frameworks

Axiom supports seven compliance frameworks simultaneously. Each framework provides a distinct lens through which the same underlying technical findings are interpreted and reported.

Framework	Identifier	Use Case
NIST SP 800-53 Rev 5	`nist-800-53`	Primary federal security control catalog
CMMC v2.0	`cmmc-v2`	Defense industrial base contractor certification
NIST SP 800-171 Rev 2	`nist-800-171`	CUI protection for non-federal systems
NIST SP 800-53A Rev 5	`nist-800-53a`	Assessment procedures and objectives
FedRAMP Moderate	`fedramp-mod`	Cloud service provider authorization
DoD RMF	`dod-rmf`	DoD Risk Management Framework lifecycle
AI RMF	`ai-rmf`	NIST AI Risk Management Framework for AI/ML systems

3.2 Switching the Framework Lens

The dashboard supports real-time framework switching via the ?framework= URL parameter. This does not change the underlying data - it changes the presentation lens.

# View command center through CMMC lens
https://<your-axiom-host>/command?framework=cmmc-v2

# View through FedRAMP Moderate lens
https://<your-axiom-host>/command?framework=fedramp-mod

# View through AI RMF lens
https://<your-axiom-host>/command?framework=ai-rmf

You can also use the framework selector dropdown in the top navigation bar. The selected framework persists across page navigation within the same session.

3.3 The 496-Row Crosswalk

Axiom maintains a 496-row crosswalk table that maps controls across all seven frameworks. This crosswalk is the foundation of multi-framework reporting: a single technical finding is automatically mapped to every applicable control across all frameworks.

For example, a password-policy check result maps simultaneously to:

NIST 800-53: IA-5 (Authenticator Management)
CMMC v2.0: L2-3.5.7
NIST 800-171: 3.5.7
FedRAMP MOD: IA-5
DoD RMF: IA-5

The crosswalk is embedded in the Axiom binary and updated with each release. You can export the crosswalk for offline review:

The crosswalk data is accessible via the /api/v1/posture API endpoint and viewable in the dashboard at /controls.

3.4 Framework-Specific Report Terminology

When generating reports, Axiom adjusts terminology to match the conventions of the selected framework:

Concept	NIST 800-53	CMMC v2.0	FedRAMP	DoD RMF
Requirements	Controls	Practices	Controls	Controls
Sub-requirements	Control Enhancements	Assessment Objectives	Parameters	CCIs
Grouping	Control Families	Domains	Control Families	Control Families
Non-compliance	Findings	Gaps	Findings	Weaknesses
Remediation plan	POA&M	POA&M	POA&M	POA&M

Tip

When preparing for a C3PAO assessment under CMMC, switch to the cmmc-v2 lens before exporting reports. This ensures all column headers, labels, and terminology match what the assessor expects.

4. Remediation Workflow

4.1 Gap-to-Green Report

The Gap-to-Green report is the primary remediation planning artifact. It lists every non-compliant control, sorted by impact and remediation effort, with a clear path from current state to full compliance ("green").

Access the report from the dashboard at /gap-analysis, or generate it from the CLI:

axiom report --type gap-to-green --format html > gap-to-green.html
axiom report --type gap-to-green --format pdf > gap-to-green.pdf

The report includes for each finding:

Control identifier and description
Current status (Open, Partial, N/A)
DISA fix text (inline remediation guidance)
Estimated effort level (Low / Medium / High)
Cross-framework impact (which other frameworks are affected)
KEV match indicator (if applicable)

4.2 Inline DISA Fix Text and Auto-Remediation

Axiom embeds DISA STIG fix text directly into scan results. For supported checks, Axiom can apply the fix automatically:

# Scan and auto-remediate where possible
axiom scan --remediate

# Remediate a specific STIG only
axiom scan --stig RHEL_9_STIG --remediate

# Dry-run: show what would be remediated without applying changes
axiom scan --remediate --dry-run

Important

Always run --dry-run first in production environments. Auto-remediation modifies system configuration and should be validated against your change management process. Axiom logs all remediation actions to ~/.axiom/remediation.log for audit purposes.

4.3 POA&M Management and Auto-Close

Axiom maintains a living POA&M that updates automatically as findings are resolved. Key behaviors:

Auto-creation: When a scan detects a new finding, a POA&M entry is automatically created with the finding details, responsible party, and a default milestone schedule.
Auto-close: When a subsequent scan shows a previously-open finding is now passing, Axiom automatically closes the POA&M entry and records the closure date, evidence (scan result), and verification method.
Aging alerts: POA&M items that exceed their milestone dates are flagged with aging indicators. Items older than 90 days are escalated in the dashboard.

# View open POA&M items
axiom poam --list

# Export POA&M in OSCAL format
axiom poam --export oscal > poam.json

# Manually close a POA&M item with justification
axiom poam --close POAM-2026-0042 --reason "Mitigated via network segmentation"

4.4 Posture Trend Tracking

The dashboard maintains a historical timeline of Sovereign Score values. This trend data is available via the /api/v1/posture-trend endpoint and the /command dashboard view, and shows:

Daily, weekly, and monthly Sovereign Score averages
Score deltas correlated with scan events and remediation actions
Predicted trajectory based on current remediation velocity
Framework-specific trend lines when a framework filter is applied

Posture trends are critical for briefing leadership and demonstrating continuous improvement to assessors.

4.5 GSA Showstopper Detection

Axiom includes a GSA Showstopper detection engine that identifies findings which would be considered "showstoppers" in a GSA review context. These are typically:

CAT I findings with no POA&M or mitigation
Missing MFA on privileged accounts
Unencrypted data-at-rest for CUI
Expired or missing ATO documentation
Active CISA KEV findings past their remediation deadline

# Check for GSA showstoppers
axiom scan --showstoppers

# Include showstopper analysis in reports
axiom report --type gap-to-green --showstoppers

Critical

Showstoppers will halt an assessment. Resolve all showstopper findings before scheduling a C3PAO or government assessment. The dashboard highlights showstoppers with a red banner at the top of the Command Center.

5. Evidence and Attestation

5.1 Technical vs. Attestation Controls

Axiom classifies controls into two categories:

Technical controls - can be evaluated automatically by scanning (e.g., password length, audit log configuration, firewall rules). These are validated by Axiom's scan engine and produce machine-verifiable results.
Attestation controls - require human judgment or evidence that cannot be automated (e.g., security awareness training completion, incident response plan review, personnel screening). These require a Human-in-the-Loop (HITL) workflow.

The dashboard clearly distinguishes these categories. Technical controls show scan timestamps and pass/fail results. Attestation controls show the last attestation date and the attesting party.

5.2 Attestation Workflow (HITL)

The Human-in-the-Loop attestation workflow enables ISSMs and control owners to manually attest to the implementation status of non-automatable controls.

Review: Navigate to /controls to see all controls awaiting attestation.
Evaluate: Select a control and review its description, assessment objective, and any attached evidence.
Attest: Mark the control as Satisfied, Partially Satisfied, or Not Satisfied. Provide a justification narrative.
Attach Evidence: Upload supporting evidence (screenshots, policy documents, training records).
Sign: The attestation is cryptographically signed with the attesting user's identity and timestamp.

Attestations have a configurable expiration period (default: 365 days). The dashboard alerts when attestations are approaching expiration.

5.3 Evidence Ingestion

Axiom accepts evidence artifacts in multiple formats commonly used in the DoD and federal compliance ecosystem:

Format	Extension	Description
STIG Checklist (legacy)	`.ckl`	DISA STIG Viewer XML checklist format
STIG Checklist (new)	`.cklb`	STIG Manager binary checklist format
Nessus Scan Results	`.nessus`	Tenable Nessus scan export (XML)
PDF Evidence	`.pdf`	Policy documents, training certificates, signed memos

# Ingest a CKL file
axiom ingest --file scan-results.ckl

# Ingest a CKLB file
axiom ingest --file checklist.cklb

# Ingest Nessus results
axiom ingest --file vulnerability-scan.nessus

# Bulk ingest a directory of evidence
axiom ingest --dir /path/to/evidence/

5.4 SWT3 Anchor Verification

Every scan result and attestation in Axiom is anchored with a Sovereign Witness Tripwire v3 (SWT3) hash. SWT3 provides tamper-evident integrity verification for all compliance data.

Each scan result is hashed and chained to the previous result, creating a verifiable sequence
Attestations include the attester's identity, timestamp, and content hash in the SWT3 anchor
Anchors can be independently verified without access to the Axiom dashboard

# Verify SWT3 integrity of all results
axiom verify

# Verify via the dashboard
Navigate to /verify in the dashboard

# Verify via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/attest/verify

Tip

Run axiom verify before any assessment to confirm the integrity of your evidence chain. Any broken anchors indicate potential data tampering and should be investigated immediately.

6. OSCAL and Assessment Prep

6.1 OSCAL Exports

Axiom generates NIST OSCAL-compliant artifacts for interoperability with government assessment tools and processes. Three core OSCAL document types are supported:

System Security Plan (SSP)

# Export SSP via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/ssp/export > ssp.json

Plan of Action and Milestones (POA&M)

# Export POA&M via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/poam/export > poam.json

Assessment Results (AR)

# Export AR via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/ar/export > assessment-results.json

6.2 Bundle Export (Cross-Validated)

For assessment preparation, Axiom can export a complete bundle containing all three OSCAL artifacts, cross-validated for internal consistency:

# Export cross-validated bundle via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/bundle/export > assessment-bundle.zip

The bundle export performs the following validation checks:

All POA&M items reference valid control identifiers from the SSP
Assessment results map 1:1 to SSP control implementations
No orphaned findings (AR findings without SSP control entries)
SWT3 integrity chain is unbroken across all artifacts
Timestamps are consistent across documents

Tip

Always use bundle export rather than exporting individual artifacts. The cross-validation catches inconsistencies that could cause questions during assessment.

6.3 C3PAO Artifact Generation

Axiom provides API endpoints for generating C3PAO assessment artifacts. Use these endpoints to produce assessor-ready documentation:

# Generate C3PAO SSP via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/c3pao/ssp

# Generate C3PAO POA&M via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/c3pao/poam

# Generate C3PAO checklist via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/c3pao/checklist

Available artifacts include:

C3PAO assessment checklist (pre-populated with Axiom data)
SSP export in OSCAL format
POA&M export in OSCAL format
Assessment Results export
Policy bundle generation via /api/v1/policy/bundle

6.4 Mock Assessment Report (2,304 Objectives)

Axiom can generate a full mock assessment report covering all 2,304 assessment objectives from NIST 800-53A. This report mirrors what a C3PAO or government assessor would produce:

axiom report --type mock-assessment --objectives all > mock-assessment.html

The mock assessment report includes:

Per-objective determination (Satisfied / Other Than Satisfied)
Evidence citations for each objective
Risk categorization for Other Than Satisfied findings
Recommended corrective actions
Executive summary with aggregate statistics

Important

The mock assessment is an internal readiness tool. It does not replace a formal C3PAO assessment. Use it to identify and remediate gaps before the official assessment engagement.

6.5 eMASS Compatibility

Axiom exports are compatible with eMASS (Enterprise Mission Assurance Support Service). To prepare artifacts for eMASS import:

# Export POA&M for eMASS via API
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/poam/export > poam.json

# Consult the eMASS guide for field mapping
curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/emass-guide

The eMASS export maps Axiom fields to the eMASS schema, including System ID, Control Acronym, AP Acronym, CCI, Implementation Status, and Test Result fields.

7. Air-Gapped Operations

7.1 Overview

Axiom is designed to operate fully in air-gapped (disconnected) environments. All scanning, reporting, and evidence management capabilities work without network connectivity. Data transfer between air-gapped enclaves and connected management systems uses the .pulse bundle format.

7.2 Pulse Bundles

A pulse bundle is an encrypted, integrity-verified archive containing scan results, attestations, POA&M data, and SWT3 anchors. Pulse bundles enable data transfer across air gaps via removable media.

Generating a Pulse Bundle (Air-Gapped Side)

# Generate a pulse bundle with all current data
axiom pulse --generate --output /media/usb/enclave-alpha.pulse

# Generate with a date range filter
axiom pulse --generate --since 2026-03-01 --output /media/usb/enclave-alpha.pulse

# Verify the generated bundle
axiom pulse --verify /media/usb/enclave-alpha.pulse

Loading a Pulse Bundle (Connected Side)

# Load pulse data into the dashboard
axiom pulse --load /media/usb/enclave-alpha.pulse

# Load with integrity verification
axiom pulse --load --verify /media/usb/enclave-alpha.pulse

7.3 USB Transfer Procedure

For air-gapped environments, the recommended transfer procedure is:

Run scans on the air-gapped host: axiom scan --all --provenance
Generate pulse bundle to approved removable media: axiom pulse --generate --output /media/usb/pulse.pulse
Transfer removable media through your organization's approved cross-domain transfer process
Load the pulse bundle on the connected management host: axiom pulse --load /media/usb/pulse.pulse
Verify data integrity after load: axiom verify

Important

Pulse bundles are encrypted at rest. The encryption key is derived from your Axiom installation identity. Ensure both the air-gapped and connected installations are registered under the same tenant before attempting pulse transfer.

7.4 Local Scanning

In air-gapped environments, use the --local flag to ensure no network calls are attempted:

# Fully local scan (no network calls)
axiom scan --all --local

# Local scan with provenance anchoring
axiom scan --all --local --provenance

Local scanning uses the STIG content bundled with the Axiom binary. To update STIG content in an air-gapped environment, download the latest Axiom binary on a connected system and transfer it via approved media.

7.5 Local HTML Reports

Generate self-contained HTML reports that can be viewed in any browser without network connectivity:

# Generate a local HTML report
axiom report --type full --format html --self-contained > report.html

The --self-contained flag embeds all CSS, JavaScript, and chart data directly in the HTML file, ensuring it renders correctly without external dependencies.

7.6 Local SWT3 Anchors in SQLite

In air-gapped mode, SWT3 anchors are stored in a local SQLite database at ~/.axiom/swt3.db. This database maintains the full anchor chain for local integrity verification.

# Verify local SWT3 chain
axiom verify

# Export SWT3 database for archival
cp ~/.axiom/swt3.db /media/usb/swt3-backup.db

8. Multi-Enclave Management

8.1 Tenant Creation

Axiom supports multi-tenant, multi-enclave architectures. Each enclave operates as an isolated tenant with its own scan data, POA&M tracker, and Sovereign Score.

Tenants are created and managed through the dashboard at /tenants. Use the "New Tenant" form to provision a new enclave with its tenant ID, cloud provider, and deployment tier. The axiom init CLI command can generate tenant provisioning SQL for bulk setup.

When creating tenants, you can assign framework profiles to control which frameworks are active for that enclave:

All 13 frameworks are available to every tenant. Use the framework toggle in the dashboard to switch between compliance lenses for any enclave.

8.2 Portfolio View

The Portfolio View provides a consolidated dashboard across all enclaves. Access it at:

https://<your-axiom-host>/portfolio

The portfolio view displays:

Sovereign Score heatmap - all enclaves at a glance with color-coded scores
Aggregate POA&M counts - total open items across all enclaves with per-enclave breakdown
Drift summary - which enclaves have active drift alerts
KEV exposure matrix - cross-enclave view of KEV-affected systems
Trend comparison - side-by-side Sovereign Score trends for selected enclaves

8.3 Per-Enclave Monitoring

The portfolio view at /portfolio provides an aggregate view with per-enclave breakdown cards. Each enclave card displays its current Sovereign Score, trend direction, and key metrics.

Key per-enclave visibility includes:

Score breakdown - individual Sovereign Score per enclave with trend indicators
Framework selection - which of the 13 frameworks apply to this enclave
POA&M summary - per-enclave open item counts and aging
Drift and KEV status - per-enclave drift alerts and KEV exposure
Responsible parties - ISSM, ISSO, and AO assignments per enclave

Configure enclave-level settings via /settings in the dashboard or through the /api/v1/tenants API endpoint.

9. Integrations

9.1 STIG Manager Push (Coming Soon)

STIG Manager integration is planned for a future release. Axiom will support pushing scan results directly to DISA STIG Manager for organizations that maintain parallel workflows. Contact us at Sovereign tier for early access.

9.2 CI/CD Gate API

Axiom provides a REST API for integration into CI/CD pipelines. Use this to enforce compliance gates before deployment:

# CI/CD pipeline example: check compliance gate
SCORE=$(curl -s -H "Authorization: Bearer ${AXIOM_TOKEN}" \
  https://<your-axiom-host>/api/v1/posture | jq '.sovereign_score')

if [ $(echo "$SCORE < 70" | bc) -eq 1 ]; then
  echo "Compliance gate FAILED: Sovereign Score $SCORE is below threshold"
  exit 1
fi

Available API endpoints for CI/CD integration:

Endpoint	Method	Description
`/api/v1/posture`	GET	Returns current Sovereign Score and compliance posture
`/api/v1/posture-trend`	GET	Returns posture time series and assessment deltas
`/api/v1/health`	GET	Service health check - uptime, DB connectivity, last scan

9.3 AI Witness API

The AI Witness API is a cryptographic flight recorder for AI decisions. If your organization uses AI in any capacity, the AI Witness anchors every inference to the same SWT3 ledger as your security controls - providing auditable proof of AI governance for NIST AI RMF compliance.

# Anchor an AI inference to the compliance ledger
curl -s -X POST -H "Authorization: Bearer axm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "...", "response": "...", "modelId": "gpt-4", "latencyMs": 1200, "promptTokens": 150, "completionTokens": 400}' \
  https://<your-axiom-host>/api/v1/ai/witness

What the AI Witness records per inference:

AI-1.1 Prompt hashing - SHA-256 hash of the input prompt
AI-1.2 Response anchoring - SHA-256 hash of the model response
AI-1.3 Model ID tracking - which model produced the output
AI-2.1 Witness minting - SWT3 anchor for the inference event
AI-2.2 Latency threshold - PASS if response latency is under 30 seconds
AI-2.3 Token tracking - prompt and completion token counts recorded

Key Distinction

The AI Witness does not perform AI analysis or answer questions. It is a logging and anchoring system that creates tamper-proof evidence that an AI inference occurred, what model was used, and what the inputs and outputs were. This evidence satisfies NIST AI RMF governance requirements (GOVERN, MAP, MEASURE, MANAGE functions).

9.4 Real-Time FAIL Alerting

Axiom provides automatic notification when a control verdict flips to FAIL. This is critical for CAT I findings that require immediate ISSM attention. The adjudication engine includes a Verdict Router that dispatches FAIL events to configured channels.

Slack Webhook (Built-in)

The adjudication pipeline includes a Verdict Router node that sends FAIL verdicts to a Slack incoming webhook. To enable:

Create a Slack incoming webhook at https://api.slack.com/messaging/webhooks
Set the SLACK_WEBHOOK_URL environment variable on the adjudication engine
FAIL verdicts are dispatched immediately after adjudication - no polling or delay

Each Slack notification includes the procedure ID, control title, verdict, tenant, and a direct link to the ledger entry. CAT I findings (critical controls defined in your gate policy) trigger a distinct high-priority format with an explicit "IMMEDIATE ACTION REQUIRED" prefix.

Regulatory Webhook API (Enclave+)

For SIEM, GRC, and ticketing integration, the Regulatory Webhook API sends HMAC-signed compliance events to subscriber endpoints:

# Subscribe to FAIL events via the webhook API
curl -s -X POST -H "Authorization: Bearer axm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-siem.internal/webhook", "events": ["verdict.fail"], "secret": "your_hmac_secret"}' \
  https://<your-axiom-host>/api/v1/webhooks

Webhook payloads are signed with HMAC-SHA256 using the subscriber's secret. Each delivery includes:

Procedure ID, verdict, tenant, cloud provider
SWT3 Witness Anchor fingerprint
STIG severity (CAT I/II/III) when mapped
X-Axiom-Signature header for payload verification

Alert Escalation by Severity

Severity	Response Window	Alert Behavior
CAT I (Critical)	Immediate	Slack @channel mention, webhook priority flag, gate BLOCK
CAT II (High)	24 hours	Standard Slack notification, webhook delivery
CAT III (Medium)	Next review cycle	Aggregated in daily digest, webhook delivery

Operational Note

The gate policy (configured in the dashboard Settings page) defines which controls are "critical." If block_on_critical_fail is enabled, any FAIL on a critical control blocks deployment via the CI/CD gate API. Pair this with Slack alerting so ISSMs are notified the moment a blocking finding appears.

10. CLI Reference

Complete reference for all axiom CLI commands and their flags.

10.1 Core Commands

Command	Flags	Description
`axiom scan`	`--all`	Scan all applicable baselines
	`--stig <STIG_ID>`	Scan a specific STIG baseline
	`--family <FAMILY>`	Scan a specific control family
	`--provenance`	Generate SWT3 provenance anchors
	`--remediate`	Auto-apply DISA fix text where supported
	`--dry-run`	Preview remediation without applying changes
	`--local`	Fully offline scan (no network calls)
	`--verbose`	Verbose output for troubleshooting
	`--quiet`	Suppress output (for cron use)
	`--showstoppers`	Include GSA Showstopper analysis

10.2 Drift and KEV

Command	Flags	Description
`axiom drift`	(none)	Run drift detection against last scan
	`--verbose`	Detailed drift output
	`--baseline <ISO8601>`	Compare against a specific baseline timestamp
`axiom kev`	`--sync`	Sync local KEV database with CISA catalog
	`--check`	Cross-reference findings against KEV catalog
	`--boost`	Elevate severity of KEV-matched findings

10.3 Reporting and Export

Command	Flags	Description
`axiom report`	`--type <TYPE>`	Report type: full, gap-to-green, mock-assessment
	`--format <FMT>`	Output format: html, pdf, json
	`--self-contained`	Embed all assets in HTML output
	`--objectives all`	Include all 2,304 assessment objectives
	`--showstoppers`	Include GSA Showstopper analysis
OSCAL exports (SSP, POA&M, AR, bundle) are available via the API: `/api/v1/ssp/export`, `/api/v1/poam/export`, `/api/v1/ar/export`, `/api/v1/bundle/export`

10.4 POA&M Management

Command	Flags	Description
`axiom poam`	`--list`	List all open POA&M items
	`--export oscal`	Export POA&M in OSCAL format
	`--close <ID>`	Manually close a POA&M item
	`--reason "<TEXT>"`	Justification for manual closure

10.5 Evidence and Integrity

Command	Flags	Description
`axiom ingest`	`--file <PATH>`	Ingest a single evidence file (.ckl, .cklb, .nessus, .pdf)
	`--dir <PATH>`	Bulk ingest all evidence in a directory
`axiom verify`	(none)	Verify SWT3 integrity chain

10.6 Pulse Bundles (Air-Gap Transfer)

Command	Flags	Description
`axiom pulse`	`--generate`	Generate a pulse bundle from current data
	`--load <PATH>`	Load a pulse bundle into the dashboard
	`--verify <PATH>`	Verify pulse bundle integrity
	`--since <DATE>`	Filter pulse data by start date
	`--output <PATH>`	Output path for generated bundle

10.7 Tenant and Integration

Command	Flags	Description
`axiom init`	`--tenant <ID>`	Generate tenant provisioning SQL
	`--list`	List all tenants
	`--switch <ID>`	Switch active tenant context
	`--frameworks <LIST>`	Comma-separated framework IDs for tenant
`axiom push`	`--target stigman`	Push results to STIG Manager (coming soon)

10.8 General

Command	Description
`axiom --version`	Display version information
`axiom --help`	Display help and usage information
`axiom config --show`	Display current configuration
`axiom config --set <KEY> <VALUE>`	Set a configuration value
`axiom status`	Display system status and connectivity

11. Attestation Lifecycle

11.1 Re-Attestation Schedule

Attestation controls have a configurable expiration period. The default is 365 days from the date of attestation. When an attestation expires, the control verdict automatically transitions from PASS to LAPSED, which reduces the Sovereign Score.

Control Family	Default Expiry	Rationale
AT (Awareness & Training)	365 days	Annual training cycle per NIST 800-53 AT-2
PE (Physical & Environmental)	365 days	Annual facility review, inherited from provider
PS (Personnel Security)	365 days	Annual background re-investigation cycle
PL (Security Planning)	365 days	Annual plan review per PL-2
CP (Contingency Planning)	365 days	Annual BCP/DR test per CP-4
IR (Incident Response)	365 days	Annual tabletop exercise per IR-3

11.2 Expiration Handling

The dashboard provides progressive alerts as attestation expiration approaches:

30 days before expiry: Amber indicator appears on the control in the family detail page
14 days before expiry: Attestation appears in the Command Center "Expiring Soon" section
7 days before expiry: Red indicator; control flagged for immediate re-attestation
After expiry: Verdict transitions to LAPSED. Sovereign Score impact begins. POA&M item auto-created.

11.3 Bulk Re-Attestation Workflow

When multiple attestations expire within the same family (common during annual review cycles), use the Bulk Re-Attestation feature:

Navigate to the family detail page at /families/[family-id]
Click the Bulk Re-Attest button (appears when lapsed controls exist in the family)
In the modal, provide your identity and a justification narrative once. This identity is applied to all attestations in the batch.
The system processes each attestation sequentially, minting an individual SWT3 anchor per control.
A progress bar shows completion. On finish, a toast summary reports the number of attestations processed and any failures.

Tip

Schedule annual re-attestation reviews at least 30 days before the expiration date to avoid LAPSED status and Sovereign Score impact.

11.4 Attestation Chain Integrity

Each attestation event is linked to the previous attestation for the same control via the SWT3 anchor chain. This creates a verifiable history of attestation decisions. Assessors can trace the full attestation lineage for any control by viewing the attestation history on the family detail page (expandable section showing the last 10 attestation entries with date, attester, summary, and SWT3 hash).

12. Drift Remediation Workflow

12.1 Investigation Procedure

When drift is detected by axiom drift, follow this triage procedure:

Classify severity: Critical (security-relevant config), Warning (non-critical config), Informational (benign change)
Identify root cause: Was this an authorized change (patch, configuration update, deployment) or an unauthorized modification?
Check change management records: Cross-reference the drift timestamp against approved change requests or maintenance windows
Determine action: Revert, rebaseline, or escalate based on the classification matrix below

Severity	Authorized Change?	Action	Timeline
Critical	No	Revert immediately, escalate to ISSO, log incident	4 hours
Critical	Yes	Rebaseline after validation, update SSP if scope changes	24 hours
Warning	No	Investigate, revert if necessary, notify ISSM	24 hours
Warning	Yes	Rebaseline, document in change log	Next review cycle
Informational	Either	Document in audit trail, no action required	Next review cycle

12.2 Rebaseline Procedure

When drift is caused by an approved, intentional change, rebaseline the drift detector to accept the new configuration as the known-good state:

axiom drift --baseline now

This creates a new baseline snapshot at the current timestamp. All subsequent drift checks will compare against this new baseline. The previous baseline is preserved in the drift history for audit purposes.

Important

Only rebaseline after confirming the change was authorized and the new configuration meets all applicable security requirements. Premature rebaselining masks drift and creates compliance gaps.

12.3 False Positive Handling

Some drift detections are expected and benign (e.g., log rotation timestamps, ephemeral process IDs, package cache updates). To reduce noise:

Review drift output for patterns that recur on every scan
Document known false positive patterns in the drift allowlist configuration
Periodically review the allowlist to ensure it does not mask real drift

12.4 Escalation Timelines

Unresolved drift must be escalated according to the following schedule:

Critical drift (unresolved after 4 hours): Escalate to ISSO for immediate investigation and incident response consideration (IR-6)
Warning drift (unresolved after 24 hours): Escalate to ISSM for review and remediation assignment
Informational drift: Document and review at the next scheduled continuous monitoring review (CA-7)

13. Continuous Monitoring Schedule

The following table defines the continuous monitoring activities, their frequency, applicable control references, and execution method. This schedule satisfies NIST SP 800-53 CA-7 (Continuous Monitoring) requirements.

Activity	Frequency	Control Ref	How
Vulnerability scan (Trivy)	Daily (04:00 UTC cron)	RA-5	`scripts/scan-container.sh` via cron
Drift detection	Every 4 hours	CA-7	`axiom drift` via cron
CISA KEV sync	Daily	SI-5	`axiom kev --sync` via cron
Attestation review	Monthly	CA-2	ISSM reviews expiring attestations in dashboard
POA&M review	Weekly	CA-5	Review open items, update milestones, close resolved
Account review	Quarterly	AC-2	Review active accounts, disable inactive (90+ days)
Log review	Weekly	AU-6	Review audit log for anomalies, failed logins, privilege use
Merkle rollup	Daily (00:01 UTC cron)	AU-10	`scripts/merkle-rollup-cron.js` via cron
CVE-to-POA&M sync	After each scan	RA-5, CA-5	`scripts/cve-poam-sync.js` post-scan
Posture trend review	Monthly	CA-7	Review 30-day trend, brief leadership if declining
Full security gate	Before each deployment	CM-3	`axiom-security-gate.sh && axiom-gate.sh`
Annual policy review	Annually	All -1 controls	Review and update all 19 policy documents

Tip

Configure cron jobs using crontab -e under a dedicated service account. Never run scheduled tasks as root. Log all cron output to the designated logs directory for audit trail purposes.

14. Evidence Ingestion Guide

14.1 Supported Evidence Formats

Axiom accepts evidence artifacts in formats commonly used in the DoD and federal compliance ecosystem. Each ingested artifact is anchored with an SWT3 Witness Anchor for tamper-evident integrity verification.

Format	Extension	Description	Use Case
STIG Checklist (legacy)	`.ckl`	DISA STIG Viewer XML checklist	Import results from STIG Viewer or manual assessments
STIG Checklist (new)	`.cklb`	STIG Manager binary checklist	Import results from STIG Manager
Nessus Scan	`.nessus`	Tenable Nessus XML export	Import vulnerability scan results
PDF Evidence	`.pdf`	Policy documents, certificates, memos	Attach supporting documentation to controls
Any File	any	Generic file attachment	Screenshots, spreadsheets, configuration exports

14.2 CLI Ingestion Workflow

# Ingest a single STIG checklist
axiom ingest --file scan-results.ckl

# Ingest a STIG Manager checklist
axiom ingest --file checklist.cklb

# Ingest Nessus vulnerability scan results
axiom ingest --file vulnerability-scan.nessus

# Ingest a PDF evidence document
axiom ingest --file training-certificate.pdf

# Bulk ingest all evidence files in a directory
axiom ingest --dir /path/to/evidence/

Each ingested file is processed as follows:

SHA-256 hash computed for the file contents
SWT3 Witness Anchor minted with the file hash as evidence
Metadata extracted (for CKL/CKLB/Nessus: control mappings, findings, severity)
Anchor recorded in the Compliance Ledger with the source file reference

14.3 Evidence Retention Policy

Evidence retention periods are determined by the tenant's subscription tier:

Tier	Retention Period	Notes
OPEN (Free)	7 days	Sufficient for evaluation and demo purposes
PRO	90 days	Covers quarterly assessment cycles
ENCLAVE	365 days	Full annual audit cycle coverage
SOVEREIGN	Unlimited	Complete evidence history preserved indefinitely

Important

SWT3 Witness Anchors persist beyond the evidence retention window. Even after raw evidence is purged, the cryptographic anchor remains in the ledger as proof that the evidence existed and was verified at the recorded timestamp. This is the core value proposition of the SWT3 Clearing Protocol.

14.4 Dashboard Ingestion

Evidence can also be ingested via the dashboard at /evidence (admin-only). The web interface supports drag-and-drop file upload with the same format support and SWT3 anchoring as the CLI.