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

Document filename generator + folder-scaffold zip export (DMS / netDocuments) #145

New Issue
Open
opened 2026-05-26 19:09:27 +00:00 by mAi · 0 comments
mAi commented 2026-05-26 19:09:27 +00:00
Collaborator
Copy Link

Idea

For every procedural event and its associated deadline, paliad knows enough to propose a filename for the document(s) that belong to it — and stitch those filenames into a folder structure that can be exported as a .zip to scaffold a case file in HLC's DMS (netDocuments).

Filename schema

<YYYY-MM-DD>_<Issuer>_<Content>_<DocketNumber>.<ext>

Components:

Slot Source Examples
<YYYY-MM-DD> event date (filing date, service date, court date) 2026-05-26
<Issuer> who issued the document — court, party, or office UPC, LG-Duesseldorf, OpponentXY-GmbH, EPA, DPMA, Plaintiff, Defendant-1
<Content> document content / Schriftsatz-Typ Klageschrift, Klageerwiderung, Berufungsbegruendung, Anlagenkonvolut, Versaeumnisurteil, Hinweisbeschluss
<DocketNumber> docket identifier of the proceedings — the more-or-less-unique anchor UPC_CFI_120-2024, 4a-O-12-25 (LG D'dorf), EP1234567B1, 21W12345.6 (DPMA)

Docket-number is the anchor that survives a merge into netDocuments — if a colleague pulls 50 files into a folder, the docket suffix groups everything from the same proceedings. Period as separator between date components, underscore between slots, hyphen inside multi-token slots; ASCII only (Umlaute → ae/oe/ue/ss) because netDocuments and Outlook attachment surfaces are still hostile to non-ASCII filenames.

Zip-export shape

The export bundles a project's documents into a folder tree that matches netDocuments' expected layout. Strawman:

<DocketNumber>/
  01_Klageschrift/
    2025-03-15_Plaintiff_Klageschrift_<Docket>.pdf
    2025-03-15_Plaintiff_Anlagenkonvolut-K1_<Docket>.pdf
    ...
  02_Klageerwiderung/
    2025-06-15_Defendant-1_Klageerwiderung_<Docket>.pdf
    ...
  03_Replik/
  04_Termin/
  99_Court-Orders/
    2025-09-01_UPC_Hinweisbeschluss_<Docket>.pdf

Folder ordering follows the project's procedural_events.sequence_order (the same field that powers the Verfahrensablauf view). Each folder name is the phase / event-group label; each file inside follows the filename schema above.

Open design questions (for an inventor pass)

  1. Issuer taxonomy — do we add a new issuer field on procedural_events / deadlines, or derive from primary_party + the proceeding-type's court? Multi-party cases (multiple opponents, multiple defendants) need an explicit-party-pick at file-generation time.
  2. Content taxonomy — is procedural_events.name_de good enough, or do we need a separate document_kind controlled vocabulary so filenames stay consistent across cases? (E.g. "Klageerwiderung" vs "Erwiderung auf die Klage" — both exist in the wild.)
  3. Docket number storage — where does the proceedings-level docket live in the project hierarchy (Client → Litigation → Patent → Case)? Per project_type? Per court?
  4. One event → many documents — court orders, party submissions, and party annexes can all hang off the same event. Need a documents table (1-event-to-N-documents)? Or stay implicit and let the user pick when generating filenames?
  5. Filename preview UX — where does this live in the UI? Per-event flyout? Per-project export button? Both?
  6. netDocuments specifics — any naming-length, character, or folder-depth limits we need to encode in the slugifier?
  7. Round-trip — does paliad just emit names, or does it later ingest the actual PDFs that came back from netDocuments and link them back to events?

Why this matters

File-naming is the single most consistent source of friction for litigation PAs. Today everyone invents their own scheme; collisions and missing docket suffixes mean files drift into the wrong netDocuments folder and become un-findable. Paliad already has all the structured inputs to generate canonical names — making them downloadable as a scaffold is the smallest viable step toward owning the DMS interface from paliad.

Scope notes

  • Side-feature — file when an inventor slot opens. Not blocking any active slice.
  • Phase 0: design doc + filename-schema spec + storyboarding the export UI.
  • Phase 1: per-event filename preview (read-only, copy-to-clipboard).
  • Phase 2: project-level zip export with the folder tree.
  • Phase 3 (later): netDocuments API integration / re-ingest.

Acceptance criteria for the inventor design pass

  • Filename schema fully specified including slugifier rules (Umlaute, separators, max length).
  • Folder layout specified including how event-groups become folder-level groupings (which sequence_order ranges or event_kind buckets become folders).
  • Storage decisions for issuer + docket-number + (optionally) document_kind nailed down (where in the schema they live).
  • Migration sketched (only DDL needed, no code).
  • Export endpoint shape specified (GET /projects/<id>/documents.zip? Streamed? Cached?).
  • One concrete worked example: a synthetic UPC infringement case with 6 events → exact resulting zip tree + filenames.

Out of scope

  • Actual PDF generation or templating (filenames only, files are external).
  • netDocuments API calls (Phase 3).
  • Multi-language filenames (DE-only for now; EN tracked separately if HL-London wants it).
## Idea For every procedural event and its associated deadline, paliad knows enough to **propose a filename** for the document(s) that belong to it — and stitch those filenames into a **folder structure** that can be exported as a `.zip` to scaffold a case file in HLC's DMS (netDocuments). ## Filename schema ``` <YYYY-MM-DD>_<Issuer>_<Content>_<DocketNumber>.<ext> ``` Components: | Slot | Source | Examples | |---|---|---| | `<YYYY-MM-DD>` | event date (filing date, service date, court date) | `2026-05-26` | | `<Issuer>` | who issued the document — court, party, or office | `UPC`, `LG-Duesseldorf`, `OpponentXY-GmbH`, `EPA`, `DPMA`, `Plaintiff`, `Defendant-1` | | `<Content>` | document content / Schriftsatz-Typ | `Klageschrift`, `Klageerwiderung`, `Berufungsbegruendung`, `Anlagenkonvolut`, `Versaeumnisurteil`, `Hinweisbeschluss` | | `<DocketNumber>` | docket identifier of the proceedings — the more-or-less-unique anchor | `UPC_CFI_120-2024`, `4a-O-12-25` (LG D'dorf), `EP1234567B1`, `21W12345.6` (DPMA) | Docket-number is the anchor that survives a merge into netDocuments — if a colleague pulls 50 files into a folder, the docket suffix groups everything from the same proceedings. Period as separator between date components, underscore between slots, hyphen inside multi-token slots; ASCII only (Umlaute → ae/oe/ue/ss) because netDocuments and Outlook attachment surfaces are still hostile to non-ASCII filenames. ## Zip-export shape The export bundles a project's documents into a folder tree that matches netDocuments' expected layout. Strawman: ``` <DocketNumber>/ 01_Klageschrift/ 2025-03-15_Plaintiff_Klageschrift_<Docket>.pdf 2025-03-15_Plaintiff_Anlagenkonvolut-K1_<Docket>.pdf ... 02_Klageerwiderung/ 2025-06-15_Defendant-1_Klageerwiderung_<Docket>.pdf ... 03_Replik/ 04_Termin/ 99_Court-Orders/ 2025-09-01_UPC_Hinweisbeschluss_<Docket>.pdf ``` Folder ordering follows the project's `procedural_events.sequence_order` (the same field that powers the Verfahrensablauf view). Each folder name is the phase / event-group label; each file inside follows the filename schema above. ## Open design questions (for an inventor pass) 1. **Issuer taxonomy** — do we add a new `issuer` field on `procedural_events` / `deadlines`, or derive from `primary_party` + the proceeding-type's court? Multi-party cases (multiple opponents, multiple defendants) need an explicit-party-pick at file-generation time. 2. **Content taxonomy** — is `procedural_events.name_de` good enough, or do we need a separate `document_kind` controlled vocabulary so filenames stay consistent across cases? (E.g. "Klageerwiderung" vs "Erwiderung auf die Klage" — both exist in the wild.) 3. **Docket number storage** — where does the proceedings-level docket live in the project hierarchy (Client → Litigation → Patent → Case)? Per project_type? Per court? 4. **One event → many documents** — court orders, party submissions, and party annexes can all hang off the same event. Need a `documents` table (1-event-to-N-documents)? Or stay implicit and let the user pick when generating filenames? 5. **Filename preview UX** — where does this live in the UI? Per-event flyout? Per-project export button? Both? 6. **netDocuments specifics** — any naming-length, character, or folder-depth limits we need to encode in the slugifier? 7. **Round-trip** — does paliad just emit names, or does it later ingest the actual PDFs that came back from netDocuments and link them back to events? ## Why this matters File-naming is the single most consistent source of friction for litigation PAs. Today everyone invents their own scheme; collisions and missing docket suffixes mean files drift into the wrong netDocuments folder and become un-findable. Paliad already has all the structured inputs to generate canonical names — making them downloadable as a scaffold is the smallest viable step toward owning the DMS interface from paliad. ## Scope notes - Side-feature — file when an inventor slot opens. Not blocking any active slice. - Phase 0: design doc + filename-schema spec + storyboarding the export UI. - Phase 1: per-event filename preview (read-only, copy-to-clipboard). - Phase 2: project-level zip export with the folder tree. - Phase 3 (later): netDocuments API integration / re-ingest. ## Acceptance criteria for the inventor design pass - Filename schema fully specified including slugifier rules (Umlaute, separators, max length). - Folder layout specified including how event-groups become folder-level groupings (which `sequence_order` ranges or `event_kind` buckets become folders). - Storage decisions for issuer + docket-number + (optionally) document_kind nailed down (where in the schema they live). - Migration sketched (only DDL needed, no code). - Export endpoint shape specified (`GET /projects/<id>/documents.zip`? Streamed? Cached?). - One concrete worked example: a synthetic UPC infringement case with 6 events → exact resulting zip tree + filenames. ## Out of scope - Actual PDF generation or templating (filenames only, files are external). - netDocuments API calls (Phase 3). - Multi-language filenames (DE-only for now; EN tracked separately if HL-London wants it).
mAi self-assigned this 2026-05-26 19:09:27 +00:00
mAi added the
deferred
 label 2026-05-26 19:09:46 +00:00
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
deferred
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#145
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?