Read the explanation
The source organizes eight CSV fields for each component: critical flag, requirement, test status, human review, dependency and expected and actual version, along with its name. It creates a TEST gap unless test status is exactly pass. A REVIEW gap occurs only when critical is exactly yes and human review is not exactly yes. A VERSION gap occurs when the two version strings differ. These are exact text checks on supplied evidence, not software tests or proof that a release is correct. The five-row sample has three gap records: one missing human review, one missing test status and one version mismatch. A single component can also produce all three gap kinds, so blocker count is not necessarily the number of failing components. The two bars both represent three gap records on a common sixty pixels per gap scale, whether those gaps occur in three components or one. Any blocker gives the programmed BLOCK label; zero blockers gives EVIDENCE COMPLETE, which the source explicitly limits to traceability evidence. Audit input errors update the error label without clearing the previous successful result. Export and the proof view use that stored result, so current input and saved evidence can differ until a successful audit runs. Sample loads and audits the supplied sample. Results are written to local storage, but reload does not restore custom CSV: it reruns the original sample and overwrites stored evidence. Export preserves all original rows, extra columns, per-row gaps, every blocker, decision and limitation. No compiler, release deployment or backend model is invoked.