Reconcile assurance docs with the register and v0.4.0 profile - #17
Merged
Conversation
Docs-only. Corrects three pre-existing prose inaccuracies (out of scope for the v0.4.0 re-pin, #16), each grounded in an authoritative source the validator does not mechanically check: - data-curation is no longer "provisional": v0.4.0 PROFILE.md §5 records it was promoted from provisional in v0.2.0 (only agent-runtime remains provisional), so there is no non-blocking warning on selection. Also refreshed the adjacent RES-CURATION-002 gap gloss. (AGENTIC_ASSURANCE.md §5; adoption.yaml comment) - residual counts/status on LIVE surfaces reconciled to assurance/RESIDUALS.yaml: 8 entries — 3 RESOLVED, 4 ACCEPTED, 1 OPEN; RES-CURATION-002 RESOLVED and RES-PROVENANCE-001 the sole OPEN. (AGENTIC_ASSURANCE.md §12 table + closing; adoption.yaml human_review outstanding comment) - AGENTIC_ASSURANCE.md §2 illustrative profiles snippet now lists all four declared profiles (adds data-curation). The two DATED review records — the human_review decided[] bullet and the RESIDUALS.yaml review header — are kept as 2026-07-18 point-in-time snapshots (their original numbers were accurate for the review moment); rather than embedding a live tally into a frozen record, each now points to the live per-residual status: fields for current status. No pin, register entry, invariant, or human_review provenance field (date/reviewer/record/status/approvals) is changed. Validated from a v0.4.0 checkout: adopter exit 0 (0 ERROR/WARN, reading-order OK); drift exit 0 (no assurance policy regression). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mikim
force-pushed
the
chore/reconcile-assurance-docs
branch
from
July 24, 2026 11:43
7d43c29 to
a34864b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Assurance impact: none
Reason: Documentation reconciliation only — no assurance policy, pin, register entry, invariant, or human_review provenance field is changed.
Docs-only cleanup of three pre-existing prose inaccuracies in the assurance metadata. All predate — and are out of scope for — the v0.4.0 re-pin (#16). Each correction is reconciled to an authoritative source; the validator does not mechanically check this prose, so these drifted silently.
What changed (and why it was wrong)
1.
data-curationcalled "provisional" / "emits a non-blocking warning" — false under the pinned v0.4.0 profile.PROFILE.md§5 (v0.4.0) states data-curation "was promoted from provisional in v0.2.0 after a public adopter exercised every §6.4 obligation"; the validator'sPROVISIONAL_PROFILES = ("agent-runtime",). Corrected inAGENTIC_ASSURANCE.md§5 and theadoption.yamlprofiles comment (also refreshed the adjacentRES-CURATION-002gap gloss).2. Residual counts/status on the LIVE surfaces contradicted the register —
assurance/RESIDUALS.yamlis authoritative and holds 8 entries: 3 RESOLVED, 4 ACCEPTED, 1 OPEN, withRES-CURATION-002RESOLVED (versioned rubric landed 2026-07-18,rubricVersion1.0.0,RUBRIC.md) andRES-PROVENANCE-001the sole OPEN residual. Stale prose said "2 RESOLVED … 2 OPEN" and namedRES-CURATION-002as still open. Corrected on the current-state surfaces:AGENTIC_ASSURANCE.md§12 table + closing paragraph, and theadoption.yamlhuman_reviewoutstandingcomment. This already matchedSYSTEM.md§9 andTHREAT_MODEL.md§7, which correctly markRES-CURATION-002RESOLVED.3.
AGENTIC_ASSURANCE.md§2 illustrative snippet listed only 3 profiles — now lists all four declared profiles (addsdata-curation), matching §5 andadoption.yaml.Dated review records — kept as point-in-time snapshots (owner decision)
Two surfaces are dated 2026-07-18 review records, not live state: the
human_review.decided[]bullet inadoption.yamland the review header inRESIDUALS.yaml. Their original numbers ("7 entries: 2 RESOLVED, 4 ACCEPTED, RES-CURATION-002 left OPEN") were an accurate snapshot of the review moment, so they are kept as snapshots rather than reconciled — embedding a live tally into a frozen record would just re-introduce drift the next time a residual changes. Each now carries a short pointer to the live per-residualstatus:fields for current status.human_review.datestays 2026-07-18;reviewer,record,status, and approvals are untouched.status:is changed — only header/summary prose.Validation (before opening / updating this PR)
From a v0.4.0 checkout of
agentic-assurance-profile(pinned commit00e2fe46…), against its own schemas/validator:scripts/validate.py adopter --repo-visibility public→ exit 0, 0 ERROR/WARN, reading-order OK.scripts/validate.py drift(base =main, head = this branch) → exit 0: "no assurance policy regression against the base declaration". NoAssurance policy change:directive is required — a docs-only change touches no field the drift gate diffs (human_review.date/reviewer/record/approvals).Review
Do not merge without owner review — links is DRAFT stage (§0 handoff). No functional/site code changes; assurance metadata only.