Approval binds to an immutable version
An approval record that can be retroactively changed is not an approval record. Approving here freezes the exact snapshot, specification and rule version that were reviewed.
- 37 requirements
- 12 business rules · 8 risks
- 214 citations
- 2 contradictions open
- 147 test cases · v12
- 82 scenarios
- 86 automation candidates
- SALC Test Specification Model
- 5 principles evaluated
- 3 pass · 2 fail
- 3 open findings
- Deterministic · no model calls
3 quality findings remain open
Approving does not close them. The approval record captures that a person saw these findings and decided to proceed — which is a different and more useful fact than the findings disappearing.
- QP-03REQ-1042Rolling 24-hour transaction total — no test at below the limit (₹49,999).
- QP-04REQ-1028Requirement states 1 validation rule but has no negative test case.
- QP-04REQ-1047Requirement restricts access by role (Adjuster, Supervisor) but has no negative test case.
What approving actually does
Approving this workflow freezes the referenced versions. Later edits create successors — they cannot alter what was approved.
- Requirements
- v17
- Test specification
- v12
- Quality rules
- v1.0
- Snapshot
- KN-0842
- Approver
- Demo QA Lead · Quality Lead
- Scope
- Publishing and automation generation
Nothing publishes and no automation is generated until this is approved.
This gate is not friction to be optimised away — it is the “human-governed” half of the positioning. Every generation step in the first release terminates here.