Evidence Packs and provenance
Most tools give you an AI summary and ask you to trust it. OpenThunder gives you evidence and lets you check it. This is the difference that matters when the code was written by an AI: a confident paragraph is not proof, and OpenThunder never treats it as one.
What an Evidence Pack is
An Evidence Pack is the versioned record behind a verdict. When OpenThunder says a change is safe to ship (or not), the pack is the receipt: what was checked, what the checks found, and where every conclusion came from. It is assembled from the same deterministic analysis that produces the verdict, so it is reproducible , run it again on the same commit and you get the same pack.
A pack typically contains:
- The change under review , the files touched and the diff scope it was computed against.
- Verification results , the repo's own checks that ran (typecheck, tests, lint, build) and their real outcomes.
- Risk and blast radius , what the change can affect downstream, with file:line pointers.
- Findings , security and structural issues in or reachable from the change.
- The verdict , SHIP / CAUTION / HOLD , and the specific evidence that produced it.
Assemble it with openthunder evidence, or openthunder pr-evidence for a pull-request-ready pack.
Provenance: every claim is labeled
The core rule is that a claim's source is never hidden. Each conclusion in a pack carries a provenance label and a confidence, so you can tell a proven fact from an inference at a glance:
| Label | Means | Trust it as |
|---|---|---|
| deterministic | Computed from the code by a keyless analyzer (the graph, the diff) | A fact about the repo as it is |
| scanner | Reported by an integrated scanner (secrets, deps, SAST) | A tool's finding, as reliable as that tool |
| verified | An expectation that was checked and held (a test ran and passed) | Confirmed by execution |
| user-claim | Something a person or agent asserted | A claim, not yet checked |
| AI-inference | Generated or explained by a model | A hypothesis to confirm, never proof |
| missing | Expected evidence that was not produced (no tests ran) | A gap , absence, not safety |
| unknown | OpenThunder could not determine it | Undetermined; do not assume |
The practical effect: an AI-written sentence in a pack is labeled AI-inference, and a passing test is labeled verified. They never get flattened into the same "looks fine." When evidence is missing, the pack says so , OpenThunder does not read absence of a finding as proof of safety.
Why this is the moat
Features can be copied; an attractive summary can be regenerated by anyone. What compounds is the accumulated, versioned verification evidence: a durable, reproducible record of what was checked and proven over time. OpenThunder competes on that evidence, not on the editor and not on nice-looking AI narration. The building environment is only trustworthy because everything that reaches "ship" carries a pack.
Where evidence shows up
- In the app: the Evidence panel on a mission shows the pack behind its verdict.
- On the CLI:
openthunder can-i-shipprints the verdict with file:line evidence;openthunder evidence/openthunder pr-evidenceexport the pack. - In CI: gate a merge on the verdict and attach the pack to the pull request.
- To your agent (MCP): agents can pull the current findings, risks, and change context as read-only resources , see Connect your AI agent.
Related
- Decide if a change is safe to ship , read a verdict and its evidence.
- Verify an AI-generated change before you commit , produce the evidence in the first place.
- Core concepts , where Evidence Packs sit among Missions, Lenses, and Change Verification.