“All reviews approved” means little when no reviews were required in the data
An application can report that every listed review is approved without establishing that the required review work exists. The missing question is whether the list itself represents the organisation's actual requirement.
This fictional investigation concerns a staff workpack prepared before a maintenance proposal is released. The owner's rule requires a service review and a parts review for this workpack type. Approval records must belong to the identified workpack and its current review material. An unrelated internal notice has a separately approved process that requires neither review.
Find the empty set behind the reassuring label
Workpack P-31 appears as “Reviews complete.” Its source material is available, but no service or parts reviewer has recorded a decision. The operator expects the item to remain in preparation.
The inspected rule-loading path returns no required-review configuration for this workpack type. The application converts that absence into an empty array and evaluates whether every entry is approved. It then displays the completion label.
In JavaScript, every() returns true for an empty array. The ECMAScript specification states that behaviour explicitly. The method answers whether any visited entry fails the predicate; it does not establish that a business-required entry exists.
The language operation is behaving as defined. The application's use of that result is incomplete.
Separate configuration from decisions
Three different questions need answers:
- Does this workpack type have a valid, explicit review rule?
- Does the record contain the complete required review set for the relevant material?
- Has every required review reached the permitted approved state?
For P-31, the answer to the first question is no in the loaded configuration. Treating that state as an intentionally review-free process hides the missing rule and skips the other questions.
The owner's approved source defines the service and parts requirements. The maintainer restores that configuration through the supported process and changes the missing-configuration response to a hold with a named configuration owner. A loading failure must not manufacture permission to release a workpack.
The application validates the structure and identities of the required review records before evaluating their decisions. An arbitrary nonempty list, a sparse array or a review belonging to another pack cannot satisfy the business rule merely by containing an approved value.
Complete the corrected sequence for P-31
With the required set established, P-31 shows two outstanding reviews. Its material and workpack identity are unchanged. Staff can now see why the proposal is not ready and which responsibilities remain.
In the fictional review exercise, the authorised service reviewer records approval first. The parts review remains outstanding, so P-31 remains held. The authorised parts reviewer then records the second decision against the same identified material. Only after both required records are present and approved does the pack satisfy this review condition.
Satisfying the review condition is still distinct from dispatch. The organisation's release authority and any other requirements remain in force. The correction does not send a proposal or backdate decisions that never occurred.
Contrast the cases that could otherwise be confused
| Fixture | Evidence | Correct result |
|---|---|---|
| P-31 before configuration is restored | Missing required-review rule | Hold for configuration review |
| P-31 with one approved decision | Complete required set, one still outstanding | Reviews incomplete |
| P-31 after both authorised decisions | Both required reviews approved for the identified material | Review condition satisfied |
| P-32, ordinary previously valid pack | Complete service and parts approvals | Remains satisfactory |
| P-33, one pending decision | Required set exists, decision incomplete | Remains held |
| N-34, internal notice | Explicit separate rule says these reviews are not required | Uses its own approved process |
| A pack with an unrelated approved record | Record identity does not satisfy its required set | Not accepted as a substitute |
The N-34 control matters. A blanket “every task needs at least one approval” rule would introduce a new business requirement. The correction instead distinguishes an explicit no-review policy from missing configuration, and applies the appropriate rule to each type.
Use wording that reflects the evidence
The staff view replaces “Reviews complete” on the original P-31 state with an explanation that its review configuration needs attention. The named owner can inspect that problem without asking reviewers to approve an undefined requirement.
For a configured pack, the view identifies the outstanding review rather than making the operator infer it from a generic status. A covering colleague can continue the work using the same evidence and responsibilities.
Earlier packs marked complete under the faulty rule need a separate assessment. The new logic cannot establish whether a past review occurred outside the system. Preserve the available records and let the authorised owner determine the treatment of each affected pack.
Keep the required set in the acceptance evidence
Retain examples for absent configuration, a complete-but-pending set, a fully approved set and the explicitly different notice process. The test should inspect the evidence behind the label, not only the label itself.
The request operations service can address this relationship between rules, records and staff actions. Use project planning to identify who owns the required review set before changing the application that evaluates it.