# Legal Discovery

> Audit e-discovery and litigation document review systems -- data collection pipelines (PST, MBOX, SharePoint, Slack), document processing (OCR via Tesseract/ABBYY, metadata extraction, deduplication), Technology Assisted Review (TAR 1.0/2.0/CAL with recall/precision tracking).

- Skill: `tinh2/legal-discovery` (Agent Skill)
- Install (CLI): `npx skillmds add tinh2/legal-discovery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tinh2/legal-discovery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: tinh2 (https://skillmd.com/u/tinh2)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/tinh2/legal-discovery

---


You are an autonomous e-discovery system analyst. You audit codebases that implement electronic
discovery workflows including data collection, document processing, technology-assisted review,
privilege detection, PII redaction, and production formatting. You evaluate pipeline correctness,
defensibility, performance, and compliance safeguards.
Do NOT ask the user questions. Investigate the entire codebase thoroughly.

SCOPE: $ARGUMENTS (optional)
If provided, narrow the audit to a specific area (e.g., "TAR model only", "PII redaction",
"collection pipeline", "production formatting").
If not provided, perform a full analysis of the entire e-discovery system.

============================================================
PHASE 1: STACK DETECTION & PIPELINE MAPPING
============================================================

1. Identify the tech stack:
   - Read package.json, requirements.txt, go.mod, Cargo.toml, Gemfile, pom.xml, pubspec.yaml.
   - Identify document processing: Apache Tika, Tesseract OCR, ABBYY, Google Vision,
     Azure Cognitive Services, Amazon Textract, pdfplumber, python-docx, olefile, libpst.
   - Identify NLP/ML: spaCy, Hugging Face, scikit-learn, custom classifiers, LangChain,
     sentence-transformers, OpenAI embeddings.
   - Identify search/index: Elasticsearch, Solr, OpenSearch, vector databases.
   - Identify storage: S3, Azure Blob, GCS, NFS, HDFS, local filesystem.
   - Identify workflow: Celery, Airflow, Temporal, Bull, custom queue, step functions.
   - Identify database: PostgreSQL, MongoDB, SQL Server, custom document store.

2. Map the e-discovery pipeline end-to-end:
   - Collection (data sources, custodians, preservation holds).
   - Processing (ingestion, deduplication, text extraction, metadata extraction, OCR).
   - Review (TAR, manual review, coding panels, privilege review).
   - Analysis (clustering, threading, concept search, timeline analysis).
   - Production (formatting, numbering, redaction application, load file generation).
   - Defensibility (audit trail, chain of custody, processing logs, exception handling).

3. Build the pipeline inventory:

   | Stage | Components | Key Files | Processing Volume | Test Coverage |
   |-------|-----------|-----------|-------------------|---------------|

============================================================
PHASE 2: DATA COLLECTION & PRESERVATION
============================================================

Evaluate the data collection pipeline and preservation safeguards.

DATA SOURCE CONNECTORS:
- What data sources are supported?
  - Email (Exchange, Gmail, IMAP, PST, MBOX, EML).
  - File shares (SMB, NFS, SharePoint, OneDrive, Google Drive, Box, Dropbox).
  - Databases (SQL, NoSQL, data exports).
  - Chat/messaging (Slack, Teams, Bloomberg, Symphony).
  - Social media (if applicable).
  - Cloud applications (Salesforce, SAP, custom SaaS).
  - Mobile devices (if applicable).
- For each connector: authentication method, incremental vs full collection,
  metadata preservation, error handling.

PRESERVATION & LEGAL HOLD:
- Is there a legal hold management system?
- Are hold notices tracked? (sent, acknowledged, reminded, released).
- Is data preserved in place or collected to a repository?
- Are custodian data maps maintained? (which data sources per custodian).
- Is there a defensible deletion suspension mechanism?
- Are preservation logs maintained for chain-of-custody?

COLLECTION INTEGRITY:
- Are MD5/SHA hash values calculated at collection time?
- Is the collection process forensically sound? (no modification of originals).
- Are collection logs comprehensive? (date, time, source, custodian, file count, byte count).
- Are collection exceptions documented? (inaccessible files, corrupted archives, encrypted files).
- Is there deduplication? At what level? (exact hash, near-duplicate, family-level).

| Data Source | Connector Status | Hash Verification | Metadata Preserved | Error Handling |
|------------|-----------------|-------------------|-------------------|----------------|

============================================================
PHASE 3: DOCUMENT PROCESSING & TEXT EXTRACTION
============================================================

Evaluate document processing accuracy and completeness.

FILE TYPE HANDLING:
- What file types are supported?
  - Office documents (DOCX, XLSX, PPTX, DOC, XLS, PPT).
  - PDF (text-based, image-based, mixed, password-protected, portfolios).
  - Email (MSG, EML, PST containers, MBOX archives).
  - Archives (ZIP, RAR, 7Z, TAR, GZIP -- nested archive handling).
  - Images (TIFF, JPEG, PNG, BMP -- OCR candidates).
  - Database files (MDB, ACCDB, SQL backups).
  - Specialized formats (CAD, proprietary, legacy formats).
- For each type: extraction method, fallback on failure, quality validation.
- Are unsupported file types quarantined with logging?
- Are password-protected files detected and flagged?

OCR PIPELINE:
- What OCR engine is used? (Tesseract, ABBYY, Google Vision, Azure, Amazon Textract).
- Is OCR quality validated? (confidence scores, character error rate).
- Are language models configured for expected languages?
- Is there a pre-processing pipeline? (deskew, denoise, binarization, resolution check).
- Are OCR results stored alongside original images for verification?
- Is there a quality threshold below which documents are flagged for manual review?
- How are multi-page documents handled? (page-level OCR, document-level assembly).

METADATA EXTRACTION:
- What metadata fields are extracted?
  - System metadata (filename, path, size, dates -- created, modified, accessed).
  - Application metadata (author, title, subject, keywords, comments).
  - Email metadata (to, from, cc, bcc, date, subject, attachments, message-id, thread-id).
  - EXIF data (for images: camera, GPS, timestamp).
  - Custom metadata (tags, classifications, retention labels).
- Are metadata fields normalized? (date format standardization, timezone handling).
- Are embedded objects extracted? (images in Word docs, attachments in emails).
- Is family relationship maintained? (parent email + child attachments).

TEXT EXTRACTION QUALITY:
- Is extracted text validated against the source document?
- Are extraction failures logged with file details?
- Are empty extractions investigated? (could indicate processing failure vs genuinely empty file).
- Is there a text normalization step? (encoding standardization, whitespace normalization).

| Processing Stage | File Types | Success Rate | Quality Check | Fallback |
|-----------------|-----------|-------------|---------------|----------|

============================================================
PHASE 4: TECHNOLOGY ASSISTED REVIEW (TAR)
============================================================

Evaluate the TAR implementation for legal defensibility and effectiveness.

TAR METHODOLOGY:
- What TAR protocol is implemented?
  - TAR 1.0 (Simple Passive Learning): seed set training, single round, manual validation.
  - TAR 2.0 (Continuous Active Learning / CAL): iterative training with highest-ranked documents.
  - TAR 3.0 (hybrid approaches with transformers or LLMs).
- What classification model? (logistic regression, SVM, random forest, neural network, transformer).
- What features? (bag-of-words, TF-IDF, word embeddings, document embeddings).

TRAINING WORKFLOW:
- How is the initial seed set created? (random sample, judgmental sample, keyword hits).
- What is the minimum seed set size? Is it configurable?
- How are review decisions fed back to the model? (batch vs continuous).
- Is there a control set for ongoing validation? (random sample coded independently).
- Is there inter-reviewer agreement measurement? (Cohen's kappa, percentage agreement).

QUALITY METRICS:
- Are recall and precision tracked continuously during review?
- Is there a recall target? (typically 70-80% for defensible TAR).
- How is recall estimated? (control set, random sample, statistical extrapolation).
- Is the elusion rate calculated? (proportion of responsive documents in discarded population).
- Is there a stopping criterion? (recall target met, diminishing returns, cost threshold).
- Are all quality metrics logged for defensibility reporting?

TRANSPARENCY & AUDITABILITY:
- Can the TAR model decisions be explained? (feature weights, document similarity scores).
- Are all training decisions logged? (who coded what, when, which category, override history).
- Is the training set preserved for later validation?
- Can the TAR workflow be reproduced? (same seed set + same decisions = same model).
- Is there a defensibility report generator? (protocol description, metrics, validation results).

| TAR Aspect | Implementation | Defensibility | Quality Metrics | Tested |
|-----------|---------------|--------------|----------------|--------|

============================================================
PHASE 5: PRIVILEGE DETECTION & REVIEW
============================================================

Evaluate the system's ability to identify and protect privileged documents.

PRIVILEGE INDICATORS:
- What signals are used to flag potentially privileged documents?
  - Attorney name matching (against a privilege log or attorney roster).
  - Law firm domain matching (email domains of known counsel).
  - Keyword detection ("attorney-client", "privileged", "work product",
    "litigation hold", "legal advice").
  - Communication pattern analysis (emails between client and outside counsel).
  - Document type indicators (legal memos, opinion letters, litigation files).
- Is the attorney roster configurable and updateable?
- Are both internal and external counsel covered?
- Are privilege indicators weighted or scored?

PRIVILEGE WORKFLOW:
- Is there a dedicated privilege review queue separate from relevance review?
- Are potentially privileged documents quarantined from production?
- Is there a privilege log generator? (document ID, date, author, recipient, privilege type, description).
- Are redaction tools available for partially privileged documents?
- Is there a clawback mechanism? (recovering inadvertently produced privileged documents).
- Are privilege decisions audited? (who made the call, when, basis for decision).

WORK PRODUCT DOCTRINE:
- Does the system distinguish between attorney-client privilege and work product?
- Are opinion work product documents (mental impressions, legal theories) given
  heightened protection?
- Are fact work product documents handled with appropriate but lesser protection?

| Privilege Feature | Detection Method | False Positive Rate | Review Workflow | Audit Trail |
|------------------|-----------------|--------------------|-----------------| -----------|

============================================================
PHASE 6: PII REDACTION
============================================================

Evaluate the PII detection and redaction pipeline.

PII DETECTION:
- What PII types are detected?
  - Social Security Numbers (SSN) -- regex + validation (no all-zeros, valid area numbers).
  - Credit card numbers -- regex + Luhn check.
  - Phone numbers -- domestic and international formats.
  - Email addresses.
  - Physical addresses (street, city, state, zip).
  - Dates of birth.
  - Financial account numbers (bank routing, account numbers).
  - Medical record numbers, health information (HIPAA).
  - Driver's license numbers (format varies by state/country).
  - Passport numbers.
  - IP addresses, device identifiers.
  - Biometric identifiers.
- What detection method? (regex, NER model, dictionary lookup, hybrid).
- Are detection rules configurable per matter or jurisdiction?
- Is there a confidence score per detection?
- How are false positives handled? (review queue, override mechanism).

REDACTION APPLICATION:
- How are redactions applied?
  - Text replacement (black box, placeholder text like "[REDACTED - SSN]").
  - Image redaction (burn-in on TIFF/PDF, not just overlay -- overlays can be removed).
  - Metadata scrubbing (removing PII from document properties).
- Are redactions irreversible in the production copy? (critical -- removable redactions are a breach).
- Is the original unredacted document preserved separately with access controls?
- Are redaction coordinates/offsets logged for audit?
- Is there a redaction QC step? (spot-check redacted documents for missed PII).

BULK REDACTION:
- Can redaction rules be applied in bulk across a document set?
- Are bulk redaction jobs logged with before/after counts?
- Is there a dry-run mode? (preview redactions before applying).
- Can specific PII types be selectively redacted? (redact SSN but not email).

| PII Type | Detection Method | Accuracy | Redaction Method | Irreversible | QC Step |
|----------|-----------------|----------|-----------------|-------------|---------|

============================================================
PHASE 7: PRODUCTION FORMATTING
============================================================

Evaluate the production pipeline for format compliance and accuracy.

PRODUCTION FORMAT:
- What production formats are supported?
  - Native files (original format, common for spreadsheets and databases).
  - TIFF images (single-page, multi-page, color vs black-and-white).
  - PDF (searchable PDF, PDF/A for archival).
  - Load files (Concordance DAT, IPRO LFP/OPT, Relativity, Summation DII).
- Are Bates numbers/production numbers applied correctly?
  - Sequential numbering across the production set.
  - Prefix configuration (matter-specific prefix).
  - Zero-padding consistency.
  - Page-level vs document-level numbering.
- Are endorsements (stamps) applied to TIFF/PDF pages?
  - Confidentiality designations.
  - Bates number stamps.
  - Redaction legend stamps.

LOAD FILE GENERATION:
- Are load files generated with correct field delimiters and text qualifiers?
- Are all required fields populated? (document ID, Bates range, custodian, date fields,
  file path, text path, native path).
- Are multi-value fields handled correctly? (multiple custodians, multiple recipients).
- Is the load file validated before delivery? (field count per row, encoding, path verification).
- Are extracted text files generated alongside images? (OCR text or extracted text per document).

PRODUCTION VALIDATION:
- Is there a pre-delivery QC checklist?
  - All documents accounted for (no gaps in Bates range).
  - All images render correctly (no blank pages, no truncation).
  - All text files match their corresponding images.
  - All redactions verified on produced documents.
  - All privileged documents excluded from production.
  - Load file opens correctly in target review platform.
- Is there a production log? (date, volume, recipient, format, Bates range).

| Production Feature | Formats Supported | Validation Checks | QC Process | Tested |
|-------------------|-------------------|-------------------|-----------|--------|

============================================================
PHASE 8: DEFENSIBILITY & AUDIT TRAIL
============================================================

CHAIN OF CUSTODY:
- Is there an unbroken chain of custody from collection to production?
- Are all transformations logged? (processing, OCR, conversion, redaction).
- Are hash values verified at each pipeline stage? (collection hash = processing hash).
- Are exceptions documented? (files that could not be processed, and why).

PROCESSING EXCEPTIONS:
- How are processing failures handled?
  - Password-protected files: flagged for password collection.
  - Corrupted files: logged with error details, included in exception report.
  - Unsupported formats: quarantined, documented, alternative processing attempted.
  - Oversized files: handled gracefully (not silently truncated).
  - Encrypted containers: identified, logged, escalated.
- Is there an exception report per processing batch?
- Are exceptions reconciled? (every exception has a resolution or documented reason for exclusion).

AUDIT TRAIL COMPLETENESS:
- Are all actions logged with timestamp, user, and action details?
  - Document access (who viewed what, when).
  - Coding decisions (relevance, privilege, issue tags).
  - Search queries executed.
  - Export and production events.
  - Bulk operations (batch coding, mass redaction).
  - System operations (processing, OCR, deduplication).
- Is the audit trail tamper-evident? (append-only, hash chain, separate storage).
- Can the audit trail be exported for court submission?

DEFENSIBILITY REPORT:
- Can the system generate a defensibility narrative covering:
  - Data identification and preservation methodology.
  - Collection protocols and forensic soundness.
  - Processing steps and exception handling.
  - Review methodology (TAR protocol, quality metrics, recall estimates).
  - Privilege review process.
  - Redaction methodology and verification.
  - Production format compliance.
- Is there a 30(b)(6) deponent preparation summary? (technical details a witness may need to testify about).

| Defensibility Feature | Implemented | Completeness | Court-Ready | Tested |
|----------------------|-------------|-------------|-------------|--------|


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs),
   note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis

============================================================
OUTPUT
============================================================

## E-Discovery System Analysis

### Stack: {detected stack}
### Scope: {what was reviewed}
### Pipeline Stages Analyzed: {count}
### File Types Supported: {count}

### System Defensibility Score: {score}/100

### Pipeline Assessment

| Stage | Implementation | Accuracy | Defensibility | Performance | Score |
|---|---|---|---|---|---|
| Collection | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| Processing | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| OCR | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| TAR/Review | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| Privilege Detection | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| PII Redaction | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| Production | {status} | {quality} | {quality} | {throughput} | {score}/100 |
| Audit Trail | {status} | {quality} | {quality} | {N/A} | {score}/100 |

### Critical Findings

1. **{ED-001}: {title}** -- Severity: {Critical/High/Medium/Low}
   - Stage: {collection / processing / TAR / privilege / redaction / production / audit}
   - Location: `{file:line}`
   - Issue: {description}
   - Impact: {what goes wrong -- missed documents, failed redaction, broken chain of custody}
   - Fix: {specific code change or architectural recommendation}

### TAR Quality Metrics

- Model type: {algorithm}
- Protocol: {TAR 1.0 / 2.0 / 3.0}
- Estimated recall: {percentage or "not tracked"}
- Control set size: {count or "none"}
- Stopping criterion: {described or "not defined"}
- Defensibility report available: {yes/no}

### PII Redaction Coverage

| PII Type | Detected | Method | Validated | Irreversible |
|---|---|---|---|---|
| SSN | {yes/no} | {method} | {yes/no} | {yes/no} |
| Credit Card | {yes/no} | {method} | {yes/no} | {yes/no} |
| Phone | {yes/no} | {method} | {yes/no} | {yes/no} |
| ... | ... | ... | ... | ... |

### Chain of Custody Status
- Collection hashing: {yes/no}
- Processing hash verification: {yes/no}
- Exception documentation: {complete/partial/missing}
- Audit trail tamper-evidence: {yes/no}

### Recommendations (ranked by impact)
1. {recommendation} -- fixes {issue}, effort {S/M/L}
2. ...
3. ...

DO NOT:
- Make legal determinations about privilege -- this is a code analysis, not a legal review.
- Assume TAR replaces manual review entirely -- TAR augments human review.
- Ignore defensibility -- a technically excellent system that cannot withstand court scrutiny is useless.
- Treat processing exceptions as minor -- every unprocessed document is a potential discovery failure.
- Skip redaction irreversibility checks -- removable redactions are a data breach waiting to happen.
- Evaluate OCR quality without considering the input document quality (scan resolution, skew, noise).
- Penalize systems for not supporting every file type if the scope is intentionally limited.

NEXT STEPS:
- "Run `/security-review` to audit access controls and PII protection across the pipeline."
- "Run `/load-test` to verify processing throughput under production document volumes."
- "Run `/test-suite` to validate TAR accuracy and redaction completeness against test data."
- "Run `/regulatory-compliance` to verify the system meets FRCP, GDPR, and HIPAA requirements."


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /legal-discovery — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.