Turning a sensitive-file audit idea into clearer acceptance criteria
This is not a customer case study. It is a public validation example showing how an audit receipt suggestion changed an open-source issue's criteria.
Context
Traceary is a local-first session log and audit trail for AI coding agents. In duck8823/traceary#1257, the maintainer proposed sensitive-file access detection for command audits.
The risk: a passive audit trail can see command text such as a shell command touching a sensitive path, but that is not always proof that the file was actually opened.
Before
Single-claim risk
Sensitive file detection could collapse several different claims into one boolean: matched, accessed, redacted, and fully audited.
Overclaim risk
Command text can show sensitive intent without proving actual file access unless stronger host/tool evidence exists.
Receipt-shaped suggestion
The suggestion was to separate sensitive-path detection, redaction, and audit coverage into different receipt fields.
sensitive_path_match: true | false sensitivity_class: dotenv | ssh_key | cloud_creds | browser_profile | custom access_operation: read | write | stat | list | unknown redaction_state: applied | not_needed | not_available | failed audit_coverage: complete | partial | unobservable coverage_gap: command_text_only | stdout_truncated | hook_missing_file_event | path_unresolved
After
The maintainer replied positively and updated the issue body to separate match/class, observed or inferred operation, redaction state, audit coverage, and coverage gaps. Acceptance criteria were also expanded for command-text-only, truncated stdout, structured file-tool access, and unresolved-path cases.
This is the current best validation signal: a maintainer changed issue criteria because the receipt framing made the audit claim more precise.
Reusable lesson
Good agent audit receipts do not only say whether something happened. They state how strong the evidence is and where the audit trail is incomplete.