CMMC readiness, end to end
Theme
Phase 6 drill-down: recommend, then close the loop

Recommendations

How each open gap gets a drafted fix: policy language from a standard library, worded with the client's own names, for what isn't written down; a typed remediation, naming the client's own tools, for what isn't done. Then how an adopted fix finds its way back as evidence.

693
library statements, one atomic statement per objective
0
model calls in either proposer: drafts are assembled from the data, not written
20 + 31
drafts in the synthetic Level 2 run: documentation, then remediation
49 of 51
of those accepted; both rejections were judgment calls

The whole pipeline

Two buttons on the assessment, both on the isolated runner, both reading every failing requirement.

Read or step Rows written

Drafts live in their own tables so proposed text can never be counted as coverage. Nothing here changes a mark, a POA&M status or the score.

1

Document: drafts from the standard library

For a Define objective that isn't written down anywhere.

  1. Find the unwritten objectives. For each failing requirement, take its failing Define objectives. A requirement doesn't need a POA&M to get drafts; one that can't go on a POA&M gets drafts labeled "must be met before assessment".
  2. Pick library language. Each objective links to the statements that satisfy it. Each statement says one thing, so one objective can draw more than one. An objective with no library statement still gets a draft: an empty one, flagged for a person to write.
  3. Word it for this client. Tokens such as {{company_name}} and {{it_lead}} are replaced with the client's values. Any token left unresolved is listed on the draft, never shipped silently.
  4. Say where it goes. If a client document matches the statement's owning document by name, the draft says "add to existing document" and links it; otherwise "new document needed", with a name and type.
  5. Write it as Proposed, linked to its source statement ("Based On"), the objective and the failing requirement, with a one-line rationale.

Re-running adds only drafts that don't exist yet. A draft already there is never re-created, so a rejected one stays rejected. One still Proposed is re-worded if a client value has changed since; an accepted one keeps the wording it was accepted with.

Where the client's values come from

When a document is reviewed in Phase 3, a parallel job reads it for the client's own values (company name, the person or provider who runs IT) and records each as "Extracted (verify)", quoting the passage it came from. It fills blanks only, and never touches a value a person confirmed. The consultant confirms them in their own view.

Confirm values before accepting. A draft takes the value present when it is generated, confirmed or not, and names every unconfirmed value in its notes. Confirming the value and re-running re-words any draft still Proposed.
2

Remediate: typed fixes in the client's tools

For a Perform objective that isn't actually done.

  1. Group by function. Each failing Perform objective's evidence recipe names the function that does the job (MFA, log collection, endpoint protection). Objectives sharing a function get one proposal.
  2. Check the inventory. If the client runs a product with that function, the proposal is a configuration change: "configure their tool to the required value". If not, it's acquire and implement, with up to three example products.
  3. Fill the target. The required value comes from the organization-defined parameter values where there are any; otherwise the draft says "the defined value" and leaves the target blank.
  4. Explain it in the assessor's terms: what the control checks, and what the evidence must show.
  5. No function mapped? A fallback by control type: acquire and implement for software or hardware controls, policy or process for policy controls, otherwise a generic configuration change.
Proposal typeWhenSynthetic run
Configuration changeThe client already owns a tool for the function9
Acquire and implementNo inventoried tool provides it14
Policy or processFallback, for a policy control with no function8

Proposals are separate rows linked to the failing requirement, and to its POA&M when it has one, so the consultant's Remediation Plan on the POA&M stays theirs. A requirement that can't be deferred to a POA&M gets proposals labeled "must be met before assessment".

3

Close the loop: by hand, on purpose

A draft is a suggestion. Only proof moves the assessment.

  1. Review. In the "Proposed (review)" views the consultant accepts, edits or rejects each draft. Accepted documentation is adopted into the client's real document; an accepted remediation is folded into the POA&M's plan, or, for a requirement that can't be deferred, into the work due before assessment.
  2. The client does the work. The new policy section or the changed setting produces evidence, collected in Phase 4.
  3. Link it. The consultant links that evidence to the draft through Implemented As and sets it Implemented.
  4. Re-score in Phase 5. The objective is marked MET from the evidence, the score moves, and the POA&M shows as stale until the consultant closes it.
Why none of this is automatic. Accepting a draft says the fix is right, not that it's done; marking it Implemented says it was done, not that the evidence proves the objective. Each step stays a person's decision, and only the Phase 5 marks change the score.

Decision log

The calls that shaped the recommendation phase, and when they were made.

DecisionWhyWhen
Proposals as child rows of the POA&M, not fields on itSeveral typed fixes per gap, and the consultant's plan stays untouched2026-07-22
Assemble drafts from data, with no modelEvery word traces to the library or the client's records2026-07-22
Recommendations in their own table, apart from evidenceProposed text must never count as coverage2026-07-22
Route by the evidence recipe's function, not the broad requirement-to-technology mapThe broad map fans out to a dozen loosely relevant categories per requirement2026-07-22
Harvest values across all documents, fill blanks only, never overwrite a confirmed oneA person's confirmation outranks a model's extraction2026-07-28
Resolve {{technology}} in both directions; list any leftover token on the draft14 of 31 drafts in one run carried a raw placeholder2026-09-19
Draft for every failing requirement and link the draft to the requirement; link a POA&M only where one existsStarting from POA&Ms skipped the heaviest gaps: 28 of 59 failing requirements had none, and the re-run gave them 42 documentation drafts and 27 remediations2026-09-30
Flag unconfirmed values and missing library statements on the draft itselfThe consultant reads the review queue, not the run log2026-09-30

Known gaps