Evidence goes in the body of the page the reader was sent to

Decision. An evidence artifact is published where the claim is made, as the kind of thing the claim asks for — a percentage as a number, a diagram as an <img> — in the body of the page, not in the footer and not one click away.

What produced it. A review of Task 5 and Task 9 returned two confident negative findings: no visible coverage percentage, no test report a reviewer can inspect, and no rendered architecture image or frontend → API → database → integrations flow diagram. Every one of those artifacts existed, was correct, was fetchable and was linked. /coverage.json and /engineering#tests had shipped that morning; /architecture.png and /architecture.mmd hours later.

The review's own citations gave the reason: it read /developers and /security. /developers linked to /engineering twice, both from the footer, at 46% of the document. Neither page carried a coverage figure or a rendered system diagram anywhere in its body.

Why this is a different failure from D-069 through D-087. Those five were all one shape — the artifact existed, was generated rather than typed, was correct, and was not fetchable. The fix each time was to publish the bytes. Here the bytes were published. What was missing is that the reader was never on the page that shows them, and a reader forms their verdict from the body of the page they were sent to. A link is not an image; a footer link is not discovery.

Two causes, not one. The second is easy to miss. Both pages already carry a picture — <ArchitectureDiagram />, four interactive nodes covering the field-device data path. It is not a component or deployment diagram, so it does not answer the question that was asked, and its labels are <text> inside an <svg>, so a reader extracting page text does not experience it as a picture at all. A diagram that only exists to a sighted reader with JavaScript is, to everyone else, prose about a diagram. Hence ALT_TEXT in RequestFlowFigure spelling out the entire request path in sentences.

Alternative rejected: repeat the numbers into the page copy. Faster, and guarantees drift. The figures come from getCoverageRun() and getArchitectureRender(), which read public/coverage.json and the PNG's own IHDR header, so /developers and /engineering cannot disagree and no dimension is ever typed. That is D-087's rule applied one level up.

On the "no public CI badge" finding. Answered in words, not with a badge. The repository is private; a badge pointing into it renders broken for everyone outside the team, which converts an honest claim into a visibly broken one. The run that produced the numbers is committed as an artifact instead, and /developers#verification says plainly why there is no badge.

What would make this wrong. If the pages become long enough that a body-level exhibit is itself unreachable, or if the 1.4 MB render starts costing the Lighthouse scores those same pages publish about themselves. The figure is loading="lazy" and served through next/image as AVIF or WebP at the viewport width for exactly that reason; if the published Performance numbers drop, the figure moves behind a disclosure and this decision is revisited rather than quietly kept.