The application decomposes initial-response preparation into dependent stages. Page-level extraction supplies case context; a planner defines the response; specialist writing and fixed content produce sections; audit, polish and assembly produce a draft with findings. The attorney workspace makes the resulting material available for review and editing. The design's central boundary is the distinction between preparing legal text and deciding that it is suitable to use.
A client-operated application that turns a claim file into a reviewable first-draft response for an attorney. This study explains its extraction, planning, research, drafting and review stages.
01 / The problem
A document can be complete and still need legal work
The input pairs the claim with supporting evidence. Extraction must preserve enough context for the planner to distinguish what the claimant alleges, what the record shows and which issues require a response. Weak or corrupt page text can distort every stage that follows.
The planner is specialized for one jurisdiction's labor and workplace-risk insurance matters. It identifies the case type, proposes a strategy and selects applicable exceptions within a configured taxonomy. Those instructions bound the drafting task.
02 / Inside the system
Carry case context through an inspectable sequence
A Next.js and TypeScript attorney surface connects to a Python and FastAPI backend. A job moves through extraction, planning, section generation, audit and polish, then assembly. Server-sent events show progress with a polling fallback. Run artifacts store the structured extraction, plan, section text, research results and findings.
Page extraction records text, page references, character counts and quality flags. The planner consumes structured case material and searches a configured legal vector store. It persists a plan whose section records define purpose, research needs, citation requirements, length guidance and content type. The section registry distinguishes authored, template, verbatim and deterministic content.
- Attorney workspace
- Next.js and TypeScript intake, progress, editor, history and document access.
- Workflow service
- Python and FastAPI coordinate structured extraction, planning, specialist writing, audit, polish and assembly.
- Research and artifacts
- Configured vector-store retrieval supplies candidate authorities; persisted run artifacts store plans, sections, research results and findings.
03 / Inside the system
Specialize the writing without losing the shared case
The plan precedes section writing. Eligible authored sections fan out under a concurrency limit, while template and deterministic sections follow their own content contracts. The orchestration can combine denials and the factual account in one writing job. It generates the evidence section after relevant earlier sections, using their text as context. Parallel work therefore sits inside a sequence with explicit dependencies.
Research uses a configured file-search store and keeps file identifiers, snippets and section-level search results. Writers also parse a generated sources block. Retrieval supplies candidate support, and the lawyer verifies that each citation supports its argument. A zero-hit citation abort is configurable and is off by default.
The audit contract describes section findings, severity and insert, delete or replace operations anchored to existing text. Audit and polish precede assembly, and attorney review follows. The targeted-rewrite path records history and status and appends metadata to the section.
A worked example
A workplace-accident claim becomes a review draft
Example with invented data.
01 / IntakeCollect the claim and supporting record
A claim alleges a workplace accident. The lawyer supplies the claim and supporting evidence. Page extraction produces text and quality flags. A weak page signals that the extracted account needs inspection against the original document.
02 / PlanSet the structure and research needs
The planner classifies the case, proposes a response strategy and selects sections under the registry. In this example, no exception is selected. Research tasks and citation requirements accompany the authored sections; the lawyer evaluates the proposed strategy.
03 / DraftWrite coordinated sections
Specialists use the plan and retrieved material. Eligible sections run concurrently; the denials and factual account may share a job. The evidence section follows relevant earlier text, while fixed content comes from its defined contract.
04 / InspectAssemble a draft with findings
Audit and polish feed assembly. Suppose one section lacks recorded search support. The application flags it, and a strict gate, when configured, stops the run. The gate is off by default, so the output continues with the flag attached. The lawyer resolves the flag before using the draft.
05 / ReviewSettle facts, sources and wording
The lawyer compares the draft with the original file, examines each authority and edits the response. Manual workflow actions record review state.
04 / Inside the system
Separate the decisions that need different checks
A dedicated response application narrows the professional task. A shared plan coordinates generation before individual writers begin. Content types preserve the distinction between fixed wording and model-authored analysis. These choices make it possible to examine the structure and the substance separately.
Assembly preserves the draft and publishes readiness findings, so unresolved material stays visible: an output file can exist while readiness is blocked. The editor and manual review actions form the attorney's workflow.
- Decision 01
Plan before section generation
Persist one case-specific plan and use it to coordinate authored sections.
Section purpose and research needs stay connected to a common case account.
Trade-off. The plan can propagate a mistaken extraction or strategy across the draft.
- Decision 02
Give each content type its own contract
Separate authored sections from template, verbatim and deterministic content; respect dependent writing stages.
Fixed wording and generated analysis need different production and review checks.
Trade-off. Registry rules and section dependencies add coordination work and require content verification.
- Decision 03
Keep output and readiness separate
Preserve assembled text with findings and expose it to an attorney workspace.
Unresolved material remains available for professional inspection.
Trade-off. An output file can look final while readiness is blocked, so the attorney confirms readiness.
05 / Inside the system
Evaluate the legal support, then the professional handoff
Automated tests cover the software contracts: anchored audit operations, missing-section findings and review-state behavior.
The evaluation helper measures document structure, length and citation-string presence. A substantive assessment uses lawyer-scored cases that compare extracted facts with the original record, arguments with their supporting authorities, jurisdiction and date suitability, and the corrections required before use.
- What does a retrieved source tell the lawyer?
- That material was found. The lawyer checks whether it supports the proposition and applies in the relevant place and period.
- Does every section run in parallel?
- No. Planning precedes writing, the evidence section consumes earlier text, and fixed sections use their own content contracts.
- Is a completed draft an approved draft?
- No. Findings and readiness can stay open even when an assembled document exists. The attorney decides whether the response is ready to use.
- How does the application handle citations?
- Writers return a sources block that the application parses. Research results keep the file identifiers and snippets from search, and the lawyer verifies each authority.
06 / Inside the system
Connect legal practice, application engineering and operation
Embedding Labs connected the professional preparation task to the application workflow. Human engineering contributors and scoped coding-agent workstreams supported implementation. The runtime specialists have a different role: extract, plan, research, draft and review within the application.
Lawyers supply the case context and settle legal use; the client's operating team runs the system. The handoff brings together a coherent draft, visible findings and a review surface.
The people around the workflow.
- Attorneys
- Provide case material, assess facts and sources, edit the response and determine legal use.
- Client operating team
- Host and operate the internal application.
- Embedding Labs and engineering contributors
- Frame the focused application, connect its stages and integrate the professional review surface.
The design principle
Make the preparation inspectable and keep professional acceptance distinct from automated completion.