Check a published claim

This section routes a published sentence to the evidence behind it, and routes a vulnerability to the people who can act on it; it holds no evidence of its own, because a copy of evidence is not evidence.

Take a sentence to its evidence, in three steps

1. Find the claim term

A statement about what happened to an action is incomplete without its timing and its failure posture. ADR 0033 §6 defines the canonical vocabulary for this, and downstream material is required to pick one of its terms rather than an undifferentiated verb.

The eleven terms are:

Observed · Detected · Evaluated · Denied before execution · Redacted · Approval required · Degraded · Unmeasured · Experimental · Planned · Unsupported

Two of those words appear on this site on a different axis. Planned and Experimental above are §6 terms about an action. The 🗺️ Planned you may have seen in the sidebar beside a page title is a documentation-area label from the status map, about an area of this documentation. A page is 🗺️ Planned because its area is; an action is Planned in §6’s sense. Neither licenses a conclusion about the other, and when you are checking a sentence it is the §6 sense that applies.

What each one means, and which mechanism can legitimately reach it today, are defined in ADR 0033 §6. This page names the terms so you can find them; it does not define them, because a second definition is how two definitions start disagreeing.

If a sentence uses none of these terms, that is the finding.

2. Ask for the evidence that term requires

Each term in §6 carries the evidence that substantiates it, and they are not interchangeable: a durable event attributed to an action substantiates Observed, and does not substantiate Denied before execution, which needs a refusal by a component sitting before the effect.

Three signals look like coverage and are not, and ADR 0033 §7 names them so they cannot be offered as substantiation: an environment variable that replaces a probe result, a probe satisfied by a binary being present on $PATH, and a capability bit asserted unconditionally.

3. Check the completeness claim separately

A statement usually carries two claims at once: what happened to an action, and how much was covered. They have different owners and different evidence, so they are checked separately and the more restrictive published outcome governs.

Report a vulnerability

Do not report a security issue through a public GitHub issue.

Vulnerability reports go to the repository that owns the affected code, through GitHub’s private vulnerability reporting on that repository, and each repository’s SECURITY.md carries its current reporting route and disclosure policy:

The organisation-wide security policy is the fallback for any repository that does not publish its own, and the rows above were checked rather than assumed.

If you are unsure which repository owns the code, file against core so it can be routed.

The reporting address is deliberately not repeated on this page. Each SECURITY.md above is the canonical source for its own route, and a copied address is one that keeps working right up until it does not.

What this page does not do

• It does not hold evidence. It routes to the artifact that does.
• It does not define a claim term. ADR 0033 §6 does.
• It does not decide whether a statement may be published. For managed-service wording that is the SaaS claim publication checklist.

Going deeper

The claim vocabulary, the evidence each term requires, and the mechanisms mapped onto them are in ADR 0033.

Last updated: 2026-08-13 by AI Agent Assembly Team