C3PAO Assessor Guide

1 What is Axiom?

Axiom Sovereign Engine is an agentless evidence-collection and deterministic-adjudication platform designed for compliance frameworks that require technical artifact validation. It operates without installing agents on target systems, relying instead on authenticated remote probes to gather evidence.

Core Capabilities

• 216 controls mapped across 13 frameworks: NIST 800-53 Rev 5, CMMC v2.0, NIST 800-171 Rev 2, NIST 800-53A Rev 5, FedRAMP Moderate, DoD RMF, and NIST AI RMF.
• Deterministic adjudication: Each probe produces a verdict derived from observable system state. The same input always yields the same output.
• SWT3 witness protocol: Every evidence snapshot is anchored with a cryptographic witness token (Sovereign Witness Token, Tier 3) that can be independently verified.
• OSCAL-native output: All artifacts conform to NIST OSCAL schema for interoperability with eMASS, GRC platforms, and downstream tooling.

What Axiom is NOT

2 Assessor Workbench Access

Assessors receive dedicated credentials that provide scoped, read-only access to the evidence platform. These credentials are separate from the organization's administrative accounts.

Credential Provisioning

• Assessor accounts are created by the system owner prior to the assessment window.
• Multi-factor authentication is required. TOTP and WebAuthn are both supported.
• Assessor sessions are logged in the system audit trail.

Available Views

Restricted Views

Assessor accounts do not have access to system configuration, credential management, probe scheduling, or administrative functions. These restrictions ensure that assessor activity cannot alter the system under evaluation.

3 Navigating the Evidence

Controls Page

The Controls page lists all 216 controls in a sortable, filterable table. Each row contains:

• Control ID: The canonical identifier (e.g., AC-2, AU-6, SC-13).
• Status: Current verdict - PASS, FAIL, INHERITED, or ATTESTATION.
• Check Type: How evidence was collected - command, attestation, service, or policy_file.
• Severity: CAT I (High), CAT II (Medium), or CAT III (Low).
• Last Evaluated: Timestamp of the most recent probe execution.

Clicking any control row opens the detail view, which includes the full evidence payload and SWT3 anchor.

Ledger Entries

The Ledger provides a tamper-evident chronological record of every evidence collection event. Each entry includes the control ID, probe timestamp, verdict, SWT3 anchor token, and a link to the raw evidence payload. Entries flagged as TAMPERED are highlighted and should be investigated immediately.

Family Breakdown

The Families view groups controls by their NIST 800-53 family designation. This view is useful for structured walkthroughs during assessment interviews, allowing the assessor to review all controls within a domain (e.g., all Access Control or all Audit and Accountability controls) in sequence.

Evidence Observations

Each evidence observation contains:

• Raw command output: The unmodified output returned by the probe. For command-type checks, this is the stdout/stderr of the executed command.
• Command hash: A SHA-256 hash of the command string, allowing the assessor to verify that the probe command has not been altered between runs.
• Timestamp and host identifier: When and where the probe executed.
• Adjudication logic reference: The rule that produced the verdict from the raw output.

4 Understanding Verdicts

Axiom produces four verdict types. Each verdict is deterministic: the same system state and probe configuration will always produce the same result.

Check Types

5 SWT3 Witness Anchor Verification

Every evidence snapshot in Axiom is cryptographically anchored using the Sovereign Witness Token, Tier 3 (SWT3) protocol. These anchors provide tamper-evidence and allow independent verification of evidence integrity.

Anchor Format

Single Verification

Navigate to /verify and paste any SWT3 anchor token. The system will:

1. Parse the anchor segments and retrieve the referenced evidence payload.
2. Recompute the SHA-256 hash of the stored payload.
3. Compare the recomputed hash against the anchor's SHA256_12 segment.
4. Return a VERIFIED or TAMPERED result.

Enclave Integrity Check

The deterministic signature ensures that evidence payloads have not been modified after initial collection. If the recomputed hash does not match the anchor, the entry is flagged as TAMPERED and the assessor should treat the associated evidence as unreliable.

Independent Verification

Assessors may verify anchors independently using the open-source SWT3 library, without relying on the Axiom platform:

This command parses the token, retrieves the evidence payload via API, recomputes the hash, and reports the verification result. The library source is publicly auditable.

6 OSCAL Artifact Review

Axiom generates all compliance artifacts in NIST OSCAL (Open Security Controls Assessment Language) format. These machine-readable documents support automated validation and interoperability with government assessment platforms.

Generated Artifacts

NIST Validation

All generated OSCAL documents are validated against the official NIST OSCAL schemas prior to export. The validation status is included in the artifact metadata. Assessors can independently validate documents using the NIST OSCAL CLI tool.

Bundle Cross-Validation

The SSP, POA&M, and AR share a common system-id and cross-reference each other via OSCAL import-profile and back-matter links. Assessors should verify that:

• The SSP's control implementations match the AR's assessment results.
• Any FAIL verdicts in the AR are reflected as open items in the POA&M.
• The system-id is consistent across all three documents.

eMASS Import

To import Axiom OSCAL artifacts into eMASS:

1. Export the OSCAL bundle from /api/v1/bundle/export (ZIP archive containing SSP, POA&M, and AR).
2. In eMASS, navigate to the system's artifact repository and select "Import OSCAL Package."
3. Upload the ZIP archive. eMASS will parse and ingest the three documents.

Two adjustments may be required after import:

• eMASS may prompt for manual mapping of organization-specific fields not present in the OSCAL export.
• Inherited control references may require manual linkage to the provider's eMASS system record.

7 Assessment Objectives Coverage

NIST SP 800-53A Rev 5 defines 2,304 assessment objectives across all control families. Axiom maps its 216 controls against these objectives and classifies coverage into three categories.

Coverage Definitions

Why Most Objectives are Classified as NONE

NIST 800-53A defines three assessment methods: TEST, INTERVIEW, and EXAMINE. Axiom operates exclusively in the TEST domain, executing technical probes against live systems. It cannot conduct personnel interviews or examine physical documentation such as printed policies, signed agreements, or facility access logs. This is an inherent limitation of any automated evidence platform and is disclosed transparently.

Coverage Report

The full coverage mapping is available through the mock assessment endpoint:

This report includes per-objective coverage classification, the associated Axiom control (if any), and the rationale for the classification. Assessors can use this artifact to plan interview and document-examination activities for objectives not covered by automation.

Three-Layer Validation Pipeline

Evidence passes through three validation stages before a verdict is issued:

1. Collection validation: Confirms the probe executed successfully, returned output within expected parameters, and the target system was reachable.
2. Adjudication validation: Applies the deterministic rule to the raw output and produces a PASS or FAIL verdict.
3. Anchor validation: Generates the SWT3 witness token and stores the evidence payload with its cryptographic hash.

8 Mock Assessment Report

Axiom can generate a mock assessment report that simulates the structure and content of a formal assessment output. This is intended as a readiness tool for the organization and a reference for assessors during pre-assessment planning.

Access

Supported framework values: CMMC-v2.0, NIST-800-171, NIST-800-53, NIST-800-53A, FedRAMP-MOD, DoD-RMF, NIST-AI-RMF.

Report Contents

• Readiness score per family: Percentage of controls in each family with a PASS verdict. This provides a quick view of organizational strengths and weaknesses by domain.
• Gap list: All controls with FAIL or ATTESTATION verdicts, grouped by severity. Each gap includes the control ID, current verdict, raw evidence summary, and recommended remediation path.
• Interview topics: Suggested interview questions derived from PARTIAL and NONE coverage objectives. These are organized by family and reference the specific 800-53A objective identifiers.

9 STIG Provenance Chain

Every automated probe in Axiom traces directly to a DISA Security Technical Implementation Guide (STIG) benchmark. This provenance chain ensures that assessors can verify the authoritative source of each technical check.

Provenance Manifest

Each probe entry in the provenance manifest includes:

Supported Benchmarks

Axiom currently includes probes derived from four DISA STIG benchmarks:

1. Red Hat Enterprise Linux 8 STIG
2. Red Hat Enterprise Linux 9 STIG
3. Ubuntu 22.04 LTS STIG
4. Windows Server 2022 STIG

XCCDF Cross-Check

Assessors can independently validate STIG provenance by downloading the original XCCDF benchmark from the DISA STIG Library and comparing:

• The Rule ID in the provenance manifest against the XCCDF <Rule> element.
• The check command in Axiom against the XCCDF <check-content> element.
• The SHA-256 hash of the downloaded benchmark file against the hash recorded in the manifest.

This cross-check can be performed entirely outside of the Axiom platform using standard XML tools.

10 C3PAO Artifact Checklist

A machine-readable checklist of all exportable artifacts is available at:

The following artifacts are available for export during an assessment:

All endpoints require assessor-level authentication. Artifacts are generated on request and reflect the current system state at the time of export.

11 Limitations and Disclosures

Axiom is designed with transparent boundaries. The following limitations are disclosed to support accurate assessor expectations.

Scope Limitations

• Cannot conduct interviews: Axiom collects technical evidence only. It cannot interview personnel about their understanding of policies, procedures, or system operations. All INTERVIEW-method objectives are classified as NONE coverage.
• Cannot examine physical documents: Printed policies, signed memoranda of agreement, physical access logs, and similar documents are outside the platform's collection capability. These require assessor examination.
• Cannot verify organizational processes: Process maturity, training completion, and management oversight require human assessment methods that are beyond automated evidence collection.

Honest Coverage Classification

Axiom classifies 1,006 of 2,304 assessment objectives (43.7%) as having no automated coverage. This classification is intentional and reflects the platform's technical-only scope. Organizations using Axiom are expected to supplement automated evidence with manual processes for uncovered objectives.

SA-15 AI Development Disclosure

Assessor Judgment is Final

Axiom verdicts are technical observations, not compliance determinations. The assessor retains full authority to:

• Override any Axiom verdict based on additional evidence or context.
• Require supplementary evidence beyond what the platform provides.
• Determine the materiality and risk significance of any finding.
• Establish the final assessment result independent of platform outputs.