--- feature_id: FTR-37 title: Legal Discovery Tracking category: Legal optional: true depends_on: FTR-36 source: Not from Project_Kickoff_Seed_Prompt_v2.3.md — supplied directly by the user, drafted from real production testing in the Chambers v Chambers project against real discovery data (102 + 95 items across two rounds). No corresponding item in Bootstrap_Function_Registry.md. See coverage_report.md Section 10. registry_refs: [] --- # Legal Discovery Tracking Depends on: [FTR-36 — Excel Tracker (Base Capability)](../items/excel-tracker-base-capability.md) ## What this is Governs how discovery items (Interrogatories, Requests for Production, Requests for Admission) are tracked once they exist in some source form (served document, drafted set, markdown strategy file). This is specifically the tracking layer — one deterministic row per question, with status, response, and outcome fields the user can filter, sort, and check off. It is not the drafting layer and not the strategy layer; those stay in markdown, per the division of labor below. **The core division of labor:** markdown (strategy documents) holds reasoning that changes and needs prose — why a cluster of questions exists, what evidence anchors it, what legal theory it supports. Excel (the tracker) holds the deterministic, versioned record of the questions themselves — exact numbering, exact text, status, outcome. The two are linked, not merged: every row has a `Strategy Group` field and a `Strategy Doc Reference` field naming the specific markdown file that explains that group's reasoning — the Excel tracker never duplicates strategy prose into a cell, it points to it. ## Assess first - Confirm FTR-36 (Excel Tracker Base Capability) is installed — this feature nests under it, not beside it, per FTR-36's own merge-behavior rule. - Confirm the jurisdiction. This feature's schema, counting rules, and statutory citations are Georgia-specific (O.C.G.A. and Uniform Superior Court Rules) — a different jurisdiction's civil procedure code must be checked independently before assuming any of this transfers. ## Ask, only if needed - If the project's Document ID / file-naming convention for discovery rounds isn't already established: ask what round-naming pattern to use (e.g., `DISC-01`, `Round-01`) rather than inventing one. - If it's not clear whether the project's discovery rounds predate cluster-based strategy organization: ask before leaving `Strategy Group` blank on existing rows — don't assume. ## Write ### Schema — one row per question Building on FTR-36's general row-per-item model, columns for a legal discovery tracker: | Column | Purpose | Notes | |---|---|---| | `ID` | Unique identifier, e.g. `-INT-1`, `-RFA-27`, or `-RFP-29-a` for a lettered RFP subpart | Pattern: `--` normally, `---` only for lettered RFP subpart rows. Type codes: INT, RFP, RFA. | | `Discovery Set` | Which round | Match the project's existing round-naming convention, don't invent a parallel one. | | `Type` | Interrogatory / RFP / RFA | Full word, not the short code. | | `Number` | The raw item number as served/drafted | Preserve as-is, never renormalize. A separately-numbered inserted item (e.g. 14A) is a different Number entirely, NOT the same as a lettered subpart of one item. | | `Subpart` | RFPs only — the lettered subpart (a, b, c...) | Blank for no subparts. Each lettered RFP subpart gets its own fully independent row (own Status, Response, Objection Status). Always blank for Interrogatories and RFAs. | | `Subpart Count` | Primarily Interrogatories — count of cap-countable units | 1 for no subparts. For an Interrogatory with lettered subparts, the count of those subparts — the row is NOT split, this is the only place the count is captured for cap math. Always 1 for RFPs/RFAs. | | `Strategy Group` | Cluster identifier, e.g. J, Cluster A | Must match a real group in the linked strategy doc. | | `Strategy Doc Reference` | Filename of the markdown strategy doc explaining this group | Never paste strategy prose here — reference only. If a QR (Targeted Question Research) doc exists for this specific question, reference that first; otherwise reference the Master Strategy doc. | | `Question Text` | The exact question as served or drafted | Verbatim, never paraphrased. | | `Status` | Tracking state | Dropdown: Not Started, Drafted, Vetted, Finalized, Served. | | `Committed` | Locked in, independent of pipeline position | Yes/No. Distinct from Status — a question can be Drafted but not Committed, or Committed while still Status: Drafted. | | `Response` | The actual answer, either party's | Free text; may summarize with a pointer to a full drafted response doc for length. | | `Outcome` | For RFAs/contested items | Dropdown: Admitted, Denied, Denied-Contested, N/A-Objection, No Response, Deemed Admitted. Blank for Interrogatories/RFPs. | | `Response Acceptable` | Judgment on whether the response is proper/complete | Dropdown: Yes, No, Not Yet Applicable. Distinct from Outcome — an RFA can be Admitted yet Response Acceptable: No if improperly qualified. | | `Objection Status` | Whether an objection has been raised, by whom | Dropdown: None, Objected — Ours, Objected — Theirs, Objection Resolved. | | `Waiver Status` | Whether the right to object has been lost through inaction | Dropdown: N/A, At Risk, Waived — Deadline Missed, Waived — No Objection Raised. Missing the response deadline waives ALL objections including privilege — the single most consequential procedural fact in discovery response management. | | `Verified/Sworn` | Whether an interrogatory answer was sworn/notarized | Dropdown: N/A (RFP), Yes, No — Deficient. An unsworn interrogatory answer is treated in Georgia practice as no answer at all, not a technical defect. | | `Follow-Up ID` | Points to a new row created as a direct follow-up | Rows are never deleted or mutated into a different question — a follow-up is always a NEW row, linked back via this field. | | `Escalation Status` | Procedural escalation state for a deficient/missing response | Dropdown: None, Deficiency Letter Sent, Notice of Discovery Dispute Filed, Motion to Compel Filed, Compelled — Order Entered. | ### Nomenclature — naming discovery rounds A round's name must state which party propounded it, its sequence, and (for our outbound rounds) that it's ours. Our own outbound rounds: name plainly by sequence (`Round-01`, or a project's own short code like `DISC-01`). The other party's inbound rounds: explicit `INBOUND` marker plus sequence (`-INBOUND-01`). Track the other party's round count independently — their round 1 and our round 1 are unrelated sequences that happen to share a number. Never name a round or folder using only physical mail direction. ### Folder structure — one folder per party, containing that party's questions AND the answers to them The organizing principle is `whose questions are these`, not `which direction did this arrive from`. An answer to OUR questions belongs in OUR folder even though it physically arrived from the other party, since it's the answer half of our own round. Structure: ``` Discovery Root\ |-- Our Party\ | |-- Round-01\ | | |-- final\ - finalized version served (or draft\ if not yet served) | | |-- filed\ - actual served\court copy plus certificate of service | | |-- responses\ - OTHER party's answers to OUR round-01 (belongs here, not their folder) | |-- strategy\ - research\strategy shaping OUR questions and analyzing THEIR answers | |-- Party_Discovery_Tracker.md |-- Other Party\ | |-- Round-INBOUND-01\ | | |-- requests\ - documents THEY served on us | | |-- responses\ - OUR answers to THEIR questions (belongs here, not our folder) | |-- strategy\ - research shaping OUR answers to THEIR questions |-- strategy\ - ONLY genuinely direction-neutral research; most belongs in a party folder ``` Test to apply: ask `whose question does this answer or analyze`, not `whose name is on the email`. The Excel tracker for a party's own discovery lives in that party's folder, same level as (not nested inside) round subfolders, alongside the markdown narrative tracker. The `_backup` folder (per FTR-36) sits beside the Excel tracker at that level. ### Strategy folder taxonomy — seven categories The organizing test: does this document generate or support the strategy, or is it the strategy itself? Exactly one document per party is `the strategy itself` (Master Strategy). Everything else is research that feeds it. All seven categories live flat in `strategy` — no subfolder split, since the naming convention already encodes the category in the filename prefix. | Category | Code | What it does | |---|---|---| | Master Strategy | MS | The single document covering all clusters/groups and expected-answer paths for the round(s) as a whole | | Playbook | PB | General procedural mechanics not tied to any specific question | | Response Analysis | RA | Question-by-question scrutiny of answers actually received | | Gap/Opportunity Worksheet | GA | Evidence-driven scan generating new proposed questions not yet asked | | Single-Issue Deep-Dive | IA | Focused analysis of one specific fact pattern, narrower than the master strategy | | Anticipated-Response Matrix | RM | Per-question expected-clean-answer vs. red-flag-deficiency table | | Targeted Question Research | QR | One-off research tied to one specific question, narrower than any other category | **Naming pattern:** `-_[_].`. MS carries no sequence number (exactly one per party, edited in place). Every other category uses a two-digit sequence assigned in creation order within its category, per party. No embedded dates — the filesystem timestamp and `_backup` history already carry that. QR items carry one additional requirement: the filename or a header field must name the specific question(s) the research is tied to, not just a topic (e.g. `..._re_RFA-52.md`, not a bare topic title). **On installation, write a README.md to each party's strategy folder** explaining this taxonomy, naming pattern, and the counting rules below, so they're looked up rather than re-derived each session. This README is written once and is not duplicated into Agent Instructions beyond an enforcement rule and a pointer to it. ### Discovery counting rules | Type | Numeric cap | Subpart treatment | |---|---|---| | Interrogatory | Yes — 50 per party, cumulative across every round, including subparts | Tracked via `Subpart Count` on ONE row per interrogatory — never split into multiple rows, since the governing statute's objection mechanism operates at the whole-interrogatory level. | | RFP | No numeric cap | Each lettered subpart CAN be independently objected to and gets its OWN row, since the statute requires specifying which part is objected to. | | RFA | No numeric cap | One row per numbered admission. A partial/qualified answer stays free text in the response field — it doesn't split the RFA into multiple rows. | Only Interrogatories have a cap and need real subpart counting. These specific numbers and citations are Georgia's rules — a different jurisdiction must be checked independently before assuming any of this transfers. ### Strategy document backup The Master Strategy document is backed up before every edit, using the identical mechanism FTR-36 specifies for the Excel tracker — PowerShell `Copy-Item` to a `strategy\_backup` folder, timestamped, verified non-zero, bundled into the same script as the edit. Applies specifically to the one Master Strategy document per party, not every file in `strategy` — research documents are typically static once written. ### Accompanying reference package — Georgia_Discovery_Process_-_Statutes_and_Guide.zip This feature ships with a downloadable reference package, separate from this spec document: a general-purpose (non-case-specific), Georgia-jurisdiction bundle of the governing statutes and a practical counting/objection guide. On installation, this package should be: 1. Downloaded from the feature site alongside this spec. 2. Unzipped into the host project's research/reference location as its own top-level folder, `Georgia_Discovery_Process_-_Statutes_and_Guide\` — not merged file-by-file into an existing structure. 3. Referenced from the project's Agent Instructions or CLAUDE.md as a pointer only (path plus one-line purpose) — never re-summarized or duplicated into the instructions themselves. Contents: `01_Statutes\` (20 verbatim Georgia and federal statutes covering discovery mechanics, evidence/privacy law, and privilege/confidentiality); `02_Guides\` (a three-part practice guide covering discovery tools and cap-counting, objection/verification/waiver, and the escalation pipeline); `README.md` (top-level index). Jurisdiction scope is Georgia only, stated explicitly throughout the package. Download: [data/items/georgia-discovery-process-statutes-and-guide.zip](data/items/georgia-discovery-process-statutes-and-guide.zip) ## What this doesn't cover - The base Excel access method, backup mechanics, and verification discipline — see FTR-36. - The project-cache sidecar mechanism for a legal discovery tracker — FTR-36's sidecar section applies as-is, without legal-specific variation. - Court-formatting or filing conventions for the underlying discovery documents (captions, certificates of service, verification blocks) — remains governed by whatever brand/formatting spec and legal research the host project already maintains. - Automated parsing of a new discovery document straight into tracker rows — a reasonable future extension, not yet specified. ## Confirm Confirm: Legal Discovery Tracking is installed, nested under FTR-36's EXCEL TRACKER section — schema, nomenclature, folder structure, and strategy taxonomy are in place, and the Georgia_Discovery_Process_-_Statutes_and_Guide reference package is unzipped into the project's research location and pointed to from Agent Instructions. Want to install another, or is that everything for now?