Requirements and evidence

A content item needs more than a title before it can be considered for a collection. Operators add requirement lines with a sequence, description and source reference. Each line has an outcome of Pending, Accepted or Rejected. Supporting files carry a title, document date and external reference, and the person who verifies a file is recorded with it. These records let the reviewer see what was checked and which source supported the conclusion.

The Content Items and Details workspace places the child requirement strip beside the selected item. The operator can work from a pending line to the file that supports it, then return to the item without losing the submission context. For a thesis deposit, one line might identify the source record and another the document supplied for review. The reviewer should be able to explain a rejected line from its reason and source reference, not from memory.

• Lines belong to an item. Sequence and description make the requested evidence understandable in order.
• Files retain attribution. The file and its verifier remain linked to the content under review.
• Outcome stays explicit. Pending work remains visible until the operator records its outcome and the reviewer decides the revision.

Agree which requirement lines apply to each project and which source identifiers are stable enough for later reconciliation. Decide whether a line represents a document, an observation or a delivery prerequisite. Write the expected evidence and acceptance basis in the project’s operating policy. Use the same units and reference conventions when importing older records; a quantity without a clear unit is difficult to review.

Define who may verify a file and what a Yes value means in practice. Verification should include checking that the attached document matches the item and source reference. The verifier should be a real person record. Agree how a rejected requirement is corrected and when a new item revision is required. The decision should be attached to the revision actually inspected.

The operator enters a pending requirement for an item and links a file carrying an external source reference. The reviewer compares the document title and date with the requirement description and returns the revision with a reason when the file is wrong. The operator marks the line Rejected and assigns a task to obtain the right file. The operator adds the replacement, records the updated source reference and submits the successor revision for review. The earlier rejection and file remain part of the case history.

• Pending requirements — Lines awaiting an outcome, with their parent item and source reference.
• Rejected requirements — Lines whose reasons need correction or review.
• Unverified files — Supporting files awaiting an attributed check.

Evidence review covers the check. Content intake to decision shows where it fits in the main process.