Workflow v1.3 — Fully corrected workflow, Aug 2026

Legal Brief Processing System

Workflow & Stage Reference · User only interacts at Upload and Completed. Internal team owns WIP and QC entirely.

Changes in v1.3
Engine (automated)
Internal team
QC Reviewer
User / Client
System (automated)
Return path

User — Upload & Submit

U
User logs in and uploads a brief (Word .docx or PDF)
U
User clicks Submit — system creates a Job ID and places the job in the WIP queue. Internal team is notified.
U
User has no further access until the job reaches Completed. They can see job status (In Progress / Completed) but cannot view WIP or QC details.
↓
1

Stage 1 — WIP (Work in Progress)

Internal team only · Engine manually triggered · Internal team reviews output · Moves to QC when satisfied

▴
🚫
User has no access to WIP — This stage is internal team only. The user cannot see or interact with anything here.
How a job enters WIP

Route A — New Job

  • User submitted a brief for the first time
  • System creates a new Job ID
  • TOC and TOA will be generated from scratch
  • Job appears in WIP queue for internal team

Route B — Returned from Completed

  • User submitted comments and/or a revised brief
  • Internal team sent the job back to WIP
  • Existing TOC and TOA carried as baseline
  • Engine reconciles — does NOT start from scratch
  • Same Job ID retained; new version created
What happens in WIP
I
Internal team reviews the submitted brief
I
Internal team manually triggers the AI engine — the engine does not run automatically
E
Engine reads the brief and generates TOC (headings, page numbers, hyperlinks) and TOA (all citations, grouped alphabetically, all page references hyperlinked). Highlights every captured item in the document.
I
Internal team downloads the document/PDF to review the AI output — checks TOC and TOA for accuracy using the highlights as a guide
I
If something is missed or incorrect, internal team reruns the engine. Each rerun creates a new version under the same Job ID.
I
When satisfied, internal team clicks "Move to QC"
✅
Engine rerun on Route B — Uses existing TOC and TOA as baseline to minimise AI token usage. Reconciles changes; does not regenerate from scratch.
⚑
Open — confirm with Hemant before build: Engine trigger method not yet decided.
Option 1 — Automatic: Engine runs as soon as user submits. Faster, but AI tokens consumed on every submission including bad uploads.
Option 2 — Manual: Internal team clicks "Run Engine" in WIP after reviewing the uploaded file. Slower, but full cost control — no tokens wasted on bad uploads. Currently documented as manual pending Hemant's confirmation.
↓
2

Stage 2 — QC (Quality Check)

Internal team only · Download → correct offline in Word → upload corrected file → mark Completed

▴
🚫
User has no access to QC — Internal team only. No in-system editing. All corrections happen offline in Word.
QC process — step by step
Q
QC Reviewer downloads the document from the system
Q
Reviews the document offline, manually — scans every TOC entry and TOA citation page by page. Uses highlights to spot anything the engine may have missed.
Q
Makes all corrections directly in the downloaded Word file — fixes extra text, missing citations, incorrect entries
Q
Uploads the corrected Word file back into the system
Q
Clicks "Mark as Completed" — system moves job to Completed and notifies the user
ℹ️
No in-system editing — There is no in-browser TOC/TOA editor. All corrections are made in the downloaded Word file and uploaded back. The system stores the corrected file as the final output.
↓
3

Stage 3 — Completed

User downloads final document · If changes needed, user submits feedback → job returns to WIP

▴
User downloads
U
User is notified that their brief is ready
U
User logs in with their own account and downloads the final document directly — no shared link, no email handoff
U
User reviews the document offline manually
✅
Zero silent failures — The system must never release a file that has not completed the full WIP and QC cycle. Download is enabled only when QC has uploaded the corrected file and marked it complete.
Decision — is the user satisfied?
✓ Yes — close the job

Internal team clicks "Close Job". Job exits the active queue and enters 6-month retention.

✗ No — user requests changes

User submits comments and/or uploads a revised brief. Job returns to WIP. Internal team reruns engine using existing TOC/TOA as baseline.

🔒
TOC and TOA are locked at Completed — Once QC uploads the corrected document and marks it Completed, all TOC entries and TOA citations are locked. No automated process can overwrite them. Only pagination and hyperlinks can be updated automatically (Path A). Any change to TOC or TOA entries requires a full WIP → QC cycle (Path B).
Two paths when user requests changes

Path A — Text changes only ~99%

User changed wording or argument in the brief. TOC headings and TOA citations are not added, removed, or renamed.

Engine reruns automatically — updates pagination and hyperlinks only. TOC and TOA entry text stays locked and cannot be changed.

Job returns directly to Completed — no WIP, no QC cycle needed.

Path B — TOC/TOA affected ~1%

User added/removed citations or changed headings. TOC or TOA entries are genuinely different.

User indicates TOC/TOA is affected when submitting. Job routes back to WIP for full rerun. Engine uses existing TOC/TOA as baseline.

Full cycle required: WIP → QC → Completed before user can download again.

↓
4

Stage 4 — Closed

Job exits active queue · 6-month retention · Full deletion after expiry including audit trail

▴

During retention (0–6 months)

  • Job visible in archive — read-only
  • Full audit trail viewable
  • Final document still available to download
  • No actions available

After 6 months — full deletion

  • All uploaded brief files deleted
  • All generated outputs deleted
  • All version history deleted
  • Audit trail deleted — confirmed by client, Aug 21, 2026
  • Deletion logged as final record before purge
✅
6-month retention confirmed — Clock starts from the date the job is moved to Closed. All files, outputs, version history, and audit trail permanently deleted after 6 months. Confirmed — Hemant Desai, Aug 21, 2026.
R

Roles — v1.3

3 roles only · Must be confirmed by Hemant before build

▴
⚠️
Needs sign-off from Hemant before build — Do not build role-based access until this table is confirmed in writing.
RoleWhat They Can DoStages Accessible
Admin Everything. Manage users, assign roles, view all jobs, access all audit trails, configure system settings. All stages
QC Reviewer Access jobs in WIP and QC. Manually trigger AI engine. Download documents. Upload corrected documents. Move jobs between stages. Mark jobs as Completed. Close jobs at Completed stage. WIP, QC, Completed
User / Client Log in. Upload brief and submit. View job status (In Progress / Completed). Download final document from Completed. Submit comments and/or revised brief if changes needed. Upload, Completed (own jobs)
A

Audit Trail

Every meaningful action logged · Deleted after 6-month retention

▴
Brief uploaded — who, when, file name, file size
Engine run triggered — who, when, version number, duration
Engine run completed — version created, TOC and TOA entry counts
Document downloaded — who, when, which version
Corrected document uploaded by QC — who, when, which version
Stage transition — who moved it, from, to, when
Job sent back to WIP — who, when
User feedback submitted — when, type (comments / revised brief)
Job closed — who, when
File deleted (retention expiry) — job ID, timestamp, system triggered
User login / logout — user ID, timestamp, IP
Failed login attempt — timestamp, IP
User account changes — who, what changed, when
Audit trail deletion — final record before full purge
🗑️
Audit trail deleted after 6 months — Confirmed by client — Hemant Desai, Aug 21, 2026.
Legal Brief Processing System  ·  Workflow v1.3  ·  August 2026