Business context & the rule book

Vera can generate tests from your pages. Reading a page tells it what a user can do; it cannot tell it what the app is supposed to do. A DOM-grounded generator can only ever assert that something is visible — and "the total is visible" passes whether the total is £90 or £900.

The business context and the rule book are how you tell it the difference.

The two things you write down

Facts describe what the product is: its purpose, the capabilities it provides, the personas who use it, the objects it manages. They give generation the vocabulary of your domain, so a planned test is called "Reject an order below the minimum" instead of "Test form 3".

Rules describe what the product must do: "a loyalty order receives a 20% discount", "only an administrator may void a balance". A rule is the thing a test can be wrong about.

Nothing is in force until you approve it

Every fact and every rule lands proposed. Nothing that is merely proposed reaches generation — a single function returns approved context, and it is the only place the gate exists.

This matters more than it sounds. A proposal is a suggestion; an approval is a statement your team is making about its own product, and every test written afterwards inherits it. If a rule says 20% and your product does 10%, the tests generated from that rule will fail — which is the point.

Where a rule comes from decides how much to trust it

A rule's source is not decoration:

The bottom two are read out of the thing you are testing, so they agree with it by construction. If your code shipped a 10% discount where the requirement said 20%, an inferred rule inherits that bug, and every test generated from it confirms the bug — sensitively, forever.

Only the middle four come from something written independently of the code, which is why only they can contradict a running app. That is their entire value.

Importing rules you already have

Vera reads rules out of artifacts you have already written, deterministically:

• API contracts — an OpenAPI document states its constraints formally.
• Tracker tickets — Gherkin blocks, checklist items, and bullets under an "Acceptance criteria" heading.
• Requirements documents — numbered clauses, shall/must/should sentences, Given/When/Then blocks, criteria lists, and requirements tables. Upload a .docx or .pdf, or paste the text.

None of these use a model. A deterministic reader cannot invent a requirement your document does not contain, and its evidence is your own sentence rather than a paraphrase — so reviewing a proposed rule is checking "is this still true?", not "is this what the document said?".

Free prose yields nothing, on purpose. A document written as flowing paragraphs with no clause numbering, no modal verbs and no lists produces no rules, and the import says so and names the forms it does read. Extracting requirements from prose is a genuinely different feature: it needs a model, so it needs you to review a guess rather than a quote, and hiding it inside this one would hand you an invention while you believed you were approving a citation.

Every import also reports what it did not read — how many lines were prose, how many bullets sat outside a criteria heading, which sections produced nothing. An import that silently covers 40% of a document and shows a green count is worse than one that refuses, because the missing 60% now looks handled.

When two rules disagree

Vera detects contradictions between approved rules — the "20% requirement, 10% implementation" case — and raises them as a review item, never a silent merge.

A contradiction is not a rule to accept or reject. It is a question about which of two rules your product actually follows, so the resolutions are: keep A, keep B, both are wrong, or this is not actually a conflict. Recording a decision does not retire the losing rule; it records what you decided.

Detection is deliberately conservative. A detector that cries wolf gets switched off, and then the real contradiction goes unreported too.

Risk

A rule or a journey can carry a risk band, derived from three things you assess: blast radius, reach, and whether the damage is irreversible. The band is computed from those, not typed directly — so two people assessing the same thing the same way get the same band, and the reasoning stays visible.

Unassessed is not low risk. Something nobody has looked at reports as unassessed, never as "P3". A default band would be a claim nobody made.

What history you get

The approved profile is a set, and it changes whenever a fact is approved, rejected or revised. Vera records every one of those transitions, so you can compare the profile between any two moments and see what was added, what was removed, and what was reworded — plus which AI-generated tests predate the change and may be worth re-reading.