Problem
A provider profile's fingerprint includes ProgramFingerprint(), which hashes the extraction prompt text and its JSON schema (internal/peoplesweep/program.go, config.go). The recorded check and the consent grant are both keyed by that fingerprint.
So any msgvault release that edits the prompt or schema changes every profile's fingerprint on every install. Scheduled sweeps then fail with "requires a successful check for the exact provider profile" until the operator re-runs person provider check and person provider consent for each profile. Nothing in status says why.
What needs deciding
This may be the right safety choice: consent should cover exactly what leaves the archive, and a prompt change does change that. But the operational cost is real, and today it lands as a silent upgrade break.
Options:
- Keep it, and make it visible and recoverable.
status --json reports that the check or consent is for a stale program version, and a single person provider reverify <name> --yes re-runs the check and re-grants consent so an agent can recover in one step.
- Narrow it. Hash the disclosed-fields set (what categories of data leave) into the consent fingerprint, and track the program version separately so a prompt wording change does not revoke consent.
Option 1 is the smaller change and keeps the strongest guarantee. Option 2 changes what "consent" means and should be argued for explicitly.
Context
Raised in the #694 review. The prompt-in-fingerprint choice predates that PR (it came with #685); #694 added the check gate on top, which doubles the recovery work.
Problem
A provider profile's fingerprint includes
ProgramFingerprint(), which hashes the extraction prompt text and its JSON schema (internal/peoplesweep/program.go,config.go). The recorded check and the consent grant are both keyed by that fingerprint.So any msgvault release that edits the prompt or schema changes every profile's fingerprint on every install. Scheduled sweeps then fail with "requires a successful check for the exact provider profile" until the operator re-runs
person provider checkandperson provider consentfor each profile. Nothing instatussays why.What needs deciding
This may be the right safety choice: consent should cover exactly what leaves the archive, and a prompt change does change that. But the operational cost is real, and today it lands as a silent upgrade break.
Options:
status --jsonreports that the check or consent is for a stale program version, and a singleperson provider reverify <name> --yesre-runs the check and re-grants consent so an agent can recover in one step.Option 1 is the smaller change and keeps the strongest guarantee. Option 2 changes what "consent" means and should be argued for explicitly.
Context
Raised in the #694 review. The prompt-in-fingerprint choice predates that PR (it came with #685); #694 added the check gate on top, which doubles the recovery work.