# Source map and completed repairs

The business records and ownership assumptions are synthetic. The named source filenames below identify the frozen supplied materials.

| Source | Facts used | Completed output |
|---|---|---|
| merchant.json | Product, care, dates, condition, policy, named owners, operating hours, cost assumptions | Care, returns, SOP, runbook, ledger and case drafts |
| forcing_answers.md | Sole owner, ownership reference, review cadence, canonical library, data scope, hold and recovery rules | Page metadata, navigation, escalation and recovery |
| sop.json | Trigger, scope, inputs, outputs, three-step outline, 10-minute/$5 estimate | Original generator scaffold completed into SOP |
| runbook.json | Three named steps, 3/4/3 minutes, observable states and holds | SOP and runbook checks, English step titles |
| kb_before/care.md | Correct care facts but no inbound navigation | Linked care page with approved reply |
| kb_before/returns.md | Stale review and conflicting role expansion; no usable policy | Complete merchant-backed returns policy |
| kb_before/runbook.md | No owner, no steps, conflicting role expansion | Complete named three-step runbook |
| kb_before/index.md | Incomplete navigation | Index linking all canonical pages |

The care facts did not conflict with the merchant record. The observed wording conflict was the CSM expansion; the new glossary standardizes the historical label as Customer Success Manager, while operative instructions name Mia or Alex. This editorial convention does not create a new merchant role.

No external policy, measured sales result or operational improvement was invented. The supplied weekly business figures were unrelated to knowledge-base repair and were not used. Numbered snapshots and the next-business-session queue review are explicit operating conventions added to make the supplied rollback and pending-state requirements executable.