--- title: "KYE Protocol™ — OSCAL compatibility | NIST 800-53A · FedRAMP · component definition · SSP · assessment results" description: "KYE Protocol™ is OSCAL-native: every signed evidence pack maps deterministically to NIST OSCAL component-definition, system-security-plan and…" url: https://kyeprotocol.com/oscal/ lang: en source: "KYE Protocol" --- > KYE Protocol™ is OSCAL-native: every signed evidence pack maps deterministically to NIST OSCAL component-definition, system-security-plan and… OSCAL compatibility # Map KYE™ evidence into NIST OSCAL. KYE Protocol™ publishes a deterministic mapping from every signed artefact to NIST OSCAL `component-definition`, `system-security-plan`, `assessment-results`, `assessment-plan`, `poam`, and `profile` JSON — the same documents FedRAMP 3PAOs, DoD eMASS, and enterprise GRC tools (Drata, Vanta, Hyperproof, AuditBoard) consume. **v1.0 ships the mapping spec; the exporter ships with v1.1.** Why this matters ## OSCAL is the interchange format for compliance. NIST OSCAL (Open Security Controls Assessment Language) is the machine-readable representation of NIST 800-53, FedRAMP, and increasingly ISO 27001:2022, SOC 2, and CMMC controls. Without an OSCAL bridge, KYE™ evidence packs would need custom ingestion in every downstream tool. **With it, KYE™ drops in.** - **FedRAMP authorisation packages** ship as OSCAL today (component-def, SSP, SAR/SAP, POA&M). - **DoD eMASS** ingests OSCAL assessment-results. - **3PAO assessors** use OSCAL to draft Security Assessment Reports. - **Enterprise GRC tools** — Drata, Vanta, Hyperproof, AuditBoard, ServiceNow GRC — have OSCAL importers in production or beta. - **EU AI Act notified bodies** are evaluating OSCAL-style machine-readable submission for Title III high-risk technical documentation. Mapping spec v1.0 ## KYE™ → OSCAL: deterministic, signed, replayable. Each KYE™ artefact maps 1:1 to an OSCAL document type. The KYE™ Compliance Mapping Rail™ provides the binding from KYE™ control identifiers (`KYE-EUAIACT-001`, etc.) to OSCAL `control-id` values in the relevant catalog. KYE™ control IDs are stable across catalog versions. KYE™ profile OSCAL `component-definition` A KYE™ profile (e.g. `pep`) becomes an OSCAL component-definition declaring which NIST 800-53 controls the profile satisfies, with one `implemented-requirement` per binding and the binding source URN as `link.href`. **OSCAL ref:** [component-definition metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_component_metaschema.xml) KYE™ entity registry + delegation chain OSCAL `system-security-plan` The KYE™ entity registry plus its delegation chain produces the `system-implementation` section of the SSP — component inventory, user/role mapping, authorisation boundaries, data-flow declarations. **OSCAL ref:** [system-security-plan metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_ssp_metaschema.xml) KYE™ evidence pack OSCAL `assessment-results` A signed KYE™ evidence pack — including decision logs, recovery proofs, and signal-bus telemetry — renders as an OSCAL assessment-results document with one `finding` per control, evidence linked by URN. **OSCAL ref:** [assessment-results metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_assessment-results_metaschema.xml) KYE™ Self-Audit™ run OSCAL `assessment-plan` A scheduled KYE™ self-audit run becomes an OSCAL assessment-plan: scope, controls under test, methods, schedule, and signing keys all declared in machine-readable form. **OSCAL ref:** [assessment-plan metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_assessment-plan_metaschema.xml) KYE™ recovery + signal events OSCAL `poam` Open recovery requests, unresolved signals, and failed self-audit checks aggregate into a Plan-of-Actions-and-Milestones (POA&M) document — with each item carrying its KYE™ URN and target close date. **OSCAL ref:** [plan-of-action-and-milestones metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_poam_metaschema.xml) KYE™ control catalog binding OSCAL `profile` A regulator profile (FedRAMP Moderate, NIS2, EU AI Act) becomes an OSCAL profile that selects controls from the relevant catalog and declares parameter values. KYE™ profile mapping rides on top. **OSCAL ref:** [profile metaschema (NIST OSCAL repo) →](https://github.com/usnistgov/OSCAL/blob/main/src/metaschema/oscal_profile_metaschema.xml) Implementation status ## Where the OSCAL exporter is today. - v1.0 **Mapping spec** — published with this page; the deterministic KYE™ → OSCAL binding rules. - v1.1 **OSCAL exporter (component-definition + assessment-results)** — in development; ships with v1.1 of the SDK family. `POST /v1/oscal/export` takes an evidence-pack URN, returns OSCAL JSON validated against the upstream schemas. - v1.2 **OSCAL importer (profile + catalog)** — consume an OSCAL profile (e.g. FedRAMP Moderate) and produce a KYE™ control-binding skeleton. - v2.0 **Full OSCAL round-trip** — SSP + SAP + SAR + POA&M; integrations with FedRAMP automation, eMASS, and the major enterprise GRC importers. **Conformance:** the exporter validates output against NIST’s upstream OSCAL JSON schemas ([github.com/usnistgov/OSCAL](https://github.com/usnistgov/OSCAL)) before returning. Drift is a hard fail, not a warning. Where to go next ## Pick the path that fits. [Per-framework reference →](https://kyeprotocol.com/frameworks/) [Compliance overview](https://kyeprotocol.com/compliance/) [For auditors](https://kyeprotocol.com/auditors/) [SDK reference](https://github.com/KYE-Protocol) Talk to us ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).