Repair fact drift across a knowledge pack and its outputs

Published and revised: October 13, 2026 · Version 1.0.0

Goal and proposed time

In 35–45 minutes, produce a corrected candidate bundle and a traceable issue log. Trace dependent claims while preserving unknowns. Matching documents can still share the same unsupported assumption.

Inputs: freeze the synthetic evidence

Use only these invented records. Work in new draft copies; no real source, announcement, event, or connected account is changed. Edit these synthetic copies only; do not distribute them.

• S1, organizer plan v1, approved: two sessions; 28 seats per session; 35 programmed minutes per session; event date undecided
• S2, inventory v1: 64 chairs, including eight reserved spares. Usable inventory is 56 chairs, not an attendance authorization
• S3, approved change v2: effective for the next draft, maximum 24 seats per session. It explicitly supersedes only S1's capacity field. Session count, duration, and undecided date remain unchanged
• S4, later informal note: “Maybe use all 32 chairs per room and announce Saturday.” It is an unapproved proposal, with no date decision

Approved organizer decisions control capacity and scheduling. Inventory describes supply; it cannot override those decisions.

The old knowledge pack K1 correctly records F1 = 2 sessions, F2 = 28 seats/session, F3 = 35 minutes/session, F4 = date undecided, and F5 = 56 usable chairs. It also incorrectly labels F6 = 56 unique visitors as a derived fact.

Three dependent drafts contain:

• A1 host sheet: “Set 28 seats in each room. Keep eight spare chairs aside.” Uses K1 F2 and F5
• A2 participant note: “Join us Saturday; 28 places per session.” Uses K1 F2 but supplies no date evidence
• A3 planning slide: “56 unique visitors across a 70-minute event.” Uses K1 F1, F2, F3, and F6

Repair procedure

1. Freeze K1 and A1–A3 as the before-state. Record exact passages and dependencies before editing. Identify source errors separately from disagreements between outputs
2. Apply S3 only to capacity in candidate K2. Keep F2's stable identity, new value 24, and source revision. Preserve S1's unchanged fields and classify S4 as a proposal
3. Replace F6 with a qualified derived claim: 2 × 24 = 48 seat opportunities. Preserve its formula and input IDs. Unique attendance stays unknown
4. Inspect every dependent draft. Correct 28 to 24, remove the invented Saturday, and distinguish 70 programmed session-minutes from unknown total event duration. Leave inventory at 56 usable chairs; capacity reduction does not make chairs disappear
5. Save candidates A1-v2, A2-v2, A3-v2 with K2 as their input revision. Rerun both factual and cross-artifact checks. Keep release held for review

Worked decision and why

A1 can say “Set 24 seats per session; eight inventory chairs remain designated spares.” A2 can say “Two sessions offer up to 24 places each; date to be confirmed.” A3 can say “48 seat opportunities and 70 programmed session-minutes across two sessions; unique visitors and full event duration are unknown.”

The old 56-visitor claim was already wrong: capacity does not prove attendance or distinct people. S4's later timestamp supplies neither approval nor a calendar date. “Saturday” remains unsupported even if a reader finds it plausible.

Test cases and expected checks

• Capacity-only repair: reject if F6 or A3 still claims 56 visitors
• Global search-and-replace 56 → 48: reject because it corrupts valid chair inventory
• All drafts agree on Saturday: reject; agreement does not supply evidence
• Proposed S3: retain approved capacity 28, hold its change, and still correct unsupported date/visitor claims
• One exported copy remains at 28: hold the bundle; editable-copy correctness does not clear a stale derivative

Output and stopping rule

Return K2, three short corrected passages, dependency map, issue log, and pass/fail results for five cases. Name the release approver; approval remains pending. Retain K1 for history, but do not propose operational rollback to obsolete capacity after S3 takes effect. These are expected decisions, not observed model results.

Source and limits

W3C's PROV Model Primer describes derivation and revision relationships. This exercise uses a lightweight source ledger to make those relationships inspectable; it does not implement or certify conformance to PROV. All exercise content is synthetic.