How to read our claims

What we think, what we have built and what we intend are three different things.

Organisations describing their own work tend to blur three kinds of statement: what they believe, what they have done and what they plan to do. Read quickly, all three sound like accomplishments.

We try to keep them apart, because a partner deciding whether to work with us should be able to tell which is which. This page explains how.

Three kinds of statement

Position. How we think about a problem. The topic pages on this site, Sovereignty, Resilience, Early warning, Verification, Capability transfer and AI-readiness, are positions. They set out the distinctions we find useful, the mistakes we see repeated and the commitments we make about our own claims. A position can be argued with. It is not a claim that something has been built or proven.

Built. Something that exists and can be inspected. When we say we have built something, it is in operation and there is a way to check it. Machine Page Format (MPF) is an example: the specification is published, the reference implementation exists, and this site is published with it. Anyone can fetch the output and compare it with the specification.

Intent. Something we plan or have designed but not yet built or proven. We describe it as intent, not as achievement. Design is a real stage of work with real value. It is not the same thing as a working system, and we do not write about it as if it were.

When a page mixes these, it says so. When it does not say, the default is that the topic pages are positions and the standards pages describe what is built.

A declaration is not evidence

Much of what institutions rely on is declared rather than demonstrated: a supplier’s statement about where data is processed, a certificate, a test report, a metadata field. Declarations are useful. They are not the same as evidence that something is true.

We apply the same distinction to ourselves. When we state something about our own work, we try to indicate what it rests on: whether it can be inspected, whether it has been tested and under what conditions, or whether it is our own assessment.

Unknown is an acceptable answer

Where we do not know something, we say so. We would rather leave a question open than fill it with an assumption that looks like a finding.

This applies to our assessments with partners as much as to what we publish. An honest “unknown” tells a decision-maker where to look next. A confident guess tells them nothing, and may send them the wrong way.

Narrow claims that hold

We prefer a narrow claim that can be reproduced to a broad one that cannot. “This function continued for four hours at reduced service when this route was lost” is less impressive than “resilient”. It is also something a partner can check, rely on and build on.

When a result holds only under particular conditions, we state the conditions. When we generalise, we say that we are generalising.

What you will not find here

We describe work on this site only once it is publicly launched. You will not find initiatives, formats or services here before that point, however far their design has progressed. You will not find partnerships implied by the mention of an institution’s name. And you will not find capabilities attributed to our work that the work does not yet have.

The same rule applies to companion.esfi.eu. The Shipyard on esfi.eu names the initiatives we have in development; each is documented here once it is launched.

This is a deliberate choice about what documentation is for. Its value depends on the reader being able to trust that what it describes is what it says it is.

When we change our view

Positions develop. Evidence changes, and so does our understanding. When we change a position materially, we update the page and say what changed, rather than quietly replacing one view with another.

Every topic page carries a short record of changes at its foot: when the position was first published, and for each material change, the date and what changed. Corrections of wording or links are not listed there; changes of substance are.

Published specifications follow a stricter rule: once a version is published, it remains available unchanged, and changes appear as new versions. See Versioning.

Why this matters to us

The work we do asks partners to judge claims more carefully: claims about control, about resilience, about what a machine is reading, about what capability remains. We cannot ask that of others without applying it to ourselves first.

Related: Six questions we ask · Glossary · Versioning