Human Anchor + AI Variants

1) The core problem: fluent output can drift away from the approved message

When each AI output becomes the next generation input, the team can lose the human-approved source of truth. A variant may sound polished while dropping a qualification, changing a product claim, or being approved only because it resembles the previous AI output. This lesson does not treat fluency as authority; it requires a reproducible link from every variant back to a specific human anchor and version.

2) COM-011 scope: Anchor and Variant lineage, not the QA Rubric or channel playbooks

This lesson owns Human Anchor and AI Variant Lineage Contract v1. COM-010 owns the content QA rubric and COM-012 owns social format playbooks. The bounded question here is: which human anchor governs this variant, what was allowed to change, which claims were protected, and who had promotion authority?

3) Mental model: Human Anchor → Generation Activity → AI Variant → Diff/QA → Human Review → Promotion

A human-authored or human-approved anchor carries anchor_id and anchor_version. The generation activity records how a derivative was produced; it does not create editorial authority. Semantic/claim/style differences, deterministic QA and human review then support a typed outcome such as promotion, rework, re-review, rejection or hold.

4) FACT: W3C PROV can express lineage, but not fidelity or approval

PROV-DM models entities, activities, agents and derivations. An anchor can be represented as an entity, a generation event as an activity and a variant as a derived entity. Provenance can therefore reconstruct lineage, but it does not prove that meaning was preserved or that a human approved the result. Lineage is necessary evidence, not a substitute for review.

5) FACT: NIST AI 600-1 frames Generative AI risk through Govern, Map, Measure and Manage

The NIST Generative AI Profile is a voluntary cross-sector companion to the AI RMF. It supports lifecycle risk-governance thinking, but it does not prescribe MAKNOW anchor IDs, diff fields or promotion states. MAKNOW uses those as local design mechanisms so GAI-related decisions remain visible and reviewable.

6) Anchor contract: 22 fields to prevent silent drift

The primary artifact has 22 fields; 20 are critical to the bounded decision. style_diff and supersedes_anchor add useful explanation and version-control context. The table below shows representative states; each real variant needs its own complete row.

7) Parentage must still resolve to the human anchor

If Variant B names only Variant A as its parent and loses the governing human-anchor binding, the lineage evidence is insufficient. The correct state is BLOCKED_LINEAGE. A generated artifact may technically be used as input, but governance must preserve the governing anchor and version explicitly.

8) Declare transformation intent and allowed changes before generation

Changing tone is not the same as changing price, qualification or product claims. transformation_intent states the purpose and allowed_change_dimensions sets the permitted scope. If observed changes exceed that scope, high similarity does not rescue the variant; it moves to REWORK_SCOPE_VIOLATION.

9) Protected claims are semantic guardrails

protected_claim_ids mark claims that require new human review if materially changed. A claim_diff against a protected claim invalidates inherited approval and routes the variant to RE_REVIEW_PROTECTED_CLAIM, even when the overall text still appears similar.

10) A diff score is not an automatic approval threshold

semantic_diff, claim_diff and style_diff make differences reviewable. There is no universal score that proves a variant is safe. Difference evidence supports judgment; it does not replace it.

11) Deterministic QA and human review are separate gates

QA may check structure, field presence, source references and deterministic rules. A passing qa_run_ref is not human approval. If human_review_state is still pending, the result is BLOCKED_HUMAN_REVIEW. AI may organize evidence but cannot grant its own release authority.

12) When the anchor version changes, freeze inherited approval until revalidation

If an approved offer changes and creates anchor version 2, version-1 variants must not silently remain approved. A variant still bound to v1 moves to REVALIDATE_ANCHOR_VERSION until its relationship to v2 is checked. Some may remain valid after review; others may need regeneration or re-review. rollback_ref preserves the route to the prior governing version and evidence.

13) Major failure modes and typed states

• Missing critical anchor/evidence data → HOLD_MISSING_EVIDENCE
• AI-to-AI chain with no governing human anchor → BLOCKED_LINEAGE
• Material protected-claim change → RE_REVIEW_PROTECTED_CLAIM
• Change outside allowed scope → REWORK_SCOPE_VIOLATION
• Failed QA → REJECT_VARIANT
• Missing human approval → BLOCKED_HUMAN_REVIEW
• New anchor version without variant revalidation → REVALIDATE_ANCHOR_VERSION
• All required gates valid → VARIANT_PROMOTED

14) Lab and transfer: handle anchor v2 without deleting history

The lab evaluates eight deterministic fixtures. The task is not to ask a model which copy is “best”; it is to show from visible evidence why a variant is promoted, held, rejected or re-reviewed. In transfer, anchor v2 is created and you must decide which v1 variants remain usable from lineage and evidence alone. This lesson does not prove live publishing, rights clearance or real-world model correctness.