Automated completeness check

An automated completeness check confirms that a submission, packet, or work product contains every required piece before verification can pass. The model does not judge quality, correctness, or policy fit. It compares the submitted materials to a required-item checklist and reports what is present and what is missing.

Typical required pieces include named fields (customer ID, order number, effective date), expected attachments (invoice PDF, packing list, photo of damage), and signatures or sign-off markers (wet signature image, digital signature block, attested checkbox with signer identity). The checklist defines the contract for the check. Without it, the check has nothing to verify against.

Staff still decide pass or fail. The model’s job is to surface gaps clearly enough that a QA checker can act without reopening every file by hand.

Run this check when incomplete packets routinely bounce later in the flow: claims returned for missing proof, onboarding stalled for unsigned forms, shipments held for absent customs docs, or tickets closed without required evidence. Completeness failures are expensive because they appear late, after someone has already spent time reviewing content that should never have entered review.

Good candidates share three traits:

1. A stable, named list of required items that operations agrees on.
2. Materials that arrive in predictable shapes (forms, PDFs, email threads with attachments, structured uploads).
3. A human who must still stamp pass or fail for audit, customer, or regulatory reasons.

Poor candidates include one-off packets with no agreed checklist, free-form narratives with no enumerable attachments, or cases where “complete” means subjective judgment rather than presence of specific pieces. Those belong in scoring or policy review, not a presence check.

Place the check as early as practical after intake and before deep human review. Catching a missing signature before an analyst reads twenty pages saves more time than catching it at the end.

Inputs

The check needs two inputs:

• Submission package: the fields, files, and signature artifacts under review.
• Required-item checklist: an explicit list of items that must be present for verification to pass. Each item should name what to look for, where it usually appears, and whether absence is a hard fail or a soft flag.

If the required-item checklist is missing, empty, or unusable, the model returns empty output. It does not invent a default list, infer requirements from past tickets, or guess what “usually” belongs in the packet. Empty output is the correct signal that the check cannot run.

Extraction and presence verification

The model extracts or locates each checklist item in the package. For fields, it looks for populated values in structured data or labeled locations in documents. For attachments, it checks that the expected file type or labeled document is present and non-empty. For signatures, it looks for a signature image, digital signature block, or other sign-off artifact named on the checklist.

Presence is binary for this check: found or not found. The model should not treat a blank field as present, a zero-byte file as an attachment, or a signature line without a mark as signed. Ambiguous cases (partial filename match, unclear scan quality, signature-looking smudge) should be listed as uncertain with a short reason, not silently marked present.

Output for staff

The model returns a structured gap list, not a pass/fail decision. A useful output includes:

• Items confirmed present (optional but helpful for audit trail).
• Items missing, each tied to the checklist entry name.
• Items uncertain, with a one-line reason.
• Enough location context for staff to re-check quickly (field name, attachment label, page or section hint when available).

Staff review the list, open only what is needed, and record pass or fail. They may override an uncertain finding after visual inspection. The human decision remains the verification record.

Human-in-the-loop is mandatory for this outcome. The model lists missing and uncertain items; staff still pass or fail the check.

Staff ownership covers:

• Maintaining and versioning the required-item checklist so the model is not checking against stale rules.
• Interpreting uncertain findings (illegible signature scan, wrong but related attachment, field present under an alternate label).
• Deciding whether a soft-flag gap blocks verification or can proceed with a documented exception.
• Recording the final pass/fail and any exception reason for downstream audit.

Do not auto-fail or auto-pass solely from model output. Automation that silently closes incomplete work, or that passes packets the model never fully inspected because the checklist was absent, defeats the purpose of a verify-stage check.

Related work on scoring how well outputs meet criteria, and on scanning for policy violations, complements this presence check but does not replace it. Completeness answers “is everything here?” Scoring and policy answer different verify questions.

Missing checklist. Empty output. Do not fabricate requirements. Surface a system-level error to operators so the checklist can be restored.

Stale checklist. The model may report false misses or false completeness when requirements changed but the checklist did not. Guardrail: version the checklist with the process, and fail closed to human review when checklist version is unknown.

False presence. A wrong file with a similar name, a placeholder value, or a signature page without an actual signature can look present to a weak check. Guardrail: define “present” tightly (non-empty, labeled, signature mark detected) and route uncertain cases to staff.

False absence. Alternate field labels, multi-part attachments, or signatures on a later page can look missing. Guardrail: allow staff override with a short note, and feed confirmed overrides back into checklist wording.

Scope creep. Asking the model to also grade quality, legality, or customer tone turns a completeness check into an unowned hybrid. Guardrail: keep this check limited to presence against the checklist; send quality and policy questions to their own verify paths.

Silent empty success. Treating empty model output as “no gaps found” when the checklist was missing is dangerous. Guardrail: empty output means “check did not run,” never “packet is complete.”

1. Write the required-item checklist with named fields, attachments, and signature artifacts; get operations sign-off.
2. Sample real packets (complete, incomplete, and edge cases) and confirm the model’s gap lists match staff findings.
3. Wire empty-output handling so a missing checklist blocks verification and alerts owners.
4. Keep pass/fail as a staff action; log model gap list beside the human decision.
5. Revisit the checklist when process or form versions change; treat checklist drift as a defect.

Done well, automated completeness checking shortens the path from intake to a trustworthy verify decision: the model enumerates gaps, staff decide, and incomplete work stops early instead of failing late.