If you're pursuing FedRAMP 20X, you've likely encountered the Consistency Between Formats requirement (CDS-CSO-CBF).
FedRAMP 20X introduces a major shift in how certification data is handled: providers must now publish their data in two formats:
Human-readable — a version for people
Machine-readable JSON — a version for agency automation
CDS-CSO-CBF is the MUST-level requirement governing how these two outputs relate to each other. It mandates that both formats be generated from a single, unified source of truth so that when data changes, both formats update automatically, without human intervention.
The Shift from Legacy FedRAMP
Historically, FedRAMP documentation was purely human-readable—packages were submitted as Word documents, PDFs, and spreadsheets. For most providers, machine-readable JSON isn't something that already exists; it's a net-new requirement.
The natural impulse is to build JSON as a secondary step: publish document version first, then generate the JSON later via an export script. CDS-CSO-CBF explicitly forbids this pattern. It requires single-source generation from day one, preventing JSON from becoming a fragile, bolt-on process that engineers have to remember to re-run.
What This Prevents: Desynchronization
Imagine a provider whose service list changes: a security category gets revised, or a new service gets added. If the two formats are produced separately, that change can land in the human-readable list right away, while the JSON version keeps reflecting the old data until someone regenerates it. Nothing about the provider's website or file looks broken in the meantime — the page loads normally, and the JSON still validates against its schema — but it no longer reflects the provider's actual authorization. That's the situation CDS-CSO-CBF is designed to rule out, by requiring both formats to come from a single source instead of being maintained side by side.
This is also why a manual process, even a reliable one, doesn't satisfy the requirement. A team that updates both formats by hand every time something changes can, in principle, keep them consistent. But that consistency depends on a person doing the right thing every time, and processes that depend on someone doing the right thing every time eventually break — someone's out, or a change goes out under time pressure and the second step gets pushed to later. CDS-CSO-CBF holds this as a MUST-level requirement, which means a process that mostly works isn't enough: propagation has to happen automatically, every time, as a direct result of the source data changing.
How NYLE Handles This
NYLE resolves this by storing each authorized service—along with its security category and Minimum Assessment Scope status—once in a single record.
Both the human-readable view and the JSON payload are rendered directly from that single record at request time. Because there is no secondary file or export step, an update to the underlying record instantly updates both formats by design.
Assessing Your Compliance Gap
If your team currently publishes both formats manually, you can audit your setup with a simple test:
Change a single entry in your human-readable list and track what it takes for the JSON version to reflect that change.
If that update requires an engineer to run a command, execute an export script, or trigger a build, that manual step is the exact compliance gap CDS-CSO-CBF requires you to close.