OSCAL spine
One package owns every OSCAL artifact, conformance fixture, and pinned NIST reference your compliance pipeline depends on.
What it is
oscal-spine is Caisson's commercial OSCAL boundary. It turns structural evidence-pack and framework inputs into deterministic OSCAL v1.2.2 assessment plans, assessment results, POA&M fragments, catalogs, XML, and ISO 27001 SoA components. The same package owns the byte-pinned NIST SP 800-53 rev5 catalog and the own-authored OLIR relationship crosswalk checked against it.
What ships in the module
Browser-safe entry point
Import @caisson/oscal-spine/browser inside a client bundle for the contracts, crosswalk model, catalog pin, and the pure catalog and assessment-plan exporters; its id seam defaults to the WebCrypto global crypto.randomUUID (Node 20.12 or later). The main entry keeps the full node-capable surface, and every browser-entry export is also on it.
Assessment artifacts from evidence you already generated
toOscalBundle projects an evidence-pack manifest into assessment-results and POA&M report fragments, while toOscalAssessmentPlan emits the matching plan. Inputs are structural contracts, so the exporter does not reach back into the collector or storage layers.
One deterministic canonical-control catalog
toOscalCatalog deduplicates shared canonical controls document-wide, sorts frameworks, groups, and controls before emission, and accepts injected clock and UUID seams. The same inputs and seams produce byte-identical JSON.
JSON, XML, and ISO 27001 SoA targets
The package keeps the JSON model, XML conversion path, and ISO 27001 SoA component-definition exporter together, with golden fixtures and oscal-cli conformance checks covering the public formats.
NIST SP 800-53 reference bytes are pinned
NIST_CATALOG_PIN travels as one coherent record: upstream repository and path, exact commit SHA, catalog and OSCAL versions, SHA-256, and vendored filename. A drift test hashes the committed bytes instead of trusting a moving branch.
Parent imports remain source-compatible
@caisson/compliance-core and @caisson/frameworks-pack both depend on and re-export oscal-spine. Existing buyers keep their import paths; buyers who need neither parent can purchase the OSCAL surface directly.
export const NIST_CATALOG_PIN: NistCatalogPin = {
repo: NIST_CATALOG_REPO,
upstreamPath: NIST_CATALOG_UPSTREAM_PATH,
commitSha: NIST_CATALOG_COMMIT_SHA,
sourceUrl: NIST_CATALOG_SOURCE_URL,
catalogVersion: NIST_CATALOG_VERSION,
oscalVersion: NIST_CATALOG_OSCAL_VERSION,
sha256: NIST_CATALOG_SHA256,
vendoredFilename: NIST_CATALOG_VENDORED_FILENAME,
};- The source URL is derived from the exact commit SHA, never from a moving main-branch URL.
- The SHA-256 and OSCAL version travel with the source identity, so consumers cannot accidentally mix a new catalog with an old pin.
- The vendored-byte test hashes the committed JSON and compares it with this record before crosswalk validation runs.