Legal pages: drafted from the code, held to it

A privacy policy is the one document where a confident guess is a legal problem: a page that promises a deletion the code does not do is the one a customer's counsel reads. So the pages are built like the rest of the product, while it is built: the agent drafts them from what the code collects, stores and sends, a test fails when the code and the pages part, and the owner supplies the facts only they have and approves the text. This is a method for keeping legal text true, not legal advice; the owner, or their counsel, decides what the pages say.

It was learned on a monitoring product and a live Q&A product, named here only by kind.

When it applies

• During the build, before the first stranger is asked for anything: a sign-up, an email address, a payment. The pages land with the public front door, and until then the deploy's URL is shared with nobody (for a SaaS, stage 8 of app-lifecycle). Before that, a placeholder behind each legal link says the text comes before launch and holds no sentence of policy, so it promises nothing the code must match.
• In the change that alters what a page describes: a new provider, an analytics tag, a cookie, a retention job, a model provider that reads what people type. The page changes in the same change, never before it and never after.
• At go-live, the release-gate skill confirms they match the code; at a review, the intended-vs-implemented skill reads them as documented intent. Neither is where they are written.

What binds