Goal

Export Argus scan results as OSCAL Assessment Results (NIST OSCAL v1.1.2, JSON) so security-controls compliance data can be ingested by GRC platforms in an industry-standard exchange format — no bespoke parsers, no manual re-keying of findings into the compliance system.

Branch: feat/oscal-export

Why

• GRC platforms (e.g. RegScale, Telos Xacta, eMASS pipelines, Paramify) ingest OSCAL natively; today Argus output (JSON/SARIF/Markdown) needs custom translation before it's useful as assessment evidence.
• FedRAMP and RMF workflows are converging on OSCAL as the exchange format for assessment artifacts. Emitting it directly turns every Argus scan into machine-readable continuous-monitoring evidence.
• Argus already knows which tool produced which finding; mapping scanners to the NIST SP 800-53 controls they exercise (e.g. gitleaks → IA-5, osv → RA-5/SI-2, checkov/trivy-iac → CM-6, clamav → SI-3, supply-chain → SA-11/SR-3) is the piece GRC tools can't reconstruct downstream.

Design anchors

• Document type: Assessment Results (AR). Findings from automated scans are assessment evidence — AR is the natural fit (not SSP, not POA&M). The 1.1.2 AR JSON schema is vendored at argus/compliance/schemas/oscal_assessment-results_schema.json for offline validation.
• New argus/compliance/ package holds the control-mapping layer and OSCAL document builder — UI-free, reporter-agnostic, so the mapping data can later back other compliance outputs.
• Delivered as a reporter (oscal), registered via the argus.reporters entry-point group in pyproject.toml like every other built-in (see argus/reporters/openvex.py for the closest precedent: a standards-body JSON format built from ScanResult).
• Schema-validated by tests, not at runtime: every generated document in the test suite must validate against the vendored 1.1.2 schema with jsonschema.

Legs (tracked)

• Control mapping registry — argus/compliance/mappings.py: scanner (and where meaningful, rule-level) → NIST SP 800-53 rev 5 control IDs; data-driven (YAML/dict), overridable via argus.yml
• OSCAL AR builder — argus/compliance/oscal.py: list[ScanResult] → assessment-results document (metadata, import-ap reference, results → observations/findings/risks, back-matter); stable UUID strategy (UUIDv5 from finding identity) so re-scans diff cleanly
• oscal reporter — argus/reporters/oscal.py + entry-point registration; writes argus-results.oscal.json; wired through reporters: config and CLI
• Validation + tests — argus/tests/compliance/ + argus/tests/reporters/test_oscal.py; fixture-driven; documents validate against the vendored schema; ≥80% coverage holds
• Docs + AI context — docs/oscal.md (what maps to what, GRC ingestion notes), docs/config-reference.md reporter entry, .ai/architecture.yaml + ADR in .ai/decisions.yaml (why AR, why vendored schema, why scanner-level mapping granularity)

Sequence

mapping registry → builder → reporter → validation/tests → docs. The mapping registry and builder land first as the pure-logic core (each independently testable); the reporter is a thin shell over them. Each leg is its own focused PR.

Done when

argus scan --config argus.yml with reporters: [oscal] produces an assessment-results JSON that (1) validates against the NIST OSCAL 1.1.2 AR schema, (2) carries per-finding control mappings and the scanner provenance already recorded by #243, and (3) imports into an OSCAL-aware GRC tool without preprocessing.

Out of scope

• Other OSCAL document types (SSP, POA&M, component-definition, assessment-plan generation) — AR's import-ap will reference a user-supplied plan URI/placeholder
• OSCAL XML/YAML serializations (JSON only; the spec treats them as equivalent)
• GRC-vendor-specific connectors or push integrations — export to file is the contract
• A composite action wrapper (can follow once the SDK reporter is stable)