docs: reconcile framework doc addendum + §9 and Artifact A CVI note to two-category GLOSSARY rule

This commit is contained in:
2026-08-07 05:17:09 +00:00
parent 7e5dfad77f
commit a4d29b2e71
2 changed files with 13 additions and 8 deletions
@@ -33,12 +33,17 @@ Resolution: Delete the "Observed/Inferred" rename — it solved a problem that d
One real distinction worth preserving, not as a rename but as a note: the playbook's Tier 2 default rule — "Public observation = Tier 2 until owner access or stronger verification upgrades it" — is a *procedural* rule about how tiers get assigned, not a different taxonomy. Module A's Evidence Record schema (Section 20) should carry this default explicitly: any fact sourced from an AI engine output or public scrape starts at Tier 2 regardless of how confidently it was captured, and only moves to Tier 1 if the client confirms it directly.
Addendum — evidence authority nuance (added after Qwen review). The single Tier 1/2 scale holds, but different fact classes have different verifying authorities, and conflating them causes real confusion — "we verified the audit run happened" is not the same claim as "we verified the business fact inside it is true." Three classes:
1. Business-entity facts (name, phone, address, hours, services, categories, profile ownership). Default Tier 2 when observed publicly. Promotes to Tier 1 only via owner confirmation or owner-access verification.
2. Audit-run facts (prompt executed, engine captured, timestamp recorded, raw output stored, competitor appeared in captured output). Default Tier 1 when supported by stored filesystem/git/database artifacts — this verifies the audit *event* occurred, not that the business fact inside the output is true.
3. Public claims inside AI outputs (an engine stating the client's phone number, hours, or service scope). Default Tier 2 until owner confirmation or owner-access verification upgrades it.
Action: add this three-class breakdown to GLOSSARY under the Tier 1/2 entry, so "verified" is never ambiguous between "the run happened" and "the fact is true."
Addendum — SUPERSEDED (2026-08-06). The three-class breakdown below was
wrong: it listed "competitor appeared in captured output" as a Tier
1-eligible "audit-run fact," but that's a claim about AI-output content,
not about whether the test ran. Reconciled version now lives in
GLOSSARY.md under "## Tier 1 — Verified" — two categories (Process facts
vs. Findings), not three classes. Findings, including anything about
mention status or competitor appearance, are Indicative by definition
per the pre-existing Evidence Model section and stay that way regardless
of how the audit event itself is verified. See GLOSSARY.md for the
authoritative version; this addendum is kept here only as a record of
the error and its correction, not as current guidance.
---
@@ -298,7 +303,7 @@ Net effect: the critique doesn't change what gets built next, but it changes wha
## 9. What's now resolved vs. still open
Resolved against the actual repo — audit-playbook-v1.md, README, path-to-poc-sequencing.md, and the four existing client/template files, all pulled from main (2026-08-06):
- No evidence-model collision existed. Verified = Tier 1, Indicative = Tier 2, one vocabulary, now with a three-class authority breakdown (business-entity facts / audit-run facts / public claims inside AI outputs).
- No evidence-model collision existed. Verified = Tier 1, Indicative = Tier 2, one vocabulary, now with a two-category reconciliation (process facts vs. Findings) — see GLOSSARY.md.
- Layers 17 are the full, verified Path to PoC engagement sequence. The Stage↔Layer bridge map is confirmed, not a working hypothesis — including the Stage 4 double-duty correction (Layer 1b + Layer 4 both land there) that the sequence doc's own ordering forces.
- Layer 7/POC Delivery confirmed at Stage 5, not Stage 6 — the sequence doc's own naming confirms this was correct, not just a reasonable guess.
- Artifact A and Artifact B are trimmed to hold only content with no existing repo home, after discovering they originally duplicated data-inventory-v1.md, threat-register-v1.md, requirements-v1.md, and workflows-v1.md. Both now carry explicit Feed-Forward sections naming exact file paths, verified against live client directories (`docs/clients/overcome-fitness/`, `docs/clients/phoenix-salons/`).