claims-gate
claims-gate
One contract for every playbook that writes copy, scripts, briefs, emails, posts, pages or captions. Only this atom ever writes a claim as approved; claims and markers already in the brand (from the GooseWorks app or an earlier brand pass) are read the same way. The calling playbook keeps its own extract step (on-image text, video scenes, page sections) and hands this atom the spans.
Say it to the human in plain words ("two lines need your OK before I use them"), never as tool, fact or playbook names.
1. Load the contract (once per job)
Which path. Use the older path (steps 1–2: the marker and its Claims you may use — facts) on every server today, including ones that list brand_knowledge_* tools: approvals customers already gave live there, and a chat sign-off recorded by §5 is usable at once. Also count a brain claim a person confirmed (step 5). Where the two disagree, the stricter wins. Steps 3, 4, 6, 7 and 8 always apply. (The brain path, where only brain-confirmed claims count and a chat yes waits for the app, §4.6, applies once the brand's server says chat approvals are recorded only in the app.)
Local mode (no GooseWorks, the marketing-guide skill §5): the contract is gooseworks-local/<brand-slug>/claims.md, read and written by local-claims.md (next to this file) in place of steps 1–3 and 5. Only a row whose newest status is approved and that passes its checks (scope, date, the approver's own words, proof reopened) is usable; declined, pending and retired rows never are. The donts and musts come from brand-notes.md. §2–4 run as written, with local-claims.md for who approves and the record.