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

Data model: 'rules' conflate legal norms + procedural events — explore submission/procedural-event-first model (inventor) #93

New Issue
Open
opened 2026-05-25 13:04:01 +00:00 by mAi · 1 comment
mAi commented 2026-05-25 13:04:01 +00:00
Collaborator
Copy Link

m's report (2026-05-25 15:02)

While looking at a Rechtsbeschwerdebegründung in the editor sidebar:

Submission                Submission
Rechtsbeschwerdebegründung   {{rule.name}}
Legal source                § 102 PatG              {{rule.legal_source_pretty}}
Primary party               both                    {{rule.primary_party}}
Event type                  filing                  {{rule.event_type}}
Submission code             dpma.appeal.bgh.begruendung  {{rule.submission_code}}

This shows how our 'rule' table system may need a revision?! It feels like we are rule based not submission based. But here we have a specific submission that is connected to a rule (as in: legal norm). And of course also connected to other 'procedural events' (which is a good term for it all) by rules how they are sequenced. But it makes it sound weird in the fields...

The observation

paliad.deadline_rules today conflates three distinct concepts into one row:

  1. The procedural event — "Rechtsbeschwerdebegründung" (the thing that happens / gets filed). m proposes procedural event as the umbrella term covering filings, oral hearings, decisions, replies, etc.
  2. The legal norm anchoring it — "§ 102 PatG" / "UPC RoP R.220(1)" (the source-of-law citation).
  3. The sequencing rule — the period ("+2 months"), the trigger event, the party role, the dependency on other procedural events.

Mixing these forces awkward field labels ({{rule.submission_code}} for what's really a procedural-event identifier; {{rule.event_type}} for the procedural-event type) and confuses the mental model.

Phase: inventor design (READ-ONLY)

Inventor → coder gate per project CLAUDE.md.

Open design questions

Q1 — Scope: relabel vs restructure

A. Cosmetic / relabel only: rename {{rule.X}} placeholders + UI field labels to use "submission" / "procedural event" wording. Keep the underlying deadline_rules table shape. ~1 coder shift.
B. Restructure: introduce a paliad.procedural_events table as the primary entity; demote sequencing rules to a sequencing_rules table linking procedural events; demote legal sources to a join. Migration + service-layer + UI refactor.
C. Mixed: rename in code + UI now, plan B as a follow-up that requires its own migration window.

(R) = C: name the entities right immediately (refactor rule.X → procedural_event.X in placeholders + UI labels; keep DB shape); design B in detail with a clear migration plan but DON'T ship it in this slice. The cosmetic win is immediate; the structural rework needs its own breathing room.

Q2 — "Procedural event" or "Submission" or "Verfahrensschritt" as the umbrella term?

m proposed "procedural event". Some surfaces already use "submission" (Schriftsätze = filings only). The umbrella covers more than just submissions (oral hearings, decisions). Pick one:

  • (R) "procedural event" (DE: Verfahrensschritt or Verfahrensereignis) — covers all of filings, hearings, decisions, replies.
  • Alternative: keep "submission" but expand its meaning. Risk: existing Schriftsätze UI surfaces would be misleading.
  • Alternative: keep "event" / "event_type" (existing column name). Risk: collides with paliad.events (audit feed).

Lock the term in the design doc + i18n.

Q3 — Migration shape if Q1=B

If restructure ships:

  • paliad.procedural_events(id, code, name, event_kind, proceeding_type_id, default_party_role, default_legal_source_id, sequence_ordinal, …) — one row per template procedural event.
  • paliad.sequencing_rules(id, procedural_event_id, trigger_event_id, period_months, period_days, …) — extracted timing rules.
  • paliad.legal_sources(id, citation, jurisdiction, pretty_name, …) — extracted.
  • paliad.deadlines.rule_id → paliad.deadlines.procedural_event_id (rename + migrate; live column is rule_id, not deadline_rule_id — verified B.0 2026-05-26 t-paliad-273); paliad.deadlines.custom_rule_text from t-paliad-258 stays as-is.
  • Backfill: every existing deadline_rules row becomes a procedural_events row + its own sequencing_rules row + legal_sources row.

Q4 — Effect on Schriftsätze / Submissions feature

t-paliad-238 + t-paliad-242 + t-paliad-243 built the Submissions/Schriftsätze surface on top of the current deadline_rules filtering. If we restructure:

  • The Submissions surface filters procedural_events by event_kind IN ('filing', 'reply') (or similar) → same content, cleaner predicate.
  • The submission_code becomes procedural_event.code — same string, cleaner name.
  • submission_templates registry keys off procedural_event.code instead of deadline_rules.submission_code — same external behavior.

Deliverable

docs/design-procedural-events-model-2026-05-25.md on branch mai/<inventor>/procedural-events-design. Sections:

  • §0 TL;DR
  • §1 Premises verified live (audit current deadline_rules schema + every consumer)
  • §2 m's vocabulary call (Q2 — lock the umbrella term)
  • §3 Scope decision (Q1 — A vs B vs C, default (R)=C)
  • §4 Restructure schema (Q3 — if we go B/C, the target shape)
  • §5 Migration plan (data backfill, dual-write window if needed, drop old columns)
  • §6 Service-layer impact (ProjectionService, SubmissionVarsService, deadline_service, projection)
  • §7 UI/i18n impact (placeholder renames, field labels, surface copy)
  • §8 Slice plan (Slice A: cosmetic rename within the existing table — ship; Slice B: restructure with migration — ship later in its own task)
  • §9 Risk assessment (what breaks if migration goes wrong; rollback strategy)
  • §10 Out of scope
  • §11 Open questions for m

Hard rules

  • READ-ONLY design phase. No code, no migrations.
  • Head answers questions — NO AskUserQuestion. Inventor uses mai instruct head. Defaults to (R); escalate to head only on material picks (esp. Q1 and Q2).
  • Inventor → coder gate per project CLAUDE.md.
  • Verify every current consumer of deadline_rules (services + handlers + frontend bundles + i18n keys) before designing — the rename surface is wider than it looks.

When done

Push design doc + mai report completed with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift.

Out of scope

  • Modeling per-jurisdiction variations of the same procedural event as a single row vs N rows (existing design choice; keep).
  • Renaming paliad.events (audit feed) — that's a separate table; don't touch.
  • Cross-firm sharing / multi-tenant model considerations.
## m's report (2026-05-25 15:02) While looking at a Rechtsbeschwerdebegründung in the editor sidebar: ``` Submission Submission Rechtsbeschwerdebegründung {{rule.name}} Legal source § 102 PatG {{rule.legal_source_pretty}} Primary party both {{rule.primary_party}} Event type filing {{rule.event_type}} Submission code dpma.appeal.bgh.begruendung {{rule.submission_code}} ``` > This shows how our 'rule' table system may need a revision?! It feels like we are rule based not submission based. But here we have a specific submission that is connected to a rule (as in: legal norm). And of course also connected to other 'procedural events' (which is a good term for it all) by rules how they are sequenced. But it makes it sound weird in the fields... ## The observation `paliad.deadline_rules` today conflates **three distinct concepts** into one row: 1. **The procedural event** — "Rechtsbeschwerdebegründung" (the thing that happens / gets filed). m proposes **procedural event** as the umbrella term covering filings, oral hearings, decisions, replies, etc. 2. **The legal norm** anchoring it — "§ 102 PatG" / "UPC RoP R.220(1)" (the source-of-law citation). 3. **The sequencing rule** — the period ("+2 months"), the trigger event, the party role, the dependency on other procedural events. Mixing these forces awkward field labels (`{{rule.submission_code}}` for what's really a procedural-event identifier; `{{rule.event_type}}` for the procedural-event type) and confuses the mental model. ## Phase: inventor design (READ-ONLY) Inventor → coder gate per project CLAUDE.md. ## Open design questions ### Q1 — Scope: relabel vs restructure A. **Cosmetic / relabel only**: rename `{{rule.X}}` placeholders + UI field labels to use "submission" / "procedural event" wording. Keep the underlying `deadline_rules` table shape. ~1 coder shift. B. **Restructure**: introduce a `paliad.procedural_events` table as the primary entity; demote sequencing rules to a `sequencing_rules` table linking procedural events; demote legal sources to a join. Migration + service-layer + UI refactor. C. **Mixed**: rename in code + UI now, plan B as a follow-up that requires its own migration window. **(R) = C**: name the entities right immediately (refactor `rule.X` → `procedural_event.X` in placeholders + UI labels; keep DB shape); design B in detail with a clear migration plan but DON'T ship it in this slice. The cosmetic win is immediate; the structural rework needs its own breathing room. ### Q2 — "Procedural event" or "Submission" or "Verfahrensschritt" as the umbrella term? m proposed "procedural event". Some surfaces already use "submission" (Schriftsätze = filings only). The umbrella covers more than just submissions (oral hearings, decisions). Pick one: - **(R)** "procedural event" (DE: `Verfahrensschritt` or `Verfahrensereignis`) — covers all of filings, hearings, decisions, replies. - Alternative: keep "submission" but expand its meaning. Risk: existing Schriftsätze UI surfaces would be misleading. - Alternative: keep "event" / "event_type" (existing column name). Risk: collides with `paliad.events` (audit feed). Lock the term in the design doc + i18n. ### Q3 — Migration shape if Q1=B If restructure ships: - `paliad.procedural_events(id, code, name, event_kind, proceeding_type_id, default_party_role, default_legal_source_id, sequence_ordinal, …)` — one row per template procedural event. - `paliad.sequencing_rules(id, procedural_event_id, trigger_event_id, period_months, period_days, …)` — extracted timing rules. - `paliad.legal_sources(id, citation, jurisdiction, pretty_name, …)` — extracted. - `paliad.deadlines.rule_id` → `paliad.deadlines.procedural_event_id` (rename + migrate; live column is `rule_id`, not `deadline_rule_id` — verified B.0 2026-05-26 t-paliad-273); `paliad.deadlines.custom_rule_text` from t-paliad-258 stays as-is. - Backfill: every existing `deadline_rules` row becomes a `procedural_events` row + its own `sequencing_rules` row + `legal_sources` row. ### Q4 — Effect on Schriftsätze / Submissions feature t-paliad-238 + t-paliad-242 + t-paliad-243 built the Submissions/Schriftsätze surface on top of the current `deadline_rules` filtering. If we restructure: - The Submissions surface filters `procedural_events` by `event_kind IN ('filing', 'reply')` (or similar) → same content, cleaner predicate. - The submission_code becomes `procedural_event.code` — same string, cleaner name. - `submission_templates` registry keys off `procedural_event.code` instead of `deadline_rules.submission_code` — same external behavior. ## Deliverable `docs/design-procedural-events-model-2026-05-25.md` on branch `mai/<inventor>/procedural-events-design`. Sections: - §0 TL;DR - §1 Premises verified live (audit current `deadline_rules` schema + every consumer) - §2 m's vocabulary call (Q2 — lock the umbrella term) - §3 Scope decision (Q1 — A vs B vs C, default (R)=C) - §4 Restructure schema (Q3 — if we go B/C, the target shape) - §5 Migration plan (data backfill, dual-write window if needed, drop old columns) - §6 Service-layer impact (ProjectionService, SubmissionVarsService, deadline_service, projection) - §7 UI/i18n impact (placeholder renames, field labels, surface copy) - §8 Slice plan (Slice A: cosmetic rename within the existing table — ship; Slice B: restructure with migration — ship later in its own task) - §9 Risk assessment (what breaks if migration goes wrong; rollback strategy) - §10 Out of scope - §11 Open questions for m ## Hard rules - READ-ONLY design phase. No code, no migrations. - **Head answers questions** — NO AskUserQuestion. Inventor uses `mai instruct head`. Defaults to (R); escalate to head only on material picks (esp. Q1 and Q2). - Inventor → coder gate per project CLAUDE.md. - Verify every current consumer of `deadline_rules` (services + handlers + frontend bundles + i18n keys) before designing — the rename surface is wider than it looks. ## When done Push design doc + `mai report completed` with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift. ## Out of scope - Modeling per-jurisdiction variations of the same procedural event as a single row vs N rows (existing design choice; keep). - Renaming `paliad.events` (audit feed) — that's a separate table; don't touch. - Cross-firm sharing / multi-tenant model considerations.
mAi self-assigned this 2026-05-25 13:04:01 +00:00
mAi commented 2026-05-26 11:45:03 +00:00
Author
Collaborator
Copy Link

B.0 read-only re-validation complete (t-paliad-273)

Branch: mai/curie/researcher-slice-b-zero · Commit: c4c0a82
Findings doc: docs/design-procedural-events-b0-findings-2026-05-26.md

Scope: re-checked every load-bearing premise in cronus's §1 against the live paliad schema. Nothing written to deadline_rules. B.1 stays blocked pending m's greenlight.

Drift since 2026-05-25

Metric Design Live Δ
deadline_rules rows 254 231 -23
distinct submission_codes 158 153 -5
distinct legal_sources 70 87 +17
concept-linked rules 125 129 +4
paliad.deadlines rows 1 5 +4
submission_drafts rows 4 7 +3
Next available mig 124 134 +10

10 migrations landed in the design's first 24 h (mig 124..133).

Decisions confirmed / refined

  • Q5 — archived multi-row codes (10 _archived_litigation.*): now moot. Zero _archived_litigation.* rows in the live DB; every active submission_code is 1:1 with one rule row. B.1 backfill becomes a straight 1:1 INSERT — no GROUP-BY collapse step needed.
  • Q6 — concept_id attaches to procedural event, not sequencing rule: confirmed N:1. Empirical: 53 distinct concepts cover 129 rule rows; 38% of concepts span >1 submission_code (max 15). §4.1's procedural_events.concept_id FK shape is already correct — no UNIQUE index. Wording in the design's Q6 should be tightened to "many procedural events → one concept" (mechanical edit, not a structural change; flagged in findings §3).
  • Snapshot precedent confirmed: deadline_rules_pre_{091,093,095,098} exists. B.4's drop migration must include CREATE TABLE paliad.deadline_rules_pre_<N> AS TABLE paliad.deadline_rules; before DROP TABLE. Non-negotiable.
  • Doc-side bug fixed: issue body line 56 now reads paliad.deadlines.rule_id (was deadline_rule_id — no such column ever existed). Live FK confirmed via information_schema.referential_constraints: paliad.deadlines.rule_id → paliad.deadline_rules.id.

One decision to surface to m before B.1 starts

78 rule rows have submission_code IS NULL (231 - 153). They are the "structural / parent-only rows in the proceeding tree". B.1 must explicitly decide whether they (a) get skipped and lost at B.4 drop time [unacceptable], (b) get synthetic codes minted and become procedural_events [recommended], or (c) become free-standing sequencing_rules with NULL procedural_event_id [would relax §4.1's NOT NULL FK]. See findings §7 point 2.

Out-of-scope observation

Project CLAUDE.md still says "Migration tracker is paliad.paliad_schema_migrations". Canonical tracker per internal/db/migrate.go:9-21,53,105 is paliad.applied_migrations. The legacy paliad_schema_migrations table is frozen at v106 and only used to bootstrap the new tracker. Separate doc-fix slice recommended; not part of B.0.

Status: B.0 COMPLETE, AWAITING B.1 GREENLIGHT. Researcher (curie) parked.

## B.0 read-only re-validation complete (t-paliad-273) **Branch:** [`mai/curie/researcher-slice-b-zero`](https://mgit.msbls.de/m/paliad/src/branch/mai/curie/researcher-slice-b-zero) · **Commit:** [`c4c0a82`](https://mgit.msbls.de/m/paliad/commit/c4c0a82) **Findings doc:** [`docs/design-procedural-events-b0-findings-2026-05-26.md`](https://mgit.msbls.de/m/paliad/src/branch/mai/curie/researcher-slice-b-zero/docs/design-procedural-events-b0-findings-2026-05-26.md) Scope: re-checked every load-bearing premise in cronus's §1 against the live `paliad` schema. Nothing written to `deadline_rules`. **B.1 stays blocked pending m's greenlight.** ### Drift since 2026-05-25 | Metric | Design | Live | Δ | |---|--:|--:|--:| | `deadline_rules` rows | 254 | 231 | -23 | | distinct `submission_code`s | 158 | 153 | -5 | | distinct `legal_source`s | 70 | 87 | +17 | | concept-linked rules | 125 | 129 | +4 | | `paliad.deadlines` rows | 1 | 5 | +4 | | `submission_drafts` rows | 4 | 7 | +3 | | Next available mig | 124 | **134** | +10 | 10 migrations landed in the design's first 24 h (mig 124..133). ### Decisions confirmed / refined - **Q5 — archived multi-row codes (10 `_archived_litigation.*`):** **now moot.** Zero `_archived_litigation.*` rows in the live DB; every active `submission_code` is 1:1 with one rule row. B.1 backfill becomes a straight 1:1 INSERT — no GROUP-BY collapse step needed. - **Q6 — `concept_id` attaches to procedural event, not sequencing rule:** **confirmed N:1.** Empirical: 53 distinct concepts cover 129 rule rows; 38% of concepts span >1 submission_code (max 15). §4.1's `procedural_events.concept_id` FK shape is already correct — no UNIQUE index. Wording in the design's Q6 should be tightened to "many procedural events → one concept" (mechanical edit, not a structural change; flagged in findings §3). - **Snapshot precedent confirmed:** `deadline_rules_pre_{091,093,095,098}` exists. B.4's drop migration must include `CREATE TABLE paliad.deadline_rules_pre_<N> AS TABLE paliad.deadline_rules;` before `DROP TABLE`. Non-negotiable. - **Doc-side bug fixed:** issue body line 56 now reads `paliad.deadlines.rule_id` (was `deadline_rule_id` — no such column ever existed). Live FK confirmed via `information_schema.referential_constraints`: `paliad.deadlines.rule_id → paliad.deadline_rules.id`. ### One decision to surface to m before B.1 starts **78 rule rows have `submission_code IS NULL`** (231 - 153). They are the "structural / parent-only rows in the proceeding tree". B.1 must explicitly decide whether they (a) get skipped and lost at B.4 drop time [unacceptable], (b) get synthetic codes minted and become `procedural_events` [recommended], or (c) become free-standing `sequencing_rules` with NULL `procedural_event_id` [would relax §4.1's NOT NULL FK]. See findings §7 point 2. ### Out-of-scope observation Project CLAUDE.md still says "Migration tracker is `paliad.paliad_schema_migrations`". Canonical tracker per `internal/db/migrate.go:9-21,53,105` is `paliad.applied_migrations`. The legacy `paliad_schema_migrations` table is frozen at v106 and only used to bootstrap the new tracker. Separate doc-fix slice recommended; not part of B.0. --- **Status: B.0 COMPLETE, AWAITING B.1 GREENLIGHT.** Researcher (curie) parked.
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 mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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