xerg explain reads the newest local audit snapshot by default and shows:
- classification or explicit neutral-observation status
- why the detector emitted the item
- observed evidence and evidence still missing
- economic meaning and pricing coverage
- run/call IDs, local source locators, and the observed time range
- digest-only tool input, result, and chain-invocation evidence when available
- limitations and the next useful inspection step
Why, Evidence, Economic meaning, Pricing and analysis coverage, Source/time range, Local source locators, Limitations, and Next step sections instead of embedding a pretty-printed JSON object. Use --json for the byte-stable machine-readable packet.
Raw tool arguments and results are never retained in an explanation packet. Xerg canonicalizes JSON by sorting object keys while preserving values and array order, then stores only SHA-256 digests and byte counts.
Choose an audit or output format
<audit-id>:<generated-at> key so a saved report always resolves its original local snapshot. When the report was persisted, the hint also carries its absolute, shell-quoted --db path, including when the audit received a relative custom-store path. --json returns that snapshot selector together with the packet, audit IDs, runtime, generation time, and diagnostic version.
Pre-0.21 snapshots remain readable, but they do not contain evidence packets. Xerg shows the legacy item and asks you to rerun. If a stale snapshot contains tool_sequence_repetition_v1, Xerg warns that the tool-name-only monetary method is retired and its amount should not be acted on.
Snapshot requirement
Later lookup requires the local snapshot written byxerg audit. If you audit with --no-db, the current report still includes item IDs and inline evidence, but replaces executable explain commands with a lookup-unavailable message because xerg explain cannot retrieve that report later. Rerun without --no-db, or use --db consistently for both commands.
Argument-diversity limitation
Xerg deliberately preserves timestamps, nonces, temporary paths, and other apparently volatile input values in v1. This prevents different invocations from being collapsed into false exact repetitions. It also means volatile values can make semantically repeated work look distinct, which inflates the distinct ratio and under-reports repetition. A 100% ratio means every observed canonical(tool name, input) pair differed. It does not prove that the calls were semantically different or successful. Generic field dropping is out of scope; future semantic normalization requires tool-specific allowlists and calibration.