[chaksaray]

Closes #326.

Three commits: data, docs, CI.

Before -> after, per framework

Framework	Tagged	Real pin before	Real pin after	unknown after
owasp_mcp	87	87	87	0
owasp_asi	74	74	74	0
mitre_atlas	54	4	4	50
nist_ai_rmf	56	0	0	56

66 entries added across 61 records, all {"pin_status": "unknown", "read_date": "2026-10-15"}. Zero real pins added: no citable source exists for any of the 66.

Evidence search

mitre_atlas (10 gaps): git log -S'"mitre_atlas"' on each record back to the commit that added the mapping, then read that commit's message/PR. All 10 verified the technique against MITRE's own ATLAS data at the time ("confirmed against MITRE's own ATLAS data repository," etc.), but none cites a dated snapshot, version, or commit sha. No citable pin for any of them, so all 10 are unknown.

nist_ai_rmf (56 gaps): git log --all -i --grep "AI RMF" across the whole history finds no dated verification event, only the field's own creation commit and two unrelated record-addition commits that happen to mention the framework. No citable pin exists, so all 56 are unknown.

A real finding beyond the backfill itself

docs/terms-relationships.md had a specific, checkable claim about the 40 pre-existing mitre_atlas entries (from #260): that they covered "the ones a dated, citable audit event actually verified." Checked directly against the live records before writing the doc update: every one of those 40 (now 50, after this PR's 10 more of the same kind) has pin_status: "unknown", not a verified pin. That clause was never accurate. Corrected in the docs commit rather than carried forward silently; see that commit's message for the full reasoning.

Mutation-check: the CI step actually bites

Before committing the CI change, temporarily removed AVE-2026-00001's nist_ai_rmf entry and ran --strict:

records/AVE-2026-00001.json | exit: 1 | FAIL: 1 of 87 record(s) carry a framework mapping with no corresponding framework_sources entry: AVE-2026-00001 (nist_ai_rmf)

Then restored the file; git diff --stat records came back empty, confirming nothing was left dirty.

Serialization note (not in the original task brief, found before writing anything)

The records use a custom formatter that collapses short arrays onto one line; plain json.dumps(record, indent=2) does not reproduce that (74 of 87 records fail a byte round-trip under it, checked directly before writing the backfill script). A full-file reserialization would have reformatted every short array in every touched file, far beyond the intended change. Instead, each new entry is spliced into the existing framework_sources block's raw text (all 61 records already had one, just missing a sub-key), matching the file's own object-nesting indentation exactly, confirmed against records/AVE-2026-00001.json's existing entries and against PR #264's own diff (a clean, minimal insertion with zero reformatting elsewhere, the same pattern this follows).

Rebase note

This branch was cut before several other PRs from the same session landed on develop (the ThM-wording correction, the vendor-neutrality cleanup, the main/develop sync). Rebased onto current origin/develop before pushing; the diff below reflects that, not a second round of changes.

Validation

• python scripts/validate_records.py -> all 87 records valid
• python scripts/check_framework_sources.py --strict -> exit 0, no warning line
• python scripts/check_confidence_signal.py -> 9 finding(s) across 8 of 87 record(s), unchanged from the pre-backfill baseline
• python scripts/check_confidence_signal.py --ratchet-since origin/develop -> all 61 edited records state evidence_vantage where the high band requires it
• python scripts/check_terms_sync.py -> docs/terms.md matches the live schema
• pytest tests -q -> 519 passed
• git status --short dist/ -> empty
• git diff origin/develop | grep '^+' | grep -c $'—' -> 0

After this merges, the "Regenerate consolidated records JSON" workflow will open the dist/ sync PR on its own; someone should confirm dist/ matches records/ once that lands.