m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Brief content generator: caption-first, expand to full document scaffolding #42

New Issue
Open
opened 2026-05-19 10:43:24 +00:00 by mAi · 0 comments
mAi commented 2026-05-19 10:43:24 +00:00
Collaborator
Copy Link

Why

HLC patent attorneys start every brief (Schriftsatz) from a static Word template (HL Patents Style.dotm). The template gives the visual frame — typography, numbering, ribbon helpers — but not the content layer: the right caption for the chosen court, the right party block in the right language, default phrases that recur in 90 % of briefs of a given type, and the metadata that already lives in the PaLiAd DB (Client, Litigation, Patent, Case, parties, case number, court).

Today every brief begins with re-typing facts PaLiAd already knows. The brief generator removes that step.

Vision

A wizard-driven generator inside PaLiAd. The user picks:

  • Case (from the existing Client → Litigation → Patent → Case hierarchy)
  • Document type (Klage / Klageerwiderung / Replik / Berufungsschrift / Beschwerde / generic brief)
  • Language (DE / EN)
  • Court (UPC LD München / Paris / Düsseldorf / Mannheim / Hamburg / The Hague / Helsinki, UPC CD, BPatG, BGH, OLG, LG)
  • Party role (Klägerin / Beklagte / Beschwerdeführerin / Beschwerdegegnerin)
  • (optional) Signatures, distribution list, exhibits placeholder

…and gets back a ready-to-edit .docx (HL Patents Style typography) with everything PaLiAd already knows filled in:

  • Caption with correct court header + Aktenzeichen + parties (full name + addresses + role)
  • Letterhead reflecting Dezernat + responsible PAs
  • Standard opening phrases per document type + language
  • Empty body section ready for the substantive argument
  • Footer with Anwalt / Ansprechpartner + Zustellungsbevollmächtigte if applicable

MVP — Briefkopf only

First slice ships the caption / Briefkopf for one document type (generic brief, no Klage-spezifika), three courts (UPC LD München, UPC CD Paris, BPatG), both languages. Outputs .docx.

Wizard route: Cases/<id>/new-brief → 3-step form (doc type, court, language) → .docx download.

Demonstrates the full data-pull → render → download pipeline at the smallest surface that still proves the architecture.

Architecture

Pure server-side .docx rendering — no Word required at render time. Master templates with placeholders ({{ court_name }}, {% if language == "de" %}…{% endif %}) live in templates/brief/ in this repo, version-controlled alongside the code.

Candidate engines (decision in a follow-up issue):

  • docxtpl (Python, Jinja2 syntax inside Word docs, MIT) — recommended starting point, isolatable as a small sidecar called from the Go backend
  • docxtemplater (Node.js, mature, license check needed for commercial use)
  • Pure Go OOXML manipulation — more code, less flexible for conditionals/loops, but zero deps

Integration shape: Go handler receives form payload → assembles render context from DB → invokes templater → streams resulting .docx to the browser.

Data model touchpoints

Already in PaLiAd (per project goal: Client → Litigation → Patent → Case):

  • Client (Mandant) — name, address
  • Litigation parties
  • Patent number
  • Case number / Aktenzeichen
  • Responsible team (Dezernat + PAs)

May need to add or extend:

  • Court entity with default judge / address / language preference / formal designation in DE and EN
  • Party role per Case (who is Klägerin / Beklagte / Beschwerdeführerin in this Case)
  • Standard-phrase library per document type + language

Schema additions for any of these get their own follow-up issues; MVP is read-only on the current schema and falls back to manual input for fields not yet captured.

Future scope (not MVP)

  • Full Klage / Klageerwiderung scaffolds with substantive section templates
  • AI-assisted pre-filling of recurring argument blocks (mClone-style, learned from prior HLC briefs)
  • Multi-recipient distribution lists for Zustellung
  • Auto-generation of exhibit numbering + cross-references
  • Export to .dotm with PA-specific BuildingBlocks pre-loaded
  • One-click upload to netDocuments / e-Akte

Open questions

  1. Templating engine choice — Python sidecar (docxtpl) vs Node sidecar (docxtemplater) vs pure Go. Recommend Python for MVP unless someone objects.
  2. Master template authoring — who maintains the placeholder-marked .docx? Likely the same workflow as HL Patents Style: m authors in Word, commits, deploy picks up.
  3. HL Patents Style coexistence — the generated .docx should inherit HL Patents Style typography so subsequent editing in Word feels native. Either embed the styles in the master template or attach the .dotm globally on render.
  4. Court catalogue source-of-truth — do we hard-code the initial 3 + grow, or seed from a structured list (yoUPC data already has UPC LDs / CD)?

Out of scope (this issue)

  • Anything beyond document generation (signing, sending, e-Akte upload)
  • HL Patents Style template changes (lives in HL/mWorkRepo)
  • Hosting / deploy (paliad.msbls.de already serves)

Done when

  • A user with a Case can click New Brief, pick doc type / court / language, and get a .docx with caption + parties + Aktenzeichen + standard letterhead filled in
  • Three courts (UPC LD MUC, UPC CD, BPatG) work end-to-end in both languages
  • Generated .docx opens cleanly in Word and inherits HL Patents Style typography
  • Wizard is reachable from the Case view
## Why HLC patent attorneys start every brief (*Schriftsatz*) from a static Word template (`HL Patents Style.dotm`). The template gives the visual frame — typography, numbering, ribbon helpers — but not the *content* layer: the right caption for the chosen court, the right party block in the right language, default phrases that recur in 90 % of briefs of a given type, and the metadata that **already lives in the PaLiAd DB** (Client, Litigation, Patent, Case, parties, case number, court). Today every brief begins with re-typing facts PaLiAd already knows. The brief generator removes that step. ## Vision A wizard-driven generator inside PaLiAd. The user picks: - **Case** (from the existing Client → Litigation → Patent → Case hierarchy) - **Document type** (Klage / Klageerwiderung / Replik / Berufungsschrift / Beschwerde / generic brief) - **Language** (DE / EN) - **Court** (UPC LD München / Paris / Düsseldorf / Mannheim / Hamburg / The Hague / Helsinki, UPC CD, BPatG, BGH, OLG, LG) - **Party role** (Klägerin / Beklagte / Beschwerdeführerin / Beschwerdegegnerin) - *(optional)* Signatures, distribution list, exhibits placeholder …and gets back a ready-to-edit `.docx` (HL Patents Style typography) with everything PaLiAd already knows filled in: - Caption with correct court header + Aktenzeichen + parties (full name + addresses + role) - Letterhead reflecting Dezernat + responsible PAs - Standard opening phrases per document type + language - Empty body section ready for the substantive argument - Footer with Anwalt / Ansprechpartner + Zustellungsbevollmächtigte if applicable ## MVP — Briefkopf only First slice ships the *caption / Briefkopf* for **one** document type (generic brief, no Klage-spezifika), **three** courts (UPC LD München, UPC CD Paris, BPatG), **both** languages. Outputs `.docx`. Wizard route: `Cases/<id>/new-brief` → 3-step form (doc type, court, language) → `.docx` download. Demonstrates the full *data-pull → render → download* pipeline at the smallest surface that still proves the architecture. ## Architecture Pure server-side `.docx` rendering — no Word required at render time. Master templates with placeholders (`{{ court_name }}`, `{% if language == "de" %}…{% endif %}`) live in `templates/brief/` in this repo, version-controlled alongside the code. Candidate engines (decision in a follow-up issue): - **`docxtpl`** (Python, Jinja2 syntax inside Word docs, MIT) — recommended starting point, isolatable as a small sidecar called from the Go backend - **`docxtemplater`** (Node.js, mature, license check needed for commercial use) - **Pure Go OOXML manipulation** — more code, less flexible for conditionals/loops, but zero deps Integration shape: Go handler receives form payload → assembles render context from DB → invokes templater → streams resulting `.docx` to the browser. ## Data model touchpoints Already in PaLiAd (per project goal: Client → Litigation → Patent → Case): - Client (Mandant) — name, address - Litigation parties - Patent number - Case number / Aktenzeichen - Responsible team (Dezernat + PAs) May need to add or extend: - **Court entity** with default judge / address / language preference / formal designation in DE and EN - **Party role per Case** (who is Klägerin / Beklagte / Beschwerdeführerin in *this* Case) - **Standard-phrase library** per document type + language Schema additions for any of these get their own follow-up issues; MVP is **read-only** on the current schema and falls back to manual input for fields not yet captured. ## Future scope (not MVP) - Full Klage / Klageerwiderung scaffolds with substantive section templates - AI-assisted pre-filling of recurring argument blocks (mClone-style, learned from prior HLC briefs) - Multi-recipient distribution lists for Zustellung - Auto-generation of exhibit numbering + cross-references - Export to `.dotm` with PA-specific BuildingBlocks pre-loaded - One-click upload to netDocuments / e-Akte ## Open questions 1. **Templating engine choice** — Python sidecar (`docxtpl`) vs Node sidecar (`docxtemplater`) vs pure Go. Recommend Python for MVP unless someone objects. 2. **Master template authoring** — who maintains the placeholder-marked `.docx`? Likely the same workflow as HL Patents Style: m authors in Word, commits, deploy picks up. 3. **HL Patents Style coexistence** — the generated `.docx` should inherit HL Patents Style typography so subsequent editing in Word feels native. Either embed the styles in the master template or attach the `.dotm` globally on render. 4. **Court catalogue source-of-truth** — do we hard-code the initial 3 + grow, or seed from a structured list (yoUPC data already has UPC LDs / CD)? ## Out of scope (this issue) - Anything beyond document generation (signing, sending, e-Akte upload) - `HL Patents Style` template changes (lives in HL/mWorkRepo) - Hosting / deploy (paliad.msbls.de already serves) ## Done when - A user with a Case can click *New Brief*, pick doc type / court / language, and get a `.docx` with caption + parties + Aktenzeichen + standard letterhead filled in - Three courts (UPC LD MUC, UPC CD, BPatG) work end-to-end in both languages - Generated `.docx` opens cleanly in Word and inherits HL Patents Style typography - Wizard is reachable from the Case view
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#42
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?