Audit-Ready by Default: Compliance Evidence Management with the Open Knowledge Format
What the CMMC Phase 2 suspension changes, what it does not, and why evidence discipline outlives the program that asks for it.
Patrick Parker, CMMC Registered Practitioner — Altiri LLC July 2026
1. The suspension, and what survives it
On July 13, 2026, the Department of War (DoW, formerly the Department of Defense) announced the immediate suspension of CMMC Phase 2 requirements, which had been scheduled to take effect November 10, 2026. Phase 2 would have introduced third-party certification by a C3PAO as a condition of award in applicable solicitations. DoW CIO Kirsten Davies directed contracting officers to amend or modify existing solicitations and contracts carrying those requirements, and established a CMMC Reform Task Force to conduct a 60-day, top-to-bottom review of the program — placing its report to the CIO in the neighborhood of September 11, 2026.
The stated reason was arithmetic. By the Department's own account, somewhere over 100,000 defense industrial base businesses would eventually have required a third-party assessment, against roughly 100 available assessors. That math never resolved, and the cost and scheduling burden fell hardest on exactly the small and mid-sized suppliers the Department is trying to keep in the base.
Here is what the suspension did not touch:
Phase 1 remains in force. Applicable solicitations still require self-assessment against NIST SP 800-171 Revision 2, score submission through the Supplier Performance Risk System, and annual affirmation of continued compliance with all 110 requirements.
DFARS 252.204-7012 is unchanged. The safeguarding and incident-reporting obligations in the clause were never a function of CMMC and remain contractual.
False Claims Act exposure is unchanged. Compliance attestations function as binding legal certifications. Submitting inaccurate scores, signing false affirmations, or proceeding despite known gaps may expose contractors to significant financial penalties and Department of Justice cyber-fraud enforcement. Nothing about a paused certification mechanism reduces the consequence of an inaccurate statement about your own posture.
So the verification layer moved and the obligation layer did not. That distinction is the whole argument of this paper, and the past two weeks made it concrete: suppliers who organized their compliance program around booking an assessment slot now hold a plan with no date attached, while suppliers who organized it around continuously maintained evidence lost nothing at all. Whatever the Task Force recommends — a restructured certification regime, a scaled tiering by contract sensitivity, something not yet proposed — every version of it will ask the same two questions. Where is the evidence, and is it current?
This paper describes a practical way to be able to answer, using the Open Knowledge Format (OKF), an open specification published by Google Cloud on June 12, 2026, and introduces okf-grc, an open set of conventions for representing controls, evidence, policies, and findings as portable, versioned files that organizations own outright.
2. The evidence problem
Ask a compliance lead at a mid-size defense supplier where their evidence is, and the honest answer is usually a list: a SharePoint library reorganized twice since anyone maintained it, a shared drive from the previous MSP, email threads with auditors, a binder in the quality office, and the memory of whoever configured the system in question. Each artifact exists. Collectively, they do not constitute a knowledge system — and every assessment cycle turns into a reconstruction project.
Organizations that treat evidence as something to be assembled for an assessment discover, late, that assembly is the hard part: locating artifacts, determining which are current, reconciling versions, and establishing when things changed and who approved them. Organizations that treat evidence as something continuously maintained approach the same requirements with a fundamentally different posture — and, as of this month, with considerably better odds of absorbing a program-level change without a scramble.
The question this paper addresses is architectural: what should "continuously maintained" actually look like for a 50-to-500-person organization without a full-time CISO, without a six-figure GRC platform budget, and with legitimate concerns about where Controlled Unclassified Information (CUI) and compliance data are allowed to live?
3. What the Open Knowledge Format is — and why boring technology is the point
In June 2026, Google Cloud published the Open Knowledge Format, an open specification for structuring knowledge as a directory of markdown files that both humans and AI systems can read, write, and exchange. OKF formalizes a pattern that emerged from practice — often called the "LLM wiki" — and reduces it to a small set of conventions:
Concepts as files. Each unit of knowledge is one markdown file with a YAML frontmatter block. The only required field is type; title, description, tags, and timestamp are recommended.
Progressive disclosure via index.md. Each directory carries a curated index so a reader — human or machine — can navigate from the top down without ingesting everything.
History via log.md. A reserved file records changes in date-grouped entries, newest first.
Standard links. Concepts cross-reference each other with ordinary markdown links, so the knowledge forms a navigable graph in any tool.
Provenance via citations. Claims sourced from outside the bundle carry a citations section.
A conformant OKF "bundle" is, deliberately, nothing exotic: a folder of text files. No runtime, no SDK, no registry. That is precisely what makes it interesting for regulated environments, for four reasons.
It is inspectable. An assessor, an auditor, or opposing counsel can read markdown with no tooling at all. There is no export step, no proprietary viewer, and no "trust the dashboard" problem — the artifact under examination is the record.
It is diffable. Because the format is plain text, standard version control applies. Every change to every policy, procedure, and evidence pointer can be captured in a version history: what changed, when, and in which commit. Documentation change control — a thing organizations chronically struggle to demonstrate — becomes a native property of the storage format rather than a process bolted on top. Section 6 addresses what that history is and is not worth as an evidentiary matter.
It is vendor-neutral and survivable. The knowledge does not depend on any subscription remaining active, any platform remaining in business, or any consultant remaining engaged. If every vendor involved disappeared tomorrow, the organization would retain a complete, readable, versioned compliance record. For organizations weighing multi-year GRC platform commitments against a certification regime under active review, that survivability deserves more weight than it typically gets.
It is agent-legible. The same structure that lets a human navigate top-down lets an AI system answer questions from the organization's own documented knowledge, with citations to specific files — rather than generating plausible-sounding answers from nowhere. Section 7 examines what governed AI on top of a bundle looks like, and just as importantly, what it must not be allowed to do.
A minimal OKF concept looks like this:
---
type: policy
title: Access Control Policy
description: Governs how access to systems handling FCI/CUI is
requested, approved, reviewed, and revoked.
owner: J. Rivera (IT Manager)
effective_date: 2026-03-15
review_cycle: 365
timestamp: 2026-06-14
---
# Access Control Policy
Access to systems processing CUI is granted on least-privilege,
role-based assignment... See implementing controls:
[Account Management](../controls/ac-3-1-1-account-management.md)
Nothing in that file requires explanation to a technical reviewer, and nothing in it requires software to read. That is the design goal, not a limitation.
4. The mapping: OKF primitives are compliance primitives
The reason OKF fits compliance work so naturally is that its primitives correspond, almost one to one, to the things assessors ask about.
OKF primitive
Compliance function
Typed concept files
Controls, policies, procedures, evidence artifacts, findings, risks — each addressable, each owned
Frontmatter metadata
The attributes assessors request: owner, effective date, review cycle, framework mapping, status
Cross-links
The control-to-policy-to-evidence mesh that otherwise lives in someone's head
Assessor navigation: from "show me your access control posture" to the specific artifact in a few hops
log.md + version history
A change record for the documentation corpus itself — what was updated, when, by whom
Citations sections
Provenance for claims, including AI-produced answers grounded in specific concepts
Two of the 110 Level 2 requirements deserve specific mention, because for them a bundle is not merely supportive but a natural implementation vehicle for the documentation itself. Requirement 3.12.4 obligates organizations to develop, document, and periodically update system security plans; an SSP decomposed into linked, versioned concept files — one per control area, each with an owner and a review cycle — is an SSP that is actually maintainable, rather than a monolithic document updated annually under duress. Requirement 3.12.2 obligates organizations to develop and implement plans of action for deficiencies; POA&M items as tracked concepts, each linked to the finding it remediates and carrying its own milestones and status, keep the plan honest between assessments. The adjacent requirements — periodic assessment (3.12.1) and ongoing monitoring (3.12.3) — are directly served by the evidence-freshness and health-reporting practices described in Section 5.
One distinction must be stated plainly, because conflating it is the fastest way to lose an assessor's trust. A bundle's version history is an audit trail of the compliance documentation. It is not, and does not satisfy, the system audit logging that NIST SP 800-171 family 3.3 requires. Family 3.3 concerns audit records of information-system activity — logons, privileged actions, events on the systems that process CUI. A knowledge bundle contributes to 3.3 the same way it contributes to most families: as an organized home for the relevant policies, procedures, and evidence of practice. The documentation change record is valuable for entirely different reasons — demonstrating that policies are living documents, establishing when a procedure changed relative to an incident, showing review discipline — and should be presented as exactly that.
5. okf-grc: shared conventions for compliance knowledge
OKF deliberately leaves its type vocabulary open. For GRC work, a shared vocabulary is worth standardizing — it is what allows tooling to check quality, lets bundles be exchanged between organizations and their advisors, and keeps an organization's own agents consistent. okf-grc (github.com/altiri-ai/okf-grc) is an open, Apache-2.0-licensed set of conventions layered on unmodified OKF v0.1 — a conventions extension, not a fork; every okf-grc bundle remains a fully conformant OKF bundle readable by any OKF consumer.
The extension defines nine concept types — control, evidence, policy, procedure, finding, poam, risk, assessment, and decision — each with a small set of recommended frontmatter fields, plus two conventions that carry most of the practical weight.
Framework identifiers. Every control, evidence item, and finding can declare which framework requirements it relates to, using the framework's own identifier syntax behind a revision-pinned tag:
framework_ids:
- "NIST-800-171r2:3.1.1"
- "SOC2-TSC:CC6.1"
The revision pinning is deliberate. Compliance claims are version-specific: the current CMMC baseline assesses against 800-171 Revision 2, and when a Revision 3 transition eventually arrives, evidence mapped to NIST-800-171r2 should say so permanently rather than being silently reinterpreted. Given a program review that may itself change the applicable baseline, the ability to state precisely which revision a piece of evidence was mapped against stops being a nicety. Format decisions like this one are where compliance rigor either gets built in or quietly leaks out.
Evidence freshness. Every evidence concept carries an evidence_date and a review_cycle in days. Staleness is then computable: a training roster dated May 2025 with a 365-day cycle is expired, and a ten-line script can say so before an assessor does. Freshness is treated as a quality signal, never a conformance failure — an important distinction, because honest bundles contain stale evidence and gaps. A bundle with no findings, no open POA&M items, and nothing expiring reads as fabricated to any experienced assessor, and it should.
A worked example, drawn from the fictional demonstration bundle that ships with okf-grc (Meridian Machining, an invented 120-employee machine shop pursuing Level 2 — every file in it is explicitly marked as fictional):
---
type: evidence
title: Quarterly Access Review — 2026 Q2
description: Signed record of the Q2 2026 user access review
covering all CUI-scoped systems.
framework_ids:
- "NIST-800-171r2:3.1.1"
evidence_date: 2026-06-28
review_cycle: 120
owner: J. Rivera (IT Manager)
---
The corresponding control concept links to its governing policy and to this evidence; the partial control links to the POA&M item remediating its gap; and the freshness tool run against the example produces exactly what it should:
STALE evidence/training-roster-2025.md (expired 2026-05-20)
freshness: 2 fresh, 0 expiring, 1 stale, 0 unknown
That single line of tool output is the difference in posture this paper is about. The organization that sees STALE training-roster-2025 in a monthly report refreshes a roster; the organization without the report discovers the same fact in front of an assessor, twelve months past the last training cycle, with no time left to fix it.
The okf-grc repository ships the conventions specification, a conformance-and-quality linter, the freshness checker, a bundle health reporter, and the Meridian example. All of it is single-file Python with no network access and no telemetry — tooling for regulated environments should itself withstand the scrutiny its users face.
6. Two questions an assessor will ask
Both of these come up early, and a method that has not answered them in advance loses credibility at the exact moment it needs it.
Can the history be rewritten?
Version control gives you a change record. It does not, by default, give you a trustworthy one. Git history is rewritable: branches can be force-pushed, commits rebased, author dates amended. If the evidentiary claim is "we can show when this procedure changed relative to the incident," a competent adversary — an assessor, an investigator, opposing counsel in an FCA matter — will ask whether that history could have been constructed after the fact.
The answer is a set of controls on the repository itself, and they are cheap:
Signed commits. GPG or SSH commit signing binds each change to a verified identity, so authorship is attributable rather than asserted in a configurable name field.
A protected authoritative remote. Force-push disabled, history rewriting blocked, direct pushes to the main branch restricted. Changes arrive by reviewed merge.
An independent copy. A mirror or write-once backup on separate infrastructure, so the authoritative history is not solely under the control of the party whose diligence is in question.
Retention aligned to contract terms. The bundle's history should outlive the contracts it evidences, on the same schedule as other contract records.
State the resulting claim carefully. With these controls, the history is tamper-evident, not tamper-proof: alterations are detectable and changes are attributable. That is a defensible position. "The record cannot be altered" is not, and an assessor who catches the overreach will discount everything else.
Is the bundle itself in scope?
A knowledge bundle inherits the sensitivity of what it contains. Policies, procedures, and control narratives are generally not CUI. Evidence artifacts frequently are — configuration exports, system inventories, scan output, network diagrams, and anything derived from covered defense information. If those land in the bundle, the machine hosting it becomes an in-scope asset carrying the full 800-171 burden, and the "lightweight" system quietly acquires the weight of everything around it.
Two postures work, and the choice should be made deliberately rather than discovered later:
Pointer discipline (recommended for most mid-market organizations). The bundle holds concepts, metadata, and references to artifacts — with the artifacts themselves retained in an enclave that is already in scope and already protected. The evidence concept records what the artifact is, when it was produced, who owns it, when it expires, and where it lives; it does not contain the artifact.
In-scope hosting. The bundle contains CUI and the host is protected accordingly. This is a legitimate choice when an appropriate enclave already exists and the bundle can live inside it, and a poor one when it silently expands the assessment boundary.
Note also that the SSP and POA&M are commonly treated as sensitive in their own right regardless of whether they meet a CUI definition, and should be handled on that assumption.
7. Governed AI on top: what the agent may do, and what it may not
The agent-legibility of a bundle is where the compliance story meets the AI-adoption story, and it is also where the most damage gets done by wishful thinking. Stated carefully: a well-structured bundle allows an AI system to answer assessor-style questions — "show me the access control policy and when it last changed," "what evidence supports 3.1.1" — from the organization's own concepts, with citations to specific files. Answered that way, the response is checkable in seconds. If it were answered by a general-purpose model's imagination, it would be a liability wearing a confident tone.
The architecture that makes this safe has three properties, and all three are load-bearing.
Local-first. The bundle, the version history, and the AI curation process all run on infrastructure the organization controls. No CUI, and no compliance documentation, needs to transit a third-party AI service for any function described in this paper. For defense suppliers, this is not a preference — it is frequently the difference between an architecture that survives scoping review and one that does not.
Human-gated writes. AI is genuinely useful for the unglamorous curation work that documentation systems die without: triaging new material into the right place, cross-linking concepts that mention each other, flagging duplicates, keeping indexes and logs current. In the architecture described here, every AI-proposed change is prepared in isolation, checked by deterministic tooling, and either merged under narrow, pre-agreed conditions or held for human review — with changes to sensitive areas always held. The AI proposes; the record of what was accepted, and by whom, is itself part of the history.
Refusal as a feature. An agent answering from a bundle must be validated not only on what it answers but on what it declines. Asked for a penetration-test result that does not exist in the bundle, the correct behavior is "the bundle does not contain that" — not a fluent invention. Asked whether the evidence satisfies a requirement, the correct behavior is to describe the evidence and decline the assessor's judgment, which is not the agent's to render. Both behaviors can be tested, and should be, before any such system is trusted in front of a third party.
For organizations building AI governance programs, this architecture has a secondary value. It is a working, inspectable implementation of the NIST AI Risk Management Framework's GOVERN and MANAGE functions for one bounded, high-value use case, exhibiting three things those functions ask for: documented human oversight, versioned operating instructions for the AI itself, and auditable outcomes. AI governance is easier to operationalize when there is a concrete system to point at rather than a policy binder alone.
8. Honest limitations
A method earns trust partly by stating what it does not do.
A knowledge bundle implements no technical controls. It does not configure MFA, sanitize media, segment networks, or generate system audit logs. Across most of 800-171's fourteen families, its contribution is documentation and evidence management — necessary, assessor-visible, and entirely insufficient on its own. Organizations with control gaps have remediation work no documentation system can substitute for.
Documentation quality remains a human responsibility. The format guarantees structure, history, and navigability; it cannot make an inaccurate procedure accurate. Garbage, versioned and cross-linked, is better-organized garbage.
Curation is a practice, not an installation. Bundles decay without active maintenance the same way SharePoint libraries do — more gracefully, and with better instrumentation, but they decay. The freshness and health tooling makes decay visible; someone still has to act on it.
There are cases where a commercial GRC platform is the better answer. Organizations running dozens of concurrent audits, needing workflow orchestration across large compliance teams, or requiring integrated quantitative risk tooling are buying capabilities a file-based approach does not offer. The approach described here is aimed at the mid-market majority for whom those platforms are over-scoped, over-priced, and — the survivability point again — a dependency that outlives its welcome.
And none of this guarantees an assessment outcome. Nothing does, and any vendor implying otherwise is telling you something about their claims discipline.
9. Getting started
Three paths, in increasing order of assistance:
Self-directed. The okf-grc repository contains everything needed to start: the conventions, the tooling, and the Meridian example to pattern against. A capable internal IT team can stand up a bundle and begin migrating documentation without anyone's permission or purchase order.
MSP-assisted. Organizations whose infrastructure is operated by a managed service provider can split the work naturally: the MSP hosts and secures the machine the bundle lives on; the conventions and curation discipline come from the compliance side.
Altiri-delivered. For organizations that want the system deployed, their documentation migrated and mapped to 800-171 Revision 2, and the curation operated as a managed practice, this methodology is delivered commercially as the Altiri Governed Knowledge Layer (AGKL) — the productized form of the approach this paper describes, and the same architecture Altiri operates internally.
The suspension bought the defense industrial base time. It did not remove the obligation, and it did not answer the question. When the Task Force reports and whatever comes next takes shape, the organizations that clear it calmly will be the ones who can already answer: where is the evidence, and is it current?
Audit-ready is a default state, or it is a fire drill. The format is the easy part, and now it is also an open standard.
References
Department of War, announcement suspending CMMC Phase 2 requirements and establishing the CMMC Reform Task Force, July 13, 2026. Reported at Federal News Network and Breaking Defense.
WilmerHale client alert, "Pentagon Suspends CMMC Phase 2 Requirements and Launches Review of Cybersecurity Certification Program," July 20, 2026. Link
DoD CIO CMMC program materials. dodcio.defense.gov/cmmc/About
48 CFR CMMC acquisition rule; Phase 1 effective November 10, 2025.
DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting.
NIST SP 800-171 Revision 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (110 security requirements).
False Claims Act, 31 U.S.C. §§ 3729–3733. Cornell LII overview
Google Cloud, "How the Open Knowledge Format can improve data sharing," June 12, 2026. Link. Specification v0.1 published in the GoogleCloudPlatform knowledge-catalog repository.
okf-grc: GRC conventions for the Open Knowledge Format. github.com/altiri-ai/okf-grc
NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023.