Case brief

The brief is the one document a legal team reads first on a device matter. It must be short, dense, and checkable: every statement in it carries a citation to a document and page (or a deposition page and line), and a person can open that page and find the statement. A brief that cannot be checked line by line is worth nothing in litigation. Everything below serves that one requirement.

The order of work is fixed because each step depends on the one before it: build the archive, index it, extract the timelines and the witness statements into tables, verify, then write. Writing first and citing afterwards produces plausible prose with wrong pages. Do not do it.

1. Settle the inputs (two minutes, not twenty)

Confirm, from the request or by looking, and state the assumptions you make in the brief's header:

• Where the documents are: a folder (local, mounted Drive, or uploaded). Treat every file in it as evidence; never edit, rename, or move an original. Work on copies in a working folder next to it (<case>-brief/).
• Whose brief: which party the user represents. The brief is written for that team, but the facts are stated neutrally — what the record shows, for and against. That is what makes it useful in a deposition.
• The question, if the user has one ("what happened with the pump", "was the manufacturer on notice"). If none, the brief answers the standard questions in section 5.
• Reference date: today unless the user names a date; dates in the brief are written in full (2024-03-14, not 3/14).

If the folder is huge (thousands of files), say so and propose a scope: the categories that matter for the question first, the rest in a second pass. Do not silently skip files; the inventory must list everything, even what you did not read.

2. Build the archive

The archive is a working copy of every document as plain text, one file per document, with a marker at every page boundary so that a citation can name the page. Build it once; every later question runs against it.

1. Inventory. Walk the folder. For each file record: path, production number or Bates range if the file name or first page carries one, type by extension, size, page count. Keep families together (an email and its attachments; a report and its appendices).
2. Extract text with page markers. For PDFs use pdftotext -layout page by page and write === PAGE n === before each page. For scanned PDFs (no text layer) run OCR if a tool is available (ocrmypdf, tesseract); if none is available, mark the document OCR needed in the index and tell the user — do not guess its contents. For .docx, .xlsx, .msg/.eml, .txt use the matching extractor; for spreadsheets keep the cells as a table (CSV), never prose.
3. Header. Start each text file with: ID (production number, or a short ID you assign such as D-0042 for the 42nd document, written into the index so it is stable), title, date if the document carries one, author or custodian, type, page count, quality (clean / OCR / partly illegible / redacted).
4. Index. Write index.csv with those columns plus the category from the list below. The index is the map every later step starts from, and it is the first thing the user checks.
5. Classify each document into one category. Use the document, not its file name:
6. Pleadings and orders (complaint, answer, motions, scheduling orders)
7. Discovery requests and responses (interrogatories, requests for production, requests for admission, and the answers and objections to each)
8. Depositions (transcripts, errata, exhibits)
9. Expert reports and disclosures
10. Medical and clinical records (chart, nursing notes, MAR, incident report, monitor strips)
11. Device data (logs, downloads, service tool reports, photographs of screens)
12. Engineering: design (DHF, requirements, drawings, V&V protocols and reports, design reviews, change orders)
13. Engineering: risk (risk management file, FMEA, hazard analysis, all revisions)
14. Engineering: software (requirements, release notes, anomaly lists, problem reports)
15. Manufacturing and service (DMR, DHR for the unit, service records, bulletins)
16. Field: complaints, MDRs, CAPAs, trend reports
17. Field actions: recalls, corrections, notices, 806 records
18. Regulatory: 510(k)/PMA, FDA correspondence, letters to file
19. Labeling, IFU, training materials
20. Correspondence (emails, letters between parties, internal manufacturer email)
21. Other / unknown (list these explicitly; do not hide them)

A small helper is faster than doing this by hand. Write it once in the working folder and reuse it on every refresh:

# build_archive.py  —  python3 build_archive.py <case_folder> <work_folder>
import sys, csv, subprocess, hashlib
from pathlib import Path
src, work = Path(sys.argv[1]), Path(sys.argv[2]); txt = work / 'text'; txt.mkdir(parents=True, exist_ok=True)
rows = []
for i, f in enumerate(sorted(p for p in src.rglob('*') if p.is_file()), 1):
    did = f'D-{i:04d}'; out = txt / f'{did}.txt'; pages = 0; quality = 'clean'
    if f.suffix.lower() == '.pdf':
        n = subprocess.run(['pdfinfo', str(f)], capture_output=True, text=True).stdout
        pages = int(next((l.split()[-1] for l in n.splitlines() if l.startswith('Pages:')), 0))
        parts = []
        for p in range(1, pages + 1):
            t = subprocess.run(['pdftotext', '-layout', '-f', str(p), '-l', str(p), str(f), '-'], capture_output=True, text=True).stdout
            parts.append(f'=== PAGE {p} ===\n{t}')
        body = '\n'.join(parts)
        if pages and len(body.strip()) < 40 * pages: quality = 'OCR needed'
    else:
        body = f.read_text(errors='replace') if f.suffix.lower() in ('.txt', '.md', '.csv', '.eml') else ''
        if not body: quality = 'extract manually (' + f.suffix + ')'
    out.write_text(f'ID: {did}\nFILE: {f.relative_to(src)}\nPAGES: {pages}\nQUALITY: {quality}\nCATEGORY: \n\n{body}')
    rows.append([did, str(f.relative_to(src)), f.suffix.lower(), pages, quality, '', hashlib.sha1(f.read_bytes()).hexdigest()[:12]])
with open(work / 'index.csv', 'w', newline='') as fh:
    csv.writer(fh).writerows([['id', 'file', 'type', 'pages', 'quality', 'category', 'sha1']] + rows)
print(len(rows), 'documents')

Fill the category column after reading the first page of each document (a batch of first pages is a fast read). Keep the SHA-1: it proves later that the text came from that file.

3. Extract before you write

Work through the archive category by category and fill five tables. Each row carries its source. These tables are the evidence base; the brief is written from them and from nothing else.

3.1 Device identity — model, catalog number, serial, lot, software version, configuration, accessories, where the unit is now and who holds it. One row per fact, with source. Two units or two software versions treated as one is the most common error in a device brief; this table prevents it.

3.2 Incident timeline — every dated or timed event from the hours and days around the event: admission, device set up, settings, alarms, interventions, outcome, device removal, preservation, downloads, inspections. Columns: date, time, clock (which clock: device, monitor, chart, wall), event, source id, page, stream (clinical / device / people). Record clock offsets once, as their own rows, and do not "correct" times silently; show both.

3.3 Case timeline — the procedural history: incident, notice to the manufacturer, complaint filed, answer, scheduling order dates, each production (date, Bates range, volume), each deposition (date, witness), expert deadlines, motions, hearings, trial date. Columns: date, event, source id, page. Include the future dates the orders set; the team reads the brief to know what is next.

3.4 Witnesses — for every deposition: witness, role, side, date, pages. Then the statements that matter, one row each: witness, topic, statement (short paraphrase, or a verbatim quote of at most two sentences in quotation marks), page:line, contradicts (ID and page of a document or another witness that says otherwise, when you find one). Topics to look for in every transcript: what the witness saw or did on the day, what the device did, training received, policies, what was known before the event, what changed after, prior similar events, who else knew. Read the whole transcript; the useful line is often in the last hour.

3.5 Legal Q&A — for each set of interrogatories, requests for admission, and requests for production: the request, the answer in one line (admitted / denied / objected and on what ground / produced with Bates range / "will produce" / nothing), source id, page. This table is where the team sees what the other side has conceded and what it has refused.

Also list, with sources, what the engineering record contains and does not: for each engineering category in section 2, whether it was produced, for which versions and dates, with an index of the main documents (DHF index, risk file revisions, V&V reports, software releases, complaint files, CAPAs, field actions, submissions). Absence is a finding: write "not in the production" rather than leaving a blank.

4. Verify before you write

• Open every cited page and confirm it says what the row says. Do this for every row, not a sample. A row that fails is corrected or deleted.
• Counts ("eleven complaints of the same failure mode") are verified by listing the eleven with sources. A count without its list is reported as "about eleven (not verified)" and never otherwise.
• Where two sources disagree (two times, two versions, two accounts), the brief shows both and says they disagree. It does not choose.
• Dates: distinguish the date a document was written from the date it was known (a report approved in May describes a test run in March). Carry both where it matters.
• Nothing in the brief comes from general knowledge of how devices or cases usually go. If the record is silent, the brief says the record is silent.

5. Write the brief

Write brief.md (and, if the user wants a file to send, convert it to .docx or PDF with the matching skill). Target length: four to eight pages for a typical matter. Dense; no filler; no adjectives about strength or weakness of the case. Use this structure, in this order, and keep the headings:

# [Matter short name] — Case brief
Prepared [date] for [party/team]. Sources: [N] documents in [folder], indexed [date]. Reference IDs are from index.csv.
Assumptions and scope: [two or three lines]

## 1. What happened
[One to three paragraphs. The event in time order, plain words, each sentence cited: [D-0012 p.3], [Depo Smith 44:12–45:3].]

## 2. The device
[Identity table from 3.1. Then two or three sentences: what it is, what it was used for, where it is now.]

## 3. Incident timeline
[Table from 3.2, trimmed to the rows that matter; the full table is attached as timeline-incident.csv. Clock offsets stated.]

## 4. Case timeline
[Table from 3.3, including upcoming dates.]

## 5. What the witnesses said
[One short block per witness: name, role, date, pages. Then four to eight bullet statements with page:line. Then "Disagreements": statements that conflict with documents or other witnesses, each pair cited.]

## 6. What the documents show
### 6.1 What was produced
[Table: category · documents · date range · main items · gaps ("not in the production").]
### 6.2 Legal Q&A
[The table from 3.5, trimmed to what matters; the full table attached as legal-qa.csv.]
### 6.3 The engineering record
[Per category: what exists, versions and dates, and the three to five documents that matter most, each with ID. Point at the matching Alpha Devices guide where the team may need background: risk file (guide 04), DHF (guides 03 and 05), software (guide 11), complaints (guide 13), field actions (guide 14), logs (guide 07).]

## 7. Open questions and next requests
[Numbered. Each one: the question, why the record cannot answer it, which document or witness would.]

## 8. Sources
[The index, filtered to the documents cited, with ID, title, date, pages. Then the query log: what was asked of the archive, when, and with which model.]

Citation form, used everywhere: [D-0042 p.7] for a document, [Depo Lastname 112:4–113:2] for a transcript, [D-0042 p.7, D-0051 p.2] for two sources. If a document has a Bates number, use it as the ID instead of D-nnnn.

Attach the tables as files next to the brief: index.csv, timeline-incident.csv, timeline-case.csv, witnesses.csv, legal-qa.csv, query-log.csv.

6. Refreshing a brief

When a new production or deposition arrives, do not rebuild everything. Run the archive step on the new material only (new IDs continue the sequence), re-run the five tables for the new documents, merge, re-verify the rows that changed, and add a section at the top of the brief: "What changed since [date]" — new documents by category, new timeline rows, witness statements that confirm or contradict earlier ones, questions from section 7 now answered. The team reads that section first.

7. Rules that hold throughout

• Originals are never edited. The archive is a copy; the production is the evidence.
• Every statement has a source, and every source was read by you on the cited page.
• The brief states facts and disagreements; it does not state opinions on causation, defect, or liability. Those belong to the expert and to counsel. If the user asks for an opinion inside the brief, put it in a separate, clearly labelled section and say whose opinion it is.
• Names of patients and other private individuals stay as the record has them; do not add personal details from outside the record.
• Confidentiality: work only where the user has put the documents; do not copy case material anywhere else, and say so in the header if the user needs the statement for a protective order.
• Log every query against the archive (question, date, model) in query-log.csv; the method may be asked about in a deposition.
• When something cannot be done (no OCR, a corrupted file, a transcript without line numbers), say so in the brief's header and in the index. A gap stated is useful; a gap hidden is dangerous.