Verification

Verification checks documentation claims against your connected code. It helps identify when a released page no longer matches the product and can propose a correction for your team to review.

A verification finding does not automatically edit or take down the released doc.

What gets checked

When you release a doc, Teaflask requests a set of executable checks for claims it can test against your repositories. This set is called a verification suite.

Checks quote the claims they cover and look for supporting evidence in your first-party source: for example, a configuration value, a named function, or the arguments passed to another function. A suite becomes active only after its initial verification run succeeds.

Not every page is checkable this way. A policy or conceptual guide may contain no claims that the connected code can establish. Verification also needs at least one selected repository with code to inspect.

A Verified result records a successful check of the claims covered by the suite. It is not a guarantee that every statement on the page has been tested.

When checks run

Releasing a new revision requests verification for that revision. Content becomes current independently of whether verification succeeds.

Once a suite is active, pushes to the relevant repositories' production branches can trigger further checks. Configure those branches under Settings > Integrations > GitHub. See GitHub.

Nearby pushes are grouped rather than starting a separate check for every delivery. A check reads the production branch when it runs, so a queued check can include commits pushed after it was first requested. If another relevant push arrives during a run, further work can follow it.

For an on-demand check, use Re-verify on a doc with an active suite. This runs the existing checks; it does not create a suite for a doc that has none.

Creating or repairing verification checks and drafting corrections use agent work. If that work is waiting for funds, check Billing.

Read the status

Status	Meaning
Verified	The doc has a successful verification result. The timestamp identifies its last successful check.
Checking…	Verification checks are being created or a run is in progress.
Needs review	A check found a contradiction, or the initial checks could not establish a passing result. Review the evidence before deciding what to change.
Not verifiable	There are no checkable claims or no suitable connected code to check against.

Some conditions show no verification label, including when verification has not been requested. An infrastructure error is not treated as proof that the doc is wrong; the last successful verification information can remain visible.

When a correction is proposed, the doc's banner summarizes the finding and, when available, quotes the affected claims. Read it alongside the proposed changes rather than relying on the label alone.

Review a proposed correction

When verification finds a contradiction, Teaflask can investigate the failing evidence and propose an updated draft. The released content stays in use while that happens.

Choose See what changed to compare the proposal with the released doc:

• Approve releases the proposed revision and requests verification for it.
• Dismiss discards the proposal and leaves the released content unchanged.

Approving requires an owner. Approval releases that specific proposal; if you want to change its wording yourself, edit the doc and release your edited draft instead.

A failed check does not always mean the doc needs rewriting. The investigation may find that the verification suite is stale or too brittle. In that case, Teaflask can replace the checks without changing the doc.

A correction is a proposal, not a guaranteed repair. Review the changes and their evidence before approving. The Needs you filter helps find docs awaiting that decision.

If a page cannot be verified

Check that the relevant repositories are connected, contain code, and use the correct production branches. If there is no active suite to re-run, verification is requested on the next release. Contact Support if you need help retrying the current revision.

A page that describes business policy or other material outside the code can remain useful without a verification suite. It can still be released and read normally.