Requirements and documents

A service case can include multiple requirements. Each line has a sequence, description and outcome. Staff can record the observed date, quantity, unit, amount, source reference and submitted date when those details matter to the request. The line stays linked to its parent case, so a reviewer can inspect individual observations without treating a saved list as a separate source of truth. An accepted line and a rejected line need different follow-up, even if they belong to the same application.

Documents provide supporting files, their dates and external references. A verification value identifies whether the file was checked, and the verifier reference records who did it. The operator prepares the material; the reviewer evaluates the case against that material. A document marked verified is evidence that someone checked it, while the decision still belongs in a separate review record.

• Requirement detail. Each line has its own outcome and source reference under the parent case.
• File verification. Supporting documents carry a verification value and named verifier.
• Follow-up work. An assigned action captures a correction or request that must be completed.

Agree the minimum description a requirement line needs, and when quantity, amount or observed date should be entered. Decide how an incoming file is named and how its external reference relates to a document held elsewhere. Name the person who can verify a file and explain what that check means for the service. Agree how an operator records a rejected requirement reason and assigns the correction to a person with a due date.

Where the source application uses its own line identifier, keep that reference stable. A repeated import must be reconciled to the intended line rather than silently creating another one. A source mapping can document a transform rule, but the service owner should review real examples before relying on it.

Consider a submitted service request with two requirement lines. The first has a matching source reference and is accepted. The second has a document whose external reference does not match the application, so its outcome is rejected and an operator gets an action to seek a corrected file. The operator attaches the new file to the case, records its document date and asks the verifier to check it. The reviewer then sees the earlier rejection, the completed action and the verified document when deciding the current revision.

Rehearse a file that remains unverified and a requirement with no source reference. The team should be able to explain what still needs attention. The case should not be treated as complete merely because a file was uploaded or a line exists.

• Pending requirements — Lines awaiting an outcome under their parent cases.
• Documents to verify — Supporting files awaiting a named verification.
• Rejected requirements — Lines requiring correction and a recorded reason.

• Requirement verification shows the evidence handoff.