---
title: "Evidence packs"
---

# Evidence packs

Build a signed evidence pack for a release, a change, a trace or a time range in the Editor, verify a pack someone sent you, drill into the evidence behind each answer, and reproduce a recorded AI request.

An evidence pack answers, for one scope, the six questions a regulated auditor asks about AI-assisted work, with a verdict per question, every gap listed and the recorded events behind every statement. It is one signed file (`.nievidence.tar`) that anyone can verify offline. You build and verify packs in the Editor's **Evidence** view; the [Evidence](https://neuralinverse.com/docs/evidence/) section explains packs for auditors in depth.

A pack is evidence toward a requirement, not a certification. It is tamper-evident: changes are detected, not prevented. Building a pack is local: no network and no server is called.

## The six questions

| # | Question |
|---|---|
| 1 | Show me every line in this release that AI touched. |
| 2 | Which model and version produced it, and what context did it see? |
| 3 | Who reviewed and approved it, and can you prove the approval was not altered? |
| 4 | Did any source code or secrets leave our boundary? |
| 5 | What happens if a log is deleted or someone misbehaves? |
| 6 | Can you reproduce this result six months from now? |

Each answer has a verdict: `complete`, `partial` (with how many gaps) or `cannot-answer`. A line with no record that connects it to an AI edit stays unattributed; AI authorship is never inferred from style or timing.

## Scopes

| Scope | What you give |
|---|---|
| Release | One or more repositories, each with a start ref and a release ref |
| Change | One repository and a commit, a branch (base and head) or a pull request (id, base, head) |
| Trace | A trace id or an agent session id |
| Time range | A start and end, with optional filters: users, agents, projects and event classes |

Tags, branches and pull request numbers are labels; the pack always names the commits they resolved to. For a trace or a time range, question 1 can be answered only if you also choose repositories to attribute lines in.

## Build a pack

1. Run **Build Evidence Pack** (the Evidence category of the Command Palette, or the Evidence panel).
2. Choose the scope kind and fill it in. For a repository, choose its local clone in the folder dialog (**Local Clone of the Repository**), the repository id the evidence names, and the refs. A shallow clone is refused. An invalid scope is refused with the reason before anything is built.
3. Choose where to save the pack (**Save Evidence Pack**).
4. Choose the bundles. Your own device's record for the scope is exported for you. Add bundles others exported for you under **Audit Bundles to Combine**.
5. Optionally, pin the device keys whose evidence you accept (fingerprints separated by commas; groups of four characters are accepted). Bundles signed by any other key are excluded and reported. With none pinned, every key that verifies is used and reported as unpinned.
6. The build runs with progress ("Building the evidence pack…"). The pack is signed by your device key through the audit ledger, recorded as `evidence.built`, and opens verified.

The ledger must be healthy to build: a pack is never signed while the ledger cannot record.

### Combining several developers

Each developer exports a bundle for you from their Activity Log (**Export Evidence Bundle**), naming you (your device key fingerprint) or the organisation as the audience. Your organisation's `NeuralInverseAuditEvidenceAllowedBuilders` policy decides who bundles may be exported for. A bundle not meant for you is refused and reported.

## Verify a pack someone sent you

1. Run **Open and Verify Evidence Pack** and choose the file (**Evidence Pack to Verify**).
2. Optionally give the signer's fingerprint you expect and the device keys you expect the evidence to come from. Get fingerprints through a different channel than the pack.
3. The verifier regenerates every answer, verdict, gap and output from the evidence inside the pack and compares byte for byte. Answers are shown only when the pack verifies.

A failure shows the reason code (for example `signature-invalid`, `unexpected-key`, `unexpected-device-key`, `answers-do-not-follow`, `output-does-not-follow`), the detail, the member and every answer difference. A pack built with other derivation or writer versions stops with `unsupported-version`: verify it with the tool version its manifest names.

Opening a pack is recorded in your own ledger as `evidence.verified`.

## Read the answers

The view lists the six questions with their verdicts, for example "Question 1: ... Partial, 3 gaps." Select a question to see its statements and gaps:

- question 1, per file and line range: class, writers, prior writers and commit;
- question 2, per AI identity: model, version and context;
- question 3, approvals with their proofs, and ranges nobody reviewed;
- question 4, data crossings with their policy standing;
- question 5, bundles, refusals, findings (for example a modified build), coverage and duplicates;
- question 6, recorded requests, earlier reproduction runs, and why reproduction is impossible where it is.

Every statement and gap opens the evidence behind it: audit events (action, time, actor, device key, ledger position, entry hash, inclusion proof and fields), Checks entries, commits and bundles. An event your own device recorded links to the Activity Log.

**Open Evidence Report** opens the pack's HTML report in your browser. If the pack holds raw content and your organisation's `NeuralInverseAuditEvidenceIncludeContent` is off, the report is regenerated without content. **Export Evidence Pack** copies a verified pack (and optionally its report) unchanged; an existing file is never overwritten. **Close Evidence Pack** closes it. At most four packs stay open.

## Reproduce a recorded AI request

On a question 6 record, **Reproduce a Recorded AI Request** sends the recorded prompt again to the same model and version. It never runs automatically, and it runs only when:

1. the request was a chat request in a window, its prompt was captured at the `full` level and revealed in a verified bundle, its digest matches, it had no attachments, and the model, version and response digest were recorded;
2. your organisation allows it (`NeuralInverseAuditEvidenceReproductionAllowed`, off on managed installs) and the ledger can record;
3. the secret scanner finds nothing in the prompt;
4. the same model and version are served now;
5. the policy decision point allows the model call;
6. you confirm in a dialog that names the model, version, provider, prompt digest and length.

The result is `identical` (same response digest), `equivalent` (equal after normalising Unicode, line endings, trailing spaces and blank lines at the start and end) or `different`. A different result can come from context the recording does not hold (system instructions, earlier turns, tool schemas). Every attempt, refused or not, is recorded as `evidence.reproduced`.

## From the command line

The Neural Inverse source has offline tools:

```sh
scripts/ni-evidence.sh --help
scripts/ni-evidence-verify.sh --expect-key <fingerprint> --expect-device <fingerprint> <pack.nievidence.tar>
```

Verifier exit codes: 0 verified, 1 error or unsupported version, 2 the pack does not verify. The standalone verifier opens no ledger and records nothing. Reproduction runs only from the app.

## What is not claimed

Framework mappings in the report are labelled "mapping, not certification". A pack proves which keys signed what; which person or machine holds a key is established out of band. Work done outside Neural Inverse, before recording was on, or while it was off appears as unattributed or as a gap.