Method · Traceability · Automated checks

How we decide what this site is allowed to say

A software vendor’s website asserts things its reader cannot check. We took the problem from the other end: rather than promising to be rigorous, we made publishing an unsourced sentence mechanically impossible. Here is how, and where what that buys you stops.

For anyone building a purchase case, comparing vendors, and wanting to understand how published information is checked.

Request a demonstration

Why this page exists

Every page of this site used to carry a “Sources for this page” table at the foot of the document. Those tables were removed: twelve repetitions of the same mechanism took up room and explained nothing, since nobody reads the same column twelve times.

What was removed is the display, not the discipline. The references did not disappear, they moved: they live in the repository that builds this site, in a single file, and this page replaces them by explaining the system once.

The four questions every sentence is asked

Before it reaches the site, a factual sentence has to clear four filters. They ensure that published information is substantiated.

1

Where does it come from?

A statement with no code reference and no dated public source is not a statement, it is a guess. It is deleted, never softened: a vague sentence is a false one with the means of contradicting it removed.

2

Does the code do it, or is it planned?

A feature that exists in a design document, in a comment, or behind a switch that is off is not a shipped feature. We verify against what runs, and we announce nothing in the future tense.

3

Is it a capability or an outcome?

“Tracks consumption per site” can be proven in code. “Cuts your bill by 20%” requires a documented measurement and its context. A capability and an outcome are not the same thing.

The claim ledger

Upstream of the site, a capability register describes what the product actually does, line by line, each pointing at a file and a line of code at a pinned commit. That register is the only sanctioned raw material for a product claim.

Downstream, every value the site displays is declared in a claim ledger, a single file in the repository. Each entry carries the sentence, its evidence, the reserve that goes with it where there is one, and a status that decides what may be done with it.

Proven by code
The capability is demonstrated by code that runs, at a specific commit. This is the status of the great majority of the product claims on this site.
Dated public source
A statute or an official page, cited with its article or page, the version in force, and the date we read it. The date is part of the source: regulation changes.
Verifiable on this site
A fact about this website itself — that it sets no cookies, for instance. Its evidence is the site’s own code, and the automated check re-verifies it on every build.
Supplied by the company
Something only the company can source: a price, a legal identity, a hosting location. It does not go out on an indexable build until management has explicitly confirmed it, and the ledger keeps side by side where the value came from and who signed off on it.
Barred from publication
A sentence we refuse to write, kept together with the reason for the refusal. It is kept precisely so that it is not reintroduced in good faith six months later by someone who never knew why.

The check that fails the build

A discipline nobody checks is a good intention. So a program in the repository reads the built pages — the bytes that would actually be served, not the content files — and refuses to let through:

  • a sentence belonging to a barred claim, matched by pattern rather than by exact quotation, so that a rewording is caught as readily as the original;
  • an amount the price table cannot produce, including an entry price no tier yields;
  • a missing mandatory legal mention, which makes going live mechanically impossible while the publisher’s identity is incomplete;
  • a resource loaded from another domain or a cookie set, since the privacy policy states there are none;
  • a document structure defect: missing title, more than one top-level heading, a skipped level, a missing canonical link, indexing that contradicts itself from one file to another;
  • a parity break between the questions shown and the structured data, or between a French page and its English translation.

Two severity levels, and the difference matters. A barred claim fails every build, including a staging one. A claim awaiting confirmation renders in staging and fails the build meant to be indexed: in other words, putting the site live forces the open questions shut instead of leaving them behind.

What this method does not guarantee

The arrangement above has edges, and hiding them would make this page the counter-example to what it describes.

  • You cannot check it yourself. The repository behind this site and the capability register are not public. If a sentence on this site matters enough for you to want its reference, ask us: we will give you the file and the line. That is the only route, and we would rather say so than let you assume an open repository.
  • An automated check matches patterns, not meanings. It refuses a sentence it recognises; it does not detect an exaggeration it has never seen. What catches that is review — and the fact that a new claim has to enter the ledger first, which forces the evidence to be written before the sentence is.
  • A dated source ages. The regulatory citations on this site carry the date we consulted them because a text gets amended. An old consultation date does not invalidate a sentence; it tells you when to re-check it — which is also why it is displayed.
  • This method makes nothing true. It makes the unsourced hard to publish. That is more modest than the guarantee a page like this usually announces, and it is what we can hold to.

Frequently asked questions about our method

Because the product does not measure savings achieved. It compares one year with the previous one and with a target you set; it cannot attribute a fall in consumption to its own use. A reduction figure is a documented result, with a method and a period, not a property of the software.
The build fails. Every factual value has to exist in the repository’s claim ledger; a page referencing a missing or barred key fails the build, and a program then re-reads the built pages looking for refused sentences, amounts the price table cannot produce, and structure defects. A wholly novel sentence can pass that check: which is why a new claim must enter the ledger with its evidence first, forcing the evidence to be established before the sentence is written.
Not online: the repository behind this site and the capability register are not public. What we can do, and gladly will, is give you the reference behind a specific sentence — the file, the line, the commit, or the official text with the date we consulted it. Ask through the contact form, quoting the sentence you care about.
Because texts change, sometimes where you would not expect. The declaration deadline of the Éco Énergie Tertiaire scheme, for instance, is not in the decree but in a ministerial order, which has already been rewritten: two signatures are enough to move it. A citation with no date suggests a permanent state. With its date and its version in force, it tells you what we read, when, and from when it needs re-reading.
No, and we would rather say so. It guarantees that an unsourced statement is hard to publish and that a refused one cannot come back by accident. It does not catch a novel exaggeration, it does not replace review, and it does not turn a dated source into a permanent truth. It is a documented reduction of risk, not a promise of accuracy.

Ask us for the reference behind any sentence

Take a sentence on this site that would count in your decision and ask us where it comes from. We will give you the file and the line, or the official text with the date we consulted it. If we cannot, the sentence comes off the site.

Request a demonstration