spec: metadata.trimmed and metadata.sanitized provenance markers

[kgilpin]

Optional metadata written by the AppMap CLI's trim and sanitize commands, recording what was applied to the file: the tool version plus the truncation cap (trim) or the verbatim-allowed values (sanitize). Both operations are one-way, so repeated runs record what still holds: the smallest cap, and the allowlist intersection.

[dividedmind]

I wonder, how is this field useful? If we see a value then obviously it was excluded.

Also, if we do have this field, shouldn't we include all the values (including built-in) so the file is self-contained and can be interpreted without hunting down the source code for a particular version?

[kgilpin]

I think it’s good for provenance. We can add other values, although having the tool version used kind of covers that.

…

On Thu, Jul 9, 2026 at 14:53 Rafał Rzepecki ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In README.md <#54 (comment)>: > @@ -117,6 +117,12 @@ Metadata has the following attributes: * **exception** *Optional* unhandled exception which occurred during scenairo processing. * **class** *Required* exception class name. * **message** *Optional* exception message. +* **trimmed** *Optional* provenance of value truncation applied to this file (the AppMap CLI's `trim` command). Truncation is one-way; after repeated runs this records the smallest cap applied. + * **version** *Required* version of the tool that trimmed the file. + * **max_length** *Required* maximum captured-value string length the file was truncated to. +* **sanitized** *Optional* provenance of value masking applied to this file (the AppMap CLI's `sanitize` command). Every captured value string has been replaced with an equality-preserving token; masking is one-way, and after repeated runs `allow_values` records the intersection of the allowlists applied. + * **version** *Required* version of the tool that sanitized the file. + * **allow_values** *Required* values kept verbatim (exact whole-value matches), beyond the tool's built-in enumerable values (`true`, `false`, `null`, etc). I wonder, how is this field useful? If we see a value then obviously it was excluded. Also, if we do have this field, shouldn't we include all the values (including built-in) so the file is self-contained and can be interpreted without hunting down the source code for a particular version? — Reply to this email directly, view it on GitHub <#54?email_source=notifications&email_token=AAAVC66XD6XMJRHX6SZLJ4T5D7S23A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINRWGU4DMNBQGUYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4665864050>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVC652X3GC7CK2K55GXL35D7S23AVCNFSNUABFKJSXA33TNF2G64TZHMYTOOJVGI3DAMZYHNEXG43VMU5TIOBUGY3DAOJXGU42C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dividedmind]

I think it’s good for provenance.

Yeah, but isn't it just noise? Up to you I suppose, I don't have a strong opinion.