Legal document request tracking: keep missing files visible

An email saying “please send the remaining documents” is hard to reconcile automatically. I would create a separate record for each approved request: matter identifier, requested item, responsible person, request date, target date supplied by the firm, and current state. The wording comes from the legal team. The software does not invent a deadline or infer a requirement from an unrelated matter.

The state model can stay small: requested, received, needs clarification, accepted, or withdrawn. Received means something arrived. Accepted means an authorized reviewer confirmed that it satisfies the request. Keeping those states separate prevents an upload event from becoming a false completion signal.

A request can also have several supporting files. A bank statement might arrive as one PDF or several scans. I would link the files to the request without forcing the number of attachments to match the number of requested items. The reviewer sees the association and can correct it.

For every upload, preserve the original storage identifier, uploader identity where available, received timestamp, and matter destination. A model may suggest that a document matches a particular request, but that suggestion should remain separate from the file itself and from the final reviewer decision.

Consider an illustrative client who uploads statement-final.pdf twice. Comparing filenames alone would be unreliable. I would use the storage provider's file identity and a content fingerprint where appropriate to flag likely duplicates. The system should show both receipt events while helping the reviewer avoid checking the same contents twice.

If the file appears to belong to another matter, stop automatic association. Do not copy it into a second matter to make the checklist look complete. Route it to a restricted exception queue with enough context for the designated staff member to correct the destination. The exception notification should avoid exposing the document body to people who cannot access the matter.

The model's output should have a place for uncertainty. If a scanned page cannot be read, the result is unreadable, with the affected page identified when possible. If the requested date range cannot be established, the proposed match should say so. A plausible filename does not establish the contents.

I would ask the implementation partner to demonstrate an incomplete response, a password-protected file, a corrupted attachment, and a file containing two different document types. These examples reveal whether the workflow can stop honestly. A system that always returns a completed checklist is unsuitable for tracking missing evidence.

File processing also needs a security boundary. OWASP's file upload guidance recommends controls including allowed file types, size limits, and storage safeguards. I would use those controls before sending supported content into extraction. An attachment should not gain executable privileges because it arrived through an approved portal.

A reminder should be assembled from the current request state. If the reviewer accepted an item this morning, the afternoon reminder should not ask for it again. I would recheck the register immediately before creating the draft and include the register revision in the draft's provenance.

For the first release, staff review the recipient, request list, and message before sending. The workflow should show a preview containing only the relevant missing items. It should not summarize confidential document contents in the email subject or add legal commentary about consequences.

If a reminder is approved and then the client uploads a file, the draft may be stale. Mark it for refresh rather than assuming approval covers any later wording. The sent-message record should reference the actual approved message and provider identifier. A failed send remains a failed send; it should not update the request to “client reminded.”

Uploads can be missed if a connector stops. I would include a reconciliation job that compares known file identifiers with the authorized matter folder. It should identify new files, moved files, and records whose source can no longer be accessed. It should never interpret a temporary connector failure as proof that every request is outstanding.

Google Drive documents a changes collection for detecting file changes. That can support synchronization when Drive is the approved repository. The application still owns the mapping between a changed file and the firm's request state.

Keep a visible last-successful-sync timestamp. If the connector is behind, the dashboard should say the checklist may be incomplete. Staff can then inspect the source repository or pause reminders until synchronization recovers.

I would accept the first release only after staff can follow a request from creation through receipt, clarification, acceptance, and reminder history. The test set should include two matters with similar client names, a duplicate upload, a withdrawn request, a reviewer correction, and a connector outage.

Measure review time, incorrectly matched files, reminders requiring correction, and items falsely marked complete. Compare those observations with the existing process using a defined sample. Do not count uploaded files as resolved requests, and do not claim time savings from the model's response time alone.

The deliverable should include the state definitions, permission mapping, exception queue, recovery steps, and the name of the person who owns the register. That gives the firm a manageable administrative system with a clear boundary around professional judgment.

For the demonstration, I would give the implementer a synthetic request for a signed agreement and a statement covering a specified period. Then I would upload an unsigned agreement and a statement for the wrong period. Both files should appear as received. Neither should become accepted automatically.

Next, a reviewer should mark the agreement as needing a signature and the statement as needing the correct period. The reminder draft should contain those two specific requests. When the signed agreement arrives, the workflow should preserve the earlier file, associate the replacement, and let the reviewer accept only that item.

Finally, replay the upload notification. The checklist should not create another request or another reminder. This short demonstration tests state meaning, revision handling, and duplicate events together. I would ask for the resulting records as acceptance evidence, because a narrated screen recording alone can hide an incorrect state transition.