Editorial standards
How this site checks its own claims
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
Marketing pages age badly because nothing forces them to stay true. This site is built with the opposite arrangement: a set of build gates reads the published text, compares it against the thing it describes, and fails the build when the two disagree. This page names them, because a standard nobody can inspect is not a standard.
The rule every number follows
A figure on this site is one of three things, and the page says which: a measurement we took, with the input named; a value from a published standard, with the standard named; or a stated assumption. Nothing is a round number chosen because it reads well.
Where a claim cannot be supported that way, it is not made. The scan-duration page is the clearest example - it publishes the two measurement points that fix its model and then says explicitly that they say nothing about the shape of the curve between them.
The gates that enforce it
Each of these runs on every build. A failure stops the deploy; none of them can be waved through.
| Gate | What it enforces | Scale |
|---|---|---|
| verify-scan-claims | A duration claim may only appear alongside a pointer to the measurement behind it | 45 checks over 368 source and 150 built files |
| verify-baseline-ladder | The published rule ladder must equal the engine's own status enum | 193 checks, 35 documented rows, 71 parity pairs |
| verify-scan-model | The published cost model must reproduce its own anchor measurements, and catch planted errors | 73 checks including mutation tests |
| verify-cli-surface | Every command line printed in the docs must exist in the CLI | 49 checks across 92 commands |
| verify-pricing-consistency | One plan list; six surfaces must name and price it identically | every tier, both locales |
| verify-hreflang | Each page's language annotations must match the sitemap | 143 pages |
| verify-prerender-depth | No page may ship as an empty shell to a crawler | 143 pages, per page class |
| verify-entity | One publisher entity, one identifier, no dangling references | 143 pages |
| verify-meta-lengths | Titles and descriptions must fit what a search engine renders | 143 routes, both locales |
When something is wrong
- Report it to contact@flowencehq.com. A claim on this site that you can disprove is the most useful mail we get.
- Factual corrections are made at the source, so the change propagates to every surface that repeats the fact - page text, structured data, llms.txt and the documentation corpus.
- A correction that changes the meaning of a published figure is noted in the development changelog with the date, rather than edited away silently.
- Where the correction reveals a gap a gate should have caught, the gate is extended. That is how most of the list above came to exist.
What this does not cover
These gates check consistency and evidence, not judgement. They cannot tell you that a rule is the right rule, only that the site describes the rule the engine actually applies. Detection quality is a separate question with its own measurement, described on the methodology page.
Frequently asked questions
How does Korthex handle corrections?
Corrections are made at the source so every surface that repeats the fact changes together, and a correction that changes the meaning of a published figure is recorded in the changelog with its date rather than edited away.
Are the claims on the Korthex site verified?
By build gates that run on every deploy. A duration claim without a pointer to its measurement, a documented rule that no longer matches the engine, or a CLI command that does not exist all fail the build rather than shipping.