Comments & Change History
Compliance review is rarely a solo activity. A finding gets raised, someone disputes it, someone else marks it a false positive — and three weeks later an auditor asks who decided that, and why.
Every control and every individual finding therefore carries a comment thread and an attributed change history.
Where to find them
Open a run, then open a control's details.
- Each finding, when expanded, has a Discussion box beneath its status override.
- The control as a whole has a Control Discussion card further down the page. It is there even when the control produced no findings at all, so a clean result can still be discussed.
Commenting
Type into the box and choose Add comment. Comments are attributed to your signed-in azuma account and stamped with the time.
You can Edit and Delete your own comments; those actions do not appear on comments written by someone else.
The Edit and Delete buttons are a courtesy, not a security control. Comments live in a plain file in your project's data directory, which anyone with access to that folder can read or change. Treat the thread as a working record for your team, not as tamper-proof evidence.
Deleting removes the comment text but leaves the entry in place — the row still shows who wrote it and when, with the body replaced by comment deleted. If the comment had been edited earlier, the previous wording remains in the change history. A deletion is a redaction, not an erasure, which is what makes the thread usable as an audit trail.
Change history
Below the thread, Change history lists what happened to this control or finding, in order:
- a status change, naming what it went from and to
- a comment added
- a comment edited
- a comment deleted
each with the reviewer's name and the time. Entries that move a finding into a suppressing state — marking it a false positive, an accepted risk, mitigated, or not applicable — are highlighted.
Restoring is recorded as well as suppressing. If a finding is marked False Positive and later reinstated, both steps appear, including when the two were done by different people. Nothing is removed from the history when a status is reverted.
Your existing notes
Notes and status overrides you recorded before this feature existed are carried over automatically. Because the old format stored no author, those entries are shown as Unknown user (imported) rather than being attributed to whoever happens to be signed in now — an imported note is not a recorded decision, and presenting it as one would misstate the history.
The original file is backed up before it is upgraded.
Where it is stored
One file per control, inside your project's data directory. Nothing is uploaded — comments, status overrides and history stay on your machine, exactly as your findings do.
If a control's file cannot be read, nori says so and disables commenting for that control rather than overwriting a file it does not understand:
The feedback file for this control could not be read. Comments and status overrides are disabled so the existing file is not overwritten.
That usually means the file was hand-edited or partially written. Restore it from your backup, or move it aside to start a fresh thread.
Threads include reviewer names and email addresses. If you attach your project's data folder to a Share Feedback report, the comment files are part of what is uploaded.
Related
- Review Results — reading a run and its findings.
- Share Feedback — telling azuma when a result is wrong.