For founders and engineers who can read their own schema
Line & Clause reads your repository first, then asks you only the three things a repository cannot answer. What you get back is a draft in which every sentence traces to a file and a line, or to an answer you gave on the record. It is not a lawyer and it will never tell you that you are compliant.
This proves an element is absent. It cannot prove one is adequate, and it is not a statement that you are compliant. The rules are compiled from the same JSON the command line reads, and a build-time parity test requires identical findings from both.
You have published a privacy policy. Almost certainly it came from a generator, and almost certainly the generator asked you about twelve things.
Your company name. Your country. Do you use analytics. Any users in Europe. Do you
sell data, which you answered no to, and were right to. Four minutes later you had
eleven pages of confident prose with your logo at the top, and you put it at
/privacy and moved on, because there were eleven other things to do that
week and this one was finally done.
Here is what nobody says out loud about that document.
It is a factual claim about a technical system. The claim reads, in effect: this is the personal data this software holds, these are the parties it goes to, this is how long it stays. And the only witness ever deposed about that system was you, from memory, in a form, in four minutes.
So answer one question, and be honest, because nobody is watching.
Does your published policy mention the ip_address column in
your sessions table?
Not because the generator is bad software. Because a form cannot ask a question about a thing it has never seen.
It did not ask which columns hold free text, or whether any user has ever pasted something into one of them that a regulator would treat as special category data, which is the legal term for health, religion, politics, sex life, biometrics and a few others. It did not ask what your error monitor receives when an exception carries a request body. It did not ask whether your session table stores an IP address, because you do not think of a server log as data you collect, and neither does anyone else, which is precisely why it is the single most under-disclosed processing in small software companies.
It did not ask what your marketing page loads. It did not ask whether the analytics script runs before anything asks permission, or whether the thing you carefully proxied through your own domain is still, in substance, a third party's collection.
And the question that actually decides the document went unasked entirely: why. Why do you hold that column. Under what basis. For how long. A form cannot answer those either, but at least a form knows it is asking you.
The result is not a wrong document. A wrong document you could read and catch.
The result is an incomplete document, and incompleteness is invisible from the inside. You cannot proofread an omission. Read your own policy twenty times and you will never once notice the paragraph that is not there.
There is one thing you can catch, though, and you can catch it in the next ten seconds.
Open the document you have live and search it for the word “periodically.”
If it says something like please check this page periodically for updates, that sentence is not merely weak. The Article 29 Working Party treats it as affirmatively unfair under GDPR Art.5(1)(a), because a material change to purpose, to controller identity, or to how rights are exercised has to be actively pushed to the people it affects, not left on a page for them to discover. It is in the rule set on this page as an error, cited to WP260 rev.01. That clause is also in nearly every auto-generated privacy policy on the internet.
Including, quite possibly, yours.
Almost nobody in this audience gets fined. Let us drop that, because it is the least honest lever in this category and you have heard it too many times to feel it.
What happens is that somebody asks.
A customer sends a security questionnaire and one of the rows says “list all subprocessors that receive personal data.” A deal you want reaches the stage where their counsel attaches a DPA. A user in Berlin emails and asks what you hold on them, which they are entitled to do, and now you are answering from a document you know was written from memory by a person in a hurry.
That is the moment. Not a regulator. A Tuesday.
And here is what makes it worse than doing nothing at all, stated in the source this system was built on:
A fabricated disclosure is worse than a missing one. It creates liability where silence would not have.
An inaccurate privacy policy is not only a privacy problem. In the US it is a representation to your users and to the FTC, and an inaccurate one is an unfair or deceptive practice in its own right, independent of any privacy law. The document you published to be safe is a separate exposure from the thing it describes.
One real example, from the one real run this system has completed. The product
transmitted its users’ résumé text to three separate US AI vendors.
Two of them are named at src/lib/pipeline/external-detection.ts, lines 57
and 187. The most consequential single sentence that product’s privacy policy could
possibly contain is your résumé is sent to three third-party AI
services, and there was no record anywhere supporting it, because nobody had asked
the code.
That is the sentence you would have to explain. Not to a regulator. To the person who asked.
My name is Tim Moehring. I build software in Olympia, Washington, and I would like to tell you I worked this out in the abstract, from principles, as a design exercise.
I worked it out because I pointed an early version of it at my own site and did not enjoy the result. It was setting an analytics cookie before anything on the page had asked permission. Fonts came off a CDN, which quietly hands a visitor's IP address to somebody else. There was no consent banner anywhere in the codebase, because I had never written one, because I had never had a reason to think about it and nothing had made me.
What got me was not the finding. It was that I had read that page maybe forty times, shipped from it, linked to it in a footer, and never once seen it. The exposure was four lines of JavaScript in a file I wrote.
I will come back to what fixing it cost, and what the commit looks like, in a minute.
For now: to skip the argument and just find out what your own document is missing, the tool is right here and it is free.
Free. Runs entirely in your browser. Nothing is uploaded, nothing is stored, and there is no email field.
Line & Clause does one structural thing differently, and everything else follows from it.
It reads the repository before it asks you anything.
Your schema is a personal-data register. It is already written, it is already accurate, and it is already versioned. Your dependency manifest is a subprocessor list. Your outbound HTTP calls are your transfer map. Your migrations are the history of when each of those things became true. None of that requires anyone to remember anything.
So the scan runs first, and it produces evidence: the data elements, the flows, the vendors, the storage written to browsers, and every file and line each of those came from.
If you want the whole difference in one test, it is this: open whichever generator you
pay for and ask it what is in your sessions table. It cannot answer. It has
never seen your database and it never will.
Then, and only then, it asks you questions. And it asks you about exactly three things:
Purpose. Why this data is held.
Legal basis. Under what lawful ground.
Retention. For how long, or by what criteria.
Those three fields are null in the evidence by design, and the scanner is forbidden from filling them. Not “discouraged.” Forbidden, as a rule the tests enforce. They are legal characterisations, not facts in a repository, and a system that infers a purpose from a column name has invented the most legally consequential part of the document while looking like it did research.
That constraint is the thing worth paying for. The other eleven stages are careful bookkeeping around it.
There is a second one worth knowing about, because it is what keeps the output honest
when nobody is checking. The gate that validates the finished documents runs two
channels that never merge. ERROR and WARN come from the
law, and every single one carries a citation to primary source. STD-ERR and
STD-WARN come from this system's own quality bar. A house preference can
never wear the law's authority, and a legal requirement can never be softened into a
style note. Merging them is the failure mode the whole design exists to prevent.
And the gate is a program. It exits non-zero. An agent saying “this looks thorough” is not a pass.
Back to my own site.
It is a small browser games arcade called Play Moehr Games. Nothing about it is sensitive, which is exactly why it is a good example: it is the kind of site where you assume none of this applies to you. The commit below is public and you can go read it.
It was loading PostHog on every page, unconditionally, the moment the page opened. There was no consent gate. There was no banner. Under ePrivacy Art.5(3) and the UK's PECR reg.6, storage on a user's device for analytics needs consent before it is set, and the order is the thing, and I had the order backwards on every page view for months.
Here is what fixing it actually took.
commit 8486aff 2026-08-13 08:35 -0700 Add /terms/ and /privacy/, consent-gated analytics, and a retention purge (#13) 8 files changed, 611 insertions(+), 30 deletions(-)
Analytics now cannot start at all until localStorage.mg_consent === 'granted'.
Declining loads nothing and sets nothing. Global Privacy Control and Do Not Track count as
a decline, and the banner never appears for anyone who has already expressed one. And a
purge job enforces the retention windows the privacy page states out loud, so the document
and the database agree: rate-limit rows holding raw IPs at 30 days, feedback at 24 months,
expired tokens on expiry.
That last one matters more than it looks. Most published retention language is aspirational. Nobody wrote the job. The policy says 30 days and the rows sit there for three years, and that gap is a false statement in a legal document that nobody in the company knows is false.
I do not offer that story as a credential. The reason it is here is that it is the honest origin: the first thing this project found was mine, and the fix is a public commit you can go read.
Not “trained on legal texts.” Not “AI-powered compliance intelligence.” A rule set, in version control, that you can open and read.
A regime here means one law's disclosure duty, like GDPR Article 13. An element is one thing that law requires a document to say.
Nine regimes. Fifty-five required elements. Every single one carries a citation
to primary law and a date on which that citation was last verified. The rule set
is a single JSON file, version 1.0.0-2026-08-13, and you would be sent it.
| Regime | Applies to | Elements |
|---|---|---|
| EU GDPR Art.13 (data collected from the subject) | privacy policy | 16 |
| EU GDPR Art.14 (data not obtained from the subject) | privacy policy | 2 |
| UK GDPR / DPA 2018 / Data (Use and Access) Act 2025 | privacy policy | 2 |
| California CCPA/CPRA | privacy policy | 12 |
| Colorado Privacy Act | privacy policy | 2 |
| EU ePrivacy Art.5(3) | cookie table + policy | 9 |
| UK PECR, as rewritten in force 5 Feb 2026 | cookie table + policy | 4 |
| EU Digital Services Act Art.14 | terms of service | 5 |
| EU Platform-to-Business Reg. Art.3 | terms of service | 3 |
Three of those fifty-five are prohibitions rather than requirements, which is a
distinction most tools in this category cannot express at all.
no-passive-update-clause is the prohibition you met earlier.
ep-no-implied-consent catches “by continuing to browse you agree,”
which the EDPB dealt with at paragraph 86 of Guidelines 05/2020: scrolling or swiping
“will not under any circumstances” satisfy the requirement of a clear
affirmative action. ep-no-cookie-wall catches conditioning access on consent,
and sits on the warning channel rather than the error channel, because the law there is
less settled and pretending otherwise would put a judgement call where a citation
belongs.
A test suite exists to prove none of that has quietly rotted:
$ node tools/test.mjs ── gate self-test ── 32/32 passed The engine behaves and every encoded rule is cited, well-formed and reachable.
Run on 2026-09-05. Exit code 0. Every rule reachable, every rule cited, no orphans.
The law moves faster than any model's memory, which is why none of this lives in a prompt. Three things a language model will currently tell you with total confidence and get wrong. The CPPA regulations effective 1 January 2026 rewrote §7011, §7012 and §7025. UK PECR reg.6 was amended in force 5 February 2026 by section 112 of and Schedule 12 to the Data (Use and Access) Act 2025, which inserted a new Schedule A1 and moved qualifying analytics storage to an opt-out footing. “Qualifying” is doing a lot of work in that sentence: the exception falls away if the data goes to a third party for that third party's own purposes, which describes most hosted analytics. And the FTC's click-to-cancel rule was vacated on 8 July 2025 and does not exist.
I am telling you where those three came from, because a page arguing that unsourced confident sentences are the defect does not get to make unsourced confident sentences. They are in the rule set with citations and verification dates, and the PECR one was re-checked against the amending Act while this page was being written.
Twelve stages. Four of them are programs rather than judgement calls, and it is worth knowing which four, because that is where the reliability lives.
01-scan is a program. It walks the repository and produces
evidence.json: data elements with their categories, flows, vendors, client
storage, and a file and line for each. It records the commit SHA it ran against, and
characterises nothing.
Its most valuable output is what it admits it could not see. Blind spots are treated as output, not as failure. Free-text columns that might hold anything. Cookies set from inside library code, which no static scan can reach. Offline processing, a support inbox, a spreadsheet on somebody's laptop. Whether a given disclosure counts as a “sale” under California law, which is a legal characterisation and not a fact about code.
On the one production codebase this has run against end to end, the blind-spot list came back with 22 entries, 15 of them blocking, against 54 flows. A scanner that reports only what it found produces a confident and incomplete policy, and the confidence is the defect.
| Stage | What it is | Who does it |
|---|---|---|
01-scan | Evidence from the repo | program |
02-intake | Merge evidence and what you know | model |
03-interview | Purpose, basis, retention. Checkpoint | you |
04-applicability | Which regimes, which role | model |
05-mapping | One disclosure matrix | model |
06/07/08 | Policy, terms, consent artifacts | model |
09-gate | Two channels, exit code | program |
10-review | Four adversarial readers. Checkpoint | model + you |
11/12 | Rendered docs, lawyer-questions.md | model |
diff.mjs | Drift check, in your CI, forever | program |
02-intake and 03-interview merge the evidence
with what you know, mark every gap, and then ask you the questions the code cannot settle.
This is the real gate, and it ends at a checkpoint: a fact ledger you confirm before
anything gets drafted. If you do not know the answer to something, that stays a gap. It
does not become a plausible sentence.
04-applicability and 05-mapping work out which
regimes plausibly apply, which role you hold, which thresholds you cross, and then project
every flow into every applicable regime to build one disclosure matrix. One inventory,
projected many times. Not a document per region stapled together, because policies
assembled from regional appendices contradict each other, and the contradiction is the
part a regulator reads.
06, 07 and 08 render the Privacy
Policy, the Terms of Service, and the consent artifacts from that single matrix, in
parallel. Same source, so they cannot disagree.
09-gate is also a program. Two channels, never merged, and
an exit code that means something.
10-review puts the rendered documents in front of four
adversarial readers who never see the drafting context: a regulator, a plaintiff's lawyer,
an ordinary user, and a red team. The evaluator is never the generator. A drafter reviewing
its own work checks whether it said what it meant, not whether what it meant was right.
11-publish and 12-handoff produce the rendered
documents, a version manifest, and the document that matters most:
lawyer-questions.md. Every decision the evidence could not settle, and the
evidence sitting under each one.
And then the part that keeps it true.
tools/diff.mjs is the fourth program, and the one you will
use most. It re-scans your repository, compares it against the evidence your published
documents were built from, and classifies every delta by what it obliges you to
do, not merely that something changed. A new data category, a new recipient, or a
new purpose generally requires notice before the processing starts. Anything that
says “your policy may be out of date” has handed the hard part back to you.
It exits non-zero. Put it in CI and it blocks a deploy that would ship undisclosed processing.
You have been reading my claims about a tool for four thousand words. Here is the tool.
The law channel from that gate is on this page. Not a demo of it. Not a video. The rules compiled out of the same JSON the command line reads, running in your browser.
Paste your current published privacy policy into the box at the top of this page. Pick the markets you serve. It will tell you which required disclosures it cannot find, each one with its citation, and it will flag the three prohibited clauses if they are in there.
Two honest limits, stated before you use it rather than after.
It can prove an element is absent. It cannot prove one is adequate. The matching is deliberately generous, so mentioning a topic counts as present. A policy that says the word “retention” once and discloses no period will pass that check. Adequacy is a human's job and then a lawyer's, and pretending a regex can do it would produce confident passes on documents that disclose nothing, which is worse than no check at all.
A clean result is not a clean bill of health. It means the elements this rule set looks for were found. It is not a statement that you are compliant, and this system will not make one, ever, in any phrasing.
Here is what it says about my own privacy policy, which I wrote by hand, in first person, after building all of this, and which I would have told you was thorough.
## eu-gdpr-art13 (16 elements): 3 error, 2 warn ## eu-gdpr-art14 (2 elements): 2 error ## us-ca-ccpa (12 elements): 4 error ## eu-eprivacy (9 elements): 1 error ## uk-gdpr, uk-pecr, us-co-cpa: clean TOTAL: 10 errors, 2 warnings
Ten. On the good one.
Now the part worth showing you rather than hiding. I went through those ten errors one at a time against the document. Seven of the ten are wrong, in two different ways, and three are real. That is one document, so it is a count and not a false-positive rate, and anyone who quotes it as a rate is quoting it wrong.
Five are false absences caused by phrasing. The recipients
rule looks for recipient, we share, we disclose,
third party, service provider or sub-processor. My
policy names its one recipient in a table under a heading about who else touches your
data. It says I, not we, because one person runs the site. The rule was
written expecting a company. rights wants “right to access” and
got “those rights are formally: access, rectification, erasure.”
withdraw-consent wants “withdraw consent” and got
“withdrawal of consent.” non-discrimination wants the word
“discriminate” and got “asking will never get you a worse experience on
the site.” ep-withdrawal-route wants “cookie settings” and
got “change your mind any time with the Cookie choices link in the footer of every
page.”
Every one of those is the disclosure being present in better English than the rule expected.
Two came from a regime that should never have fired at all. GDPR Article 14 governs data you did not get from the person it is about. My site collects everything directly. Both Article 14 errors are artifacts of a rule set that has no condition on that regime, which is a bug in my rule set, and it is now written down as one.
Three are real, and all three are California. No layered first-layer summary of the kind WP260 paragraph 36 asks for. The literal phrase “categories of personal information,” which 11 CCR §7011 wants and the document never uses. And “business purpose,” a defined term in California law that the document simply does not use.
So the free tool narrows the search from fifty-five elements to ten candidates, and then a human has to read ten things. That is genuinely useful and it is genuinely not the product. A person reading your code beside your document is what separates “the word is missing” from “the disclosure is missing.” The gate does the search. It does not do the work.
$490. Three business days. Refunded in full if it surfaces nothing you did not already know.
This is a draft page. The button does nothing: there is no booking route or payment rail yet. See the open items.
This has been pointed at exactly one production codebase end to end. Here is that run, with the numbers, and then the four things it got wrong.
tools/scan.mjs@1.0.0 against a pre-launch résumé product,
commit 6a08dd7, scanned at 01:46 UTC on 2026-08-16. 136 files walked, 2
skipped, exit code 0.
Fifty-four and fifty-four is not a coincidence, it is a symptom: every flow it built was
a store operation on one element, and it built no flow to any recipient at
all. Which is the first of the four things it got wrong.
Then a human read the evidence against the code. Three of the findings are the argument for this entire approach.
fonts.googleapis.com is imported in the CSS that generates
résumé PDFs, and also in public/templates/sample-*.html. The
first one discloses nothing: headless Chrome fetches it server-side, so the request
comes from a datacenter IP and no user is involved. The second one is loaded in an
iframe on the pre-authentication /get-started marketing page, at
TemplatePreviewModal.tsx:84, which hands the visitor's IP address to Google
with no consent, before anybody has signed up for anything. One string. Two
completely different legal facts. A questionnaire merges them. A grep merges
them. Someone reading the code separated them.
It reported clientStorage: [], meaning it found no first-party storage
writes in source. Meanwhile src/app/(app)/get-started/page.tsx:57 writes
the entire wizard state, including extracted résumé text and job posting
text, to sessionStorage on every re-render. The code is thoughtful about
it: the comment says sessionStorage was chosen over
localStorage specifically because “resume text is personal data and
should not outlive the browser tab.” Good instinct, undisclosed anywhere.
PostHog was configured better than most products this size manage: session recording
disabled, personal data properties masked, profiles for identified users only, events
proxied same-origin. And posthog.init() still ran unconditionally on every
page including pre-authentication marketing pages, with no consent gate and no banner
anywhere in the codebase. The proxy is a content-security and ad-blocker measure. It
does not change the analysis, because proxying a third party's collection through your
own domain makes the cookie first-party in form, not in substance.
All of which that run wrote down against itself.
It built zero flows to any vendor. All 54 flows came out as
store with a null recipient, which means the single most consequential
disclosure in that product, that résumé text is transmitted to three US AI
vendors, had no supporting record at all. Logged as CB-01.
It mis-sited GPTZero and Originality.ai, citing them from a health-check
script rather than from the product path that actually posts to them, and graded both at
the same weight as nextjs.org appearing in a doc comment. Logged as CB-02.
It has no sessionStorage detector, which is why the
paragraph above exists. Logged as CB-04.
It missed Google entirely as a recipient. Google sign-in is configured
unconditionally at src/lib/auth.ts:37-39, but it adds no dependency and makes
its call server-side, and the vendor detection is fingerprint-driven off
package.json and outbound hosts. Logged as CB-06. The recipient count went
from six to nine.
I am telling you the misses because the alternative is a tool that hides them, and a tool that hides its misses is the thing you are already worried about. The scanner has never been measured. There is no precision figure and no recall figure, because nobody has built the labelled fixtures yet, and every accuracy number in the published literature is from mobile-app research and does not transfer. The honest claim is the repository's own claim about itself: it finds what questionnaires miss. Nothing stronger than that is available yet, so nothing stronger will be said.
This is in the system's own configuration as a hard scope limit, not as a disclaimer bolted on at the end. It shapes the pipeline: every sentence traces to an evidence ID because the output has to be checkable by a lawyer.
Producing a document is not the same as advising you about your legal position.
| It does | It does not |
|---|---|
| Report what your code does | Say whether that is lawful |
| State that a regime requires a disclosure, with a citation | Say whether you have satisfied it |
| Identify which regimes plausibly apply, and on what facts | Conclude that a regime does not apply |
| Produce a draft a lawyer can check quickly | Produce a document that replaces a lawyer |
| List the decisions a lawyer has to make | Make those decisions |
| Flag where a clause is commonly unenforceable, with a citation | Advise you whether to include it |
A note on the vocabulary, because it is not optional here. A controller is whoever decides why and how personal data gets used, which for your product is you. A data subject is the person the data is about. Adequacy is whether a country has been ruled safe enough to send data to without extra paperwork. An intermediary service is a platform that hosts other people's content, which triggers a separate set of rules.
Four things it will never produce, in a document or in conversation:
“You are compliant,” in any phrasing. Compliance is a conclusion about an organisation's whole conduct over time. This has seen a codebase for an afternoon.
A risk assessment of your exposure. “You are unlikely to be fined” is legal advice and is also not knowable.
An assurance that a clause is enforceable. Arbitration clauses, liability caps and class-action waivers vary by jurisdiction, by consumer status, and by the drafting around them. The system reports how that varies, with citations. It does not predict a court.
A determination that a regime does not apply. That is the more dangerous conclusion, because it removes obligations rather than adding them. A run can record “no evidence of EU targeting found.” It can never record “GDPR does not apply.”
That asymmetry is deliberate. The system errs toward more disclosure and more applicable regimes, because over-disclosure costs you some prose and under-disclosure costs you a violation.
And where it is weak, it says so. Anything outside the repository is invisible to it: offline processing, a support inbox, a CRM, a spreadsheet, a founder's mailing list. Whether a DPA is signed. What a vendor's terms actually say. Sector regimes like HIPAA, GLBA and FERPA get flagged when they plausibly apply, and then it stops, because a general-purpose generator producing a HIPAA notice is a genuinely bad outcome.
You should do this if you can read your own schema and you already suspect what is in
it. If your published policy came out of a form and you have never once reread it. If
someone has asked you for a subprocessor list and you assembled it by opening
package.json and squinting. If you are pre-launch and would rather publish
something true the first time than fix it under pressure later. If you build software for
clients and hand off a legal question you are not qualified to answer, along with a link
to a generator and a shrug.
You should not do this if you want somebody to tell you that you are fine. Nobody here will say that.
You should not do this if you need an answer today. The Evidence Pass takes three business days, and the Full Draft takes two weeks, and most of the second week is you answering questions.
You should not do this if your product is mostly not code. If the real processing happens in a CRM, on phone calls, and in a shared spreadsheet, then the repository is the small half and this will find the small half.
You should not do this if you are in a sector regime. If HIPAA or GLBA or FERPA applies to you, you need a specialist, and this says so and stops.
And you should know this before you decide anything else.
Nobody has bought this yet. Not one person. The deterministic half runs every day and passes 32 of 32 tests, and one production codebase has been through the scan end to end. The back half of the pipeline, stages 4 through 12, has never executed for a paying customer, because there has never been one.
So: you would be first. What that actually buys you is a level of attention that stops being available at customer six. I will read your codebase myself rather than skim a report about it, you get the operator instead of a queue, and when something is rough you will be asked what was wrong with it rather than told it is working as intended. That is what the founding price is paying for, and it is why there are five.
If you run an agency, the thing to know is that the deliverable is an evidence file and a set of drafts, not a client-ready branded PDF. It raises the quality of a handoff and it does not replace your client's lawyer, and if you tell them it does, that is on you, not on me.
That is the correct thing to worry about, and it is what the architecture is arranged against. The scan is a program with no model in it. The gate is a program with no model in it. The three fields most likely to be confabulated, purpose and legal basis and retention, are structurally null and cannot be filled by anything except a human answering on the record. And the reviewers at stage 10 never see the drafting context, so the thing checking the work is not the thing that did the work.
It can still get things wrong. Four documented ways it did are two sections up.
It is worth the difference between your lawyer doing archaeology and your lawyer doing judgement. Right now a competent privacy lawyer handed your product has to reconstruct what it does from your description of it, which is the same unreliable witness the generator used, except now you are paying hourly for the interview. Hand them an accurate description with a citation behind every claim, plus a list of the specific decisions only they can make, and review becomes verification instead of discovery.
That is the entire value proposition, and it is deliberately smaller than the one the category advertises.
You do, and those products are competently built. As of September 2026, Termly publishes at fourteen to twenty dollars a month per site and covers thirty privacy laws. iubenda runs from $3.99 to $119.99 a month depending on tier. There is even a company called PolicyForge, at $15 a month, which we will come back to. Those are their published prices on the day this was written, and they are fair prices for what those products do.
Here is the test, and it costs you nothing. Take whichever one you pay for and ask it
what your sessions table contains. It cannot answer, because it has never
seen your database and never will. Its input is your memory. Everything downstream of that
input inherits its accuracy.
You are not comparing two prices for the same thing. You are comparing two different sources of truth, and one of them is a person filling in a form at eleven at night.
If your product genuinely is a brochure site with a contact form, the fifteen dollars a month is the right answer and you should keep paying it. This is for the case where the code is the product.
Because they carry dates. Every rule in the configuration has a citation to primary source and a verification date, and a separate process re-verifies them against primary sources and reports which already-published documents a change affects. It never touches a completed run, because a run is the permanent record of what was published, from which commit, on which evidence, under the law as it stood.
There is also a house rule that matters more than it sounds: never edit a rule mid-run to make a document pass. Record the suspicion, finish the run, then change the rules deliberately, on their own. Changing the standard to fit the output converts a finding into a silence.
Yes. Covered above, and priced for.
Two ways in. Almost everyone should take the first one.
$490
Three business days.
evidence.jsontools/diff.mjs wired into your CI, exiting non-zero on a material changeNo documents. This is the evidence, and it is the part that is fully built and deterministically tested today.
$2,400
Two weeks. Founding price, first five engagements. $3,900 after that.
Everything in the Evidence Pass, plus:
lawyer-questions.md: every decision the evidence could not settle,
with the evidence attached to eachWhat the three days are actually for, since the scan itself takes seconds: I read the
evidence beside your code. Every finding in the one real run that is worth anything came
from that step and not from the scanner. You get a git repository with
evidence.json, the blind-spot inventory, a written walkthrough in markdown,
and a pull request against your CI config. Plus a call, if a call helps.
Five, because one person runs these and my honest guess is that five is what one person can run properly while still reading every line. It is a guess: I have run zero. If it turns out to be three, I will say so and stop at three. When they are gone the price is $3,900, and the reason it goes up is that by then there will be finished engagements behind it, which is worth more to a buyer than a discount.
No inflated value stack here. You can do this arithmetic yourself and you would resent watching me do it for you.
| Generator subscription | A lawyer, from scratch | The Evidence Pass | |
|---|---|---|---|
| Input | Your memory, in a form | Your description of your system | Your repository, at a commit |
| Sees your schema | No | Only what you tell them | Yes |
| Sees your outbound calls | No | No | Yes |
| Tells you what it could not see | No | Yes, if asked | Yes, unprompted, in writing |
| Stays true when you merge | No | No | Yes, in CI |
| Makes a legal judgement | Implies one | Yes, and this is the point | No, and says so |
| Cost | $4 to $120 a month | Quoted per matter, and I am not going to invent a figure | $490 once |
The row I will not fill in is the lawyer's. Every number on that line I could find was somebody's marketing, and putting an unsourced price for a competing profession on a page about sourcing would be the single dumbest thing here. Ask two firms. The answer is regional.
The row to actually sit with is the one above it. This does not replace the lawyer. It saves the six hours a lawyer spends working out what your software does, and it hands them a better starting point than a blank page or a template.
If the Evidence Pass surfaces nothing about your own system that you did not already know, it is refunded in full. You keep the evidence file.
That is a falsifiable promise and it is meant to be. If this approach is real, that refund almost never fires, because nobody has a complete mental model of their own data flows and the scan produces artifacts nobody has looked at. If the approach is not real, that refund fires constantly and the price collapses, which is the correct outcome and the reason the guarantee is worth making.
You are the judge of it. There is no panel and no dispute process. You say it found
nothing new, within 14 days of delivery, and it is refunded in full. You keep
evidence.json and the blind-spot list either way.
Yes, that is exploitable. Someone can take the file and say they knew all of it. A dispute process would close that hole and would also destroy the only thing the guarantee is for, so the hole stays open on purpose.
Draft page: the guarantee has not been approved and no refund mechanism exists. See the open items.
Five founding engagements. Reply and tell me which repository, and whether it is public or I need access.
Or run the free gate first. Genuinely, most people should: it costs nothing, it runs in this tab, and it is the only part of this that does not require you to trust me.
Draft page. The buttons above do not work. No email address, booking link, contract, payment rail or refund process exists yet. See the open items.
For the Evidence Pass, yes: read access to the repository, at a commit we name. The scan runs locally and the codebase is never copied anywhere, never sent to a third party, and never committed to any repository of mine. It is referenced by path and commit SHA. A completed run is a full map of your personal-data handling, which is exactly the document an attacker would want, so runs are local and gitignored by default.
If read access is not possible, there is a version where you run the scanner yourself
and send only evidence.json. It is a worse engagement, because half the
findings come from a human reading the code beside the evidence, but it is
available.
Detection is strongest where the structure is declarative: SQL and ORM schema definitions, dependency manifests, outbound host references, framework configuration. It has been run against a TypeScript and Next.js and Drizzle and Postgres codebase. It has not been measured against Django, Rails or Laravel, and you get told that before you buy rather than after.
An hour or two, spread out. It only asks about purpose, legal basis and retention, per flow, and about the blind spots. It does not ask you a single question about your company that a form could have asked.
Then it stays a gap and goes into lawyer-questions.md with the evidence
attached. It does not become a plausible sentence. That is the entire point of the
design, and the single place the system is deliberately unhelpful.
I have no idea, and anyone who tells you they do is selling something worse than this. What it produces is a cited draft plus an explicit list of what a lawyer has to decide. Publishing it without that review is not what it is for.
It is the opposite. Ask your lawyer how they currently work out what your software does. The answer is that they ask you, and you tell them, from memory, in a meeting. This replaces that meeting with an artifact.
tools/diff.mjs re-scans and compares against the evidence your documents
were built from, and classifies each change by what it obliges you to do. It exits
non-zero, so it can block the deploy. That is included in both tiers and it is the part
that has the longest tail of value, because policies do not usually start false, they
become false.
The repository is called policy-forge, which turns out to be somebody
else's company: policyforge.co sells an AI privacy policy generator at fifteen dollars a
month. Unrelated, and a genuinely competent product in the category this page is arguing
with. The name here is being changed, which is one of several things on this page that
are not settled yet.
The email arrives either way. Somebody asks. A security questionnaire, a DPA, a user in Berlin exercising a right they have.
In one version you open the live document and read it looking for an answer, and you already know it will not be there, because you know how that document was made. So you go and find out the real answer from the code, under time pressure, while somebody waits. And then you have a second problem, which is the gap between what you are about to tell them and what you published.
In the other version you answer from the document, because the document was built from the thing it describes. Every claim in it has a file and a line behind it. The parts nobody could settle are written down as open questions rather than papered over. It is not perfect and it does not claim to be, but it is checkable, and checkable is the only property that survives somebody actually checking.
There is no urgency here that I did not invent, and I am not going to invent one. The document is wrong today and it will still be wrong next month, slightly more so. The only thing that changes is whether the next person who asks catches you.
Three business days. Refunded if it finds nothing you did not already know.
Or run the free gate on your current policy. It costs nothing and it will tell you something.
Draft page. The button does nothing yet. See the open items.
P.S. The single most valuable output is the admission of what it could not see. Free-text columns that might hold anything, cookies set from inside library code, the spreadsheet on somebody's laptop. Every other tool in this category reports only what it found, and a scanner that reports only what it found produces a confident and incomplete policy. The confidence is the defect.
P.P.S. Five founding engagements at $2,400. Not a deadline, a capacity limit: one person runs these. When they are gone the price is $3,900, and it goes up because by then there will be finished work behind it.
P.P.P.S. If the Evidence Pass surfaces nothing you did not already know, it is refunded in full and you keep the evidence file. You are the only judge of that.