Source provenance and limitations

Two ideas make the lab's results trustworthy: evidence and provenance.

Evidence#

A claim about a design must rest on something a tool measured.

• On the page. A stage card shows the run's id beside its result. The numbers on a build card come from that build's reports.
• From Nelix Agent. The timing and implementation agents are given measured facts, each with an id, and a list of allowed actions. Every statement they make must cite the facts it rests on, and they may recommend only from the list. They cannot state a slack, a delay or a cell count that was not measured.
• In a diagnosis. Measured facts, the AI's reasoning and its recommendation are labelled separately.

Provenance#

A result belongs to the exact version of the source it was measured on.

• Every run has an id, and the lab records which version of the source it used.
• A diagnosis is made against the source of the failed run, not against whatever is in the file now.
• A repair is tied to the version it was written for. If you have changed the file since, the lab notices and does not apply an outdated repair over newer work.
• A pass on an older version says nothing about a newer one. Only a run on the changed source counts.

What "verified" means#

A repair is called verified only when the lab has applied it to a separate copy of the project, run the test there, and seen it pass. Until then it is a proposal.

What is never done to get a pass#

The lab's rules forbid weakening a test, changing an expected value, removing a check or relaxing a timing target so that a run passes. If a test or a target is itself wrong, that is said openly and corrected as its own change.

Why this matters for learning#

A beginner cannot yet tell a confident wrong answer from a right one. By holding every claim to a measured run, the lab makes its answers checkable: you can open the run, read the log, and see for yourself.