Sources and verification
A requirement drafted from general knowledge reads exactly like one drafted from the statute, so the source and the date are stored as fields.
A requirement drafted from general knowledge reads exactly like one drafted from the statute, which is precisely the problem. The difference is invisible on the page and decisive in front of a regulator, so the source and the date somebody checked it are stored as fields, not left as an assumption about who wrote what.
Every regulated requirement carries three things: what it requires, where that comes from, and when somebody last confirmed it. A requirement missing the second is treated as unverified regardless of how confident its wording sounds.
The source is a citation specific enough to find — a named statute and section, a licensing body's published rule, a regulator's guidance with its date. "Industry standard" and "required by law" are not sources; they are summaries of a source somebody once had.
Anything drafted from general knowledge is marked unverified and stays that way until a citation is attached. This is uncomfortable in practice, because a great deal of ordinary compliance copy turns out to have no traceable origin, and marking it honestly makes visible how much of it was inherited from another site.
Requirements have review dates, because regulations change and a disclosure correct at publication is not thereby correct now. The review date is a field, so a stale requirement can be listed instead of waiting to be noticed.
Where a requirement varies by jurisdiction, the jurisdiction is recorded with it. A rule that applies in one state and not the next is a common source of copy that is simultaneously correct and misleading, depending on who is reading it.
Nothing here is legal advice and the boundary is stated wherever it is relevant rather than once in a footer. We build the mechanism that keeps a requirement attached to its claim, dated, and sourced; whether the requirement is correctly understood is a question for somebody qualified to answer it.
Where a client's own counsel supplies wording, it is reproduced exactly and attributed to them in the record, so a later reader can establish who is responsible for the text instead of assuming it was drafted here.
The value of the whole arrangement shows up under challenge. Being able to state what a page claimed, what disclosure accompanied it, what the source was, and when it was verified is a substantially different position from believing all four were probably fine.
What this does not cover.
- Legal advice, or judgements about whether a requirement has been correctly interpreted.
- Compliance copy adapted from another business's site.
- Requirements recorded without a citation and a verification date.
Security & Compliance
Claims and their disclosures
A claim and its required condition are one object, so a claim whose disclosure is missing cannot be rendered at all.
Data handling
The design question comes before the security question: a field that was never collected cannot leak, be retained too long, or turn up in a log.
Security posture
A description of practices, not a certification, published so it can be inspected and argued with.
Secrets and configuration
A credential committed alongside the code has been distributed to everyone who has ever taken a copy, and deleting the file does not retrieve it.
Input and trust boundaries
Anything arriving from a browser was composed by whoever is sitting there, not by the form that was designed.
Subprocessors
Every third party a system talks to holds part of what customers hand over; the list is short by design and written down.