Product
Who may change what, and what changed — both recorded.
In a regulated organisation the requirements set is evidence. It has to show its own history, respect the states your method defines, and refuse changes from people who should not be making them. Those are not reporting features — they belong in the write path, and that is where they are.
The controls around the record
Your states, not ours
Statuses are configured per project — their names, their order, which of them count as final — so the workspace follows the method your organisation already runs rather than imposing a lifecycle nobody recognises.
-
Transitions that can be refused
Which status may move to which is defined, and a transition can require a specific capability. Moving a requirement to its final state can be something only certain people may do.
-
Roles and capabilities, checked on the server
Access is decided by roles and capabilities, held centrally and checked before a write happens — not by hiding a button in the browser. A user who should not be able to do something cannot do it by finding another route to it.
-
A history on every item
Each change is recorded as what it was before and what it became, with who made it and when. The record of how a requirement reached its current wording is part of the record, not a separate log somebody remembered to keep.
-
Every AI proposal names its reviewer
Because nothing an AI produces can write itself, every item that began as a proposal has a person who accepted it. "The system generated it" is never the answer to who decided.
-
Formal approval recorded against the item
Sign-off is requested from a named person and recorded against the item, or a whole section, with the approver and the date. Only the person named can give it, and a rejection needs a reason. A later edit marks the approval as changed since it was given, or, where the project locks approved items, is refused to anyone without the right to approve, so an old approval is never silently carried forward.
-
A specification that names its approval state
An issued requirements specification carries its sign-off: who approved what, and when, with a fingerprint of the approved wording, so a reader can tell whether the text in front of them is the text that was approved.
Bring your audit questions
The useful call here is the awkward one: how a change is evidenced, how a state is enforced, and what happens when somebody edits an agreed requirement.