Thanks much for the feedback, @Lal_S and @paul_macharia!
Taking a step back, this form demonstrates what I think is the best that can be done now that Collect 1.22 has been released. The first screen of the form prompts for an identifier for the last person to edit the form and comments about the edit. There is a red notice that will be visible both on the first screen and in the hierarchy view. There could be different protocols developed around that concept. For example, editors could be asked to replace the comments in the text box or to append theirs after any existing ones. For identifying users, an external app could be used that is connected to a fingerprint scanner (e.g. https://www.simprints.com/).
While this is not perfect because there is no mechanism to require that editors add their identifier and comments when they make edits, I would argue that it's at least as good as paper. That is, when a paper form is used, there is some reliance on a protocol being established and followed -- the paper doesn't enforce it either. With paper, someone malicious could conceivably make an undetectable edit, destruct a filled survey or introduce a fake one. This is much harder with an ODK survey, especially with audits. With the track changes audit, it is now possible to always detect when a change occurred, even if someone fails to put in their identifier and comment.
I think we want to work towards being much better than paper in this regard but I wanted to point out what is possible today.
Tracking changes in the audit log was just released in Collect 1.22 on Friday. The documentation describes how to enable the audit log in XLSForm. Tracking changes will involve adding track-changes=true to the parameters column for the audit row in XLSForm but that has not yet been released.
In the mean time, you can add a bind::odk:track-changes and put true in the audit row (see my sample form described above). This will continue to work but is not the preferred approach because of the strangeness of bind:: and because it adds another column.
The good news is that this is all text so it's not very large. Assuming log lines of about 200 characters (this will depend on field names, non-ASCII characters, nesting level, etc), 3000 user actions would take up about 600kb (0.6mb). Unfortunately, I don't think there's a way around this to provide full compliance.
Can you say more about the context in which this would be useful?
As much as possible, I think we'd want this to be up to the form designer so that many different workflows can be supported. As I mentioned above, this might be done through external apps. For example, a form could call out to a small app that prompts a user for a PIN, verifies it, and then sends an identifier back to Collect once the PIN has been confirmed. This would be similar to what a fingerprint app would do.
I've started the discussion on how to actually build this at Approaches for linking form instance changes to individuals. You'll see that it's still pretty high-level because there are lots of possible mechanisms and no totally obvious one that I can identify yet.
As much as practical, I think it would be helpful to keep the discussion about the requirements and user experience here and the pros and cons of the different approaches from a development perspective in the other thread.