Case Theory + Auto-drafting

A mid-level associate who doesn't sleep and never complains.

The third and final slice of the Sciolto-flavored legal-services vertical. Where Litigation Flow (slice H) tracks phase + deadlines, and Discovery (slice I) tracks the document universe, Strategy owns the *thinking layer* — atomic facts, structured case theories, template-driven document drafts, sign-locked outputs.

The AI story sits at the swap-in point for narrative sections. This slice ships the deterministic mail-merge scaffolding + defensible workflow. LLM enhancement is a future upgrade at the draft_document boundary — swapping the renderer for one that calls Claude/BYOK doesn't change the tool surface, doesn't change the audit log, doesn't change the sign-lock semantics.

The three views

Drafts — every draft document across every case with review + sign actions. Unresolved placeholders ([[key]] markers) get a warn-pill count per row so an attorney knows what still needs filling before signing.

Case theory — pick a case, see its facts, theories, and drafts inline. Three inline buttons: *+ Fact*, *+ Theory*, *+ Draft*. Draft theories get a *Confirm* button; confirmed theories become the frozen structure for further drafting.

Templates — the installed template library. One-click *Install standard templates* seeds the five basics. Extensible per-tenant.

The workflow

Facts (atomic units) → CaseTheory (structured) → DraftDocument (rendered) → Signed (immutable)

1. Record facts — one CaseFact per event/communication/condition, with source citation (Bates number when it comes from Discovery). Facts are the atomic unit; theories reference them by id.
2. Draft a theory — pick a claim, list the elements to prove, note strengths / weaknesses / risk factors, link supporting facts. Starts in draft.
3. Confirm the theory — attorney validates the structure. Frozen theory drives the drafting engine.
4. Draft a document — pick a template, let case metadata auto-fill, supply extra fills as JSON. Unresolved placeholders surface as [[key]] markers.
5. Review + edit — attorney reads the draft, edits inline if needed. review_draft_document records the review.
6. Sign — signature is the attestation. Signed drafts are immutable — further edits require an addendum, same shape as clinical notes in the safety module.

Every step writes to the audit log. The audit trail lets you defend against a malpractice claim: *"here's exactly which facts drove which theory drove which draft that I signed."*

The template library

Five standard templates ship with the module:

| Template ID | Category | What it covers | |---|---|---| | TMPL-COMPLAINT-FED-CIVIL | pleadings | FRCP 8(a) short-and-plain-statement complaint — parties, jurisdiction, facts, first claim, prayer | | TMPL-ANSWER-FED-CIVIL | pleadings | FRCP 8(b) responsive pleading — admits/denies + first affirmative defense | | TMPL-MEET-CONFER | correspondence | FRCP 26(f) meet-and-confer letter with agenda | | TMPL-INTERROGATORIES-1 | discovery | Ten-question opening interrogatory set — identification, chronology, communications, damages | | TMPL-DEPO-OUTLINE | discovery | Deposition prep outline with background / chronology / documents / theory-specific / lockdown |

Templates use {{placeholder}} substitution. Missing keys surface as [[key]] in the rendered output — the attorney sees exactly what still needs filling before signing.

Additional templates get added per-tenant via direct DocumentTemplate entity writes (or a future admin form). The library is designed for one-template-at-a-time expansion — no framework to fight.

Sign-lock semantics

Signed drafts are immutable. review_draft_document and sign_draft_document both refuse a second call on a signed record with draft already signed; further edits require an addendum. This mirrors:

• Clinical notes (sign_clinical_note — safety module, healthcare vertical)
• Radiology reports (sign_radiology_report — radiology module)
• Legal matter litigation holds (once triggered, only releasable via a distinct tool)

The shape is deliberate: the audit log needs a stable "as-signed" version. If a document could be silently edited after signing, the log would lie about what was signed at what time. Addenda are separate records with their own timestamps.

What's wired

| Entity | Purpose | |---|---| | CaseFact | Atomic fact with source citation + tags | | CaseTheory | Structured claim → elements → facts + strengths / weaknesses / risk | | DocumentTemplate | The template library, seeded per-tenant | | DraftDocument | Rendered draft with lifecycle (draft → reviewed → signed) |

Tools (11): list_case_facts, record_case_fact, list_case_theories, record_case_theory, confirm_case_theory, list_document_templates, seed_standard_templates, draft_document, list_draft_documents, review_draft_document, sign_draft_document.

The AI-enhancement boundary

The current draft_document handler is a pure mail-merge:

render = template_body with {{key}} → fills[key] substituted

A future upgrade slices in an LLM narrative-section generator without changing the tool signature or the audit log shape:

render = template_body with:
   {{key}} substitutions (fills-supplied) +
   LLM-filled narrative sections (marked, human-reviewed) +
   [[key]] markers for whatever remains unresolved

The LLM call gets:

• The template
• The case metadata (LitigationCase fields)
• The confirmed CaseTheory (structure to argue)
• The linked CaseFacts (the underlying record)
• The user's per-template fills

And returns narrative-only fills that the attorney *reviews before signing*. The sign-lock is the safety net: if the LLM hallucinates, the attorney catches it at review time. No LLM output ever bypasses human review — same posture as the radiology critical-finding scanner and the legal hygiene pattern generator.

What's NOT in this slice

• The LLM narrative filler itself — the deterministic scaffolding ships now; the LLM call is a future upgrade at the draft_document boundary.
• Persona D (pro se) draft output — attorney-only. UPL exposure was flagged in the underlying Sciolto plan, and this vertical honors that scope.
• Rich-text formatting / DOCX export — draft body is plain text. A serializer to PDF/DOCX is a distinct concern, well-defined boundary, later slice.
• Cross-case template evolution — templates are static per-tenant. A "learn from what an attorney edited after render" loop is deep future work.

The load-bearing story in this slice is the *workflow discipline*: facts → theory → confirmed theory → rendered draft → reviewed → signed → immutable. The AI story goes on top of that workflow. Get the workflow right first.