paliad/docs/proposals/fristen-gap-fill-2026-05-18.md

Fristenrechner Gap-Fill Proposals — t-paliad-203

Date: 2026-05-18 Author: curie (researcher) Status: DRAFT — for m's review, not yet ingested via /admin/rules Branch: mai/curie/fristenrechner-gap Supersedes: t-paliad-201 (cancelled) Source audit: the four gaps surfaced by mig 093 commit message (t-paliad-200, internal/db/migrations/093_retire_litigation_category.up.sql:40-54) when 40 Pipeline-A litigation rules were archived under _archived_litigation and 7 litigation proceeding_types were dropped

---

0. Read-this-first — what was archived, what's left

mig 093 (commit 40e49e8) retired the entire category='litigation' rule corpus by:

1. Snapshotting the 40 rules into paliad.deadline_rules_pre_093 and the 7 proceeding_types into paliad.proceeding_types_pre_093.
2. Re-homing all 40 rules under a holding proceeding_type _archived_litigation (id 32, category='archived', is_active=false, lifecycle_state='archived').
3. Dropping INF, REV, CCR, APM, APP, AMD, ZPO_CIVIL from paliad.proceeding_types.

The commit's own body listed four open coverage questions for legal review (lines 40-54 of 093_retire_litigation_category.up.sql):

#	Pipeline-A rule(s)	Claim in commit body	This doc's verdict
1	inf.prelim (R.19, 1 month)	"not present on UPC_INF — possible coverage gap"	Real gap. Drafts 1.1 + 1.2 below.
2	inf.appeal / rev.appeal / ccr.appeal (RoP.220.1, 2 months) into UPC_APP	"fristenrechner UPC_APP starts standalone with no spawn"	Real gap. Drafts 2.1 + 2.2 below. Pipeline-A's three rules collapse to two in the unified UPC_INF (CCR-as-flag) world — see § 2 FLAG.
3	ccr.amend / rev.amend (spawn into AMD)	"superseded by inf.app_to_amend / rev.app_to_amend — safe to drop"	Claim confirmed for patent amendment. No new rules. § 3 documents the verification and surfaces R.263 (case-amendment) as a separate not-modelled item.
4	zpo.klage / zpo.vertanz / zpo.klageerw / zpo.berufung	"no UPC analogue; redundant with DE_INF / DE_INF_OLG / DE_INF_BGH / DE_NULL / DE_NULL_BGH"	Claim confirmed for klage / vertanz / berufung. klageerw exists on DE_INF but with a duration discrepancy worth m's attention. § 4 details.

Net: 4 substantive rule drafts (1 PO on UPC_INF + 1 PO on UPC_REV + 2 merits-appeal spawns) — well under the "~4-10" estimate in the brief, and at the low end because two of the four gaps don't need new rules.

0.1 Naming convention notes

• Appeal proceeding code referenced by ROLE, not by current code. Per task brief and pairing with t-paliad-204 (proceeding-code abbreviation rework, m's review pending), the current UPC_APP (id=11) is referred to in proposals 2.1/2.2 as "UPC infringement-appeal proceeding (RoP 220.1(a) main-judgment appeal)" rather than by code. m picks the final spawn_proceeding_type_id when ingesting via /admin/rules.
• Existing rule-code pattern. Live UPC_INF rules use bare prefix inf.* (not upc.inf.*), e.g. inf.sod, inf.def_to_ccr. Live UPC_REV rules use rev.*. I follow that pattern: proposed PO rules are inf.prelim (matching Pipeline-A's archived name) and rev.prelim; proposed spawn rules are inf.appeal_spawn / rev.appeal_spawn (the _spawn suffix disambiguates them from the existing UPC_APP-root app.notice, which is the target, not the source).
• Anchor semantics (per docs/audit-fristen-logic-2026-05-13.md § 4 and docs/proposals/orphan-concepts-2026-05-15.md § 0.2): parent_id NOT NULL chains the new rule off an existing rule in the same proceeding. trigger_event_id NOT NULL roots the rule on a paliad/youpc trigger event. The unified Phase 2 schema (Slice 4, mig 081+082) supports both — proposals use parent_id whenever the natural anchor is an existing intra-proceeding rule (e.g. inf.soc for inf.prelim), which matches the pattern set by inf.sod, inf.def_to_ccr, etc.
• condition_expr form. Existing UPC_INF / UPC_REV conditional rules use {"flag":"with_ccr"} or {"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_amend"}]}. The proposals add three new flag names — with_po, with_appeal, and reuse with_amend only where existing. Flag names are surfaced as FLAG items for m to confirm before ingest.

0.2 What's deliberately out of scope

• Order-appeals (R.220.2/R.220.3) spawn wiring — the brief specifies RoP 220.1(a) (main-judgment, 2-month appeal → UPC_APP). The 15-day order/discretion track lives in UPC_APP_ORDERS and has its own root rules (app_ord.with_leave, app_ord.discretion). Spawn rules from UPC_INF/UPC_REV/UPC_PI for that track would be a separate proposal — flagged as future-work in § 6.
• Cost-decision-appeal spawn (R.221.1) — UPC_COST_APPEAL exists with cost.leave_app as a root rule. Same shape as the order-appeals: future-work, not this proposal.
• R.263 application to amend the case — surfaced in § 3 but not drafted as a rule because it's court-discretion (no calendar deadline computable from a fixed anchor).
• Vertagungsantrag (ZPO §227) — the brief's description of Gap 4 named "Vertagungsantrag" but the Pipeline-A rule code zpo.vertanz is actually Verteidigungsanzeige (contraction of "Verteidigungs-Anzeige"), not Vertagungsantrag. There is no Vertagungsantrag rule anywhere in the corpus today; if m wants one, that's a fresh proposal. Documented in § 4 FLAG.

---

0.3 m's decisions on the open FLAGs (2026-05-18)

Captured live with paliadin/head. Anything not explicitly answered defaults to curie's recommendation.

Gap 1 — Preliminary Objection

• F1.4 (CCR-defendant PO): NO — do not seed a third PO rule for the patentee on a CCR. Final shape stays at 2 PO rules: inf.prelim + rev.prelim.
• F1.1 (flag name): default to curie's with_po.
• F1.2 (priority): default to curie's optional.
• F1.3 (citation pattern): default to curie's UPC.RoP.19.1 substantive-cite for both rules (cross-ref to R.46 lives in the description, not the legal_source field).

Gap 2 — Appeal spawns

• F2.1 (drop ccr.appeal): CONFIRMED — one decision under R.118 = one 2-month appeal window. Rule 2.3 explicitly NOT seeded. Final shape stays at 2 spawn rules.
• F2.3 (appeal flag-gated or always-fire): ALWAYS-FIRE. Rationale (m): "the appeal deadline should always be triggered by a decision … the flags for ccr / amend are different because that is something which only comes up during the proceedings and depends on a party. Appeal is always a possibility." So both inf.appeal_spawn and rev.appeal_spawn ship without condition_expr — the 2-month window unconditionally appears once inf.decision / rev.decision is anchored. Visibility filtering ("hide appeal deadlines on projects where the user doesn't care") is a frontend concern, not a rule-level flag — surfaced as follow-up (see § 6.X below).
• F2.2 (anchor): default to curie's parent_id = inf.decision / rev.decision (consistent with how inf.cost_app already chains).

Gap 3 — ccr.amend / rev.amend

• F3.1 (model R.263?): NO — court-discretion, no calendar deadline computable. If R.263 ever needs surfacing, it goes on the project page as a checklist item, not the fristenrechner.

Gap 4 — zpo.* family

• §4.3 — de_inf.erwidg discrepancy (6 weeks vs. court-set 2-week minimum): FLIP to court-set. Klageerwiderung is statutorily court-set with a 2-week minimum under ZPO §276(1) S.2; the existing 6-week fixed-duration rule is wrong. Action at ingest: is_court_set=true, keep duration_value=6, duration_unit='weeks' as the default display value when no court order is yet attached, with the description noting "Gericht setzt eine Frist von mindestens zwei Wochen ab Verteidigungsanzeige (§276 Abs. 1 S. 2 ZPO)." This matches the pattern existing court-set rules use elsewhere.
• F4.1 (legal_source backfills on de_inf.klage etc.): default to curie's "yes — apply the polish patches in § 4.1, § 4.2, § 4.4".

Final delta to ingest via /admin/rules

NEW RULES (4):
  inf.prelim         UPC_INF  parent=inf.soc      1mo  RoP.19.1   flag=with_po       optional
  rev.prelim         UPC_REV  parent=rev.app      1mo  RoP.19.1   flag=with_po       optional
  inf.appeal_spawn   UPC_INF  parent=inf.decision 2mo  RoP.220.1.a (no flag)         optional  spawn→merits-appeal
  rev.appeal_spawn   UPC_REV  parent=rev.decision 2mo  RoP.220.1.a (no flag)         optional  spawn→merits-appeal

PATCHES on existing rules:
  de_inf.klage       set legal_source = 'DE.ZPO.253'
  de_inf.anzeige     (no change — already correct)
  de_inf.erwidg      flip is_court_set = true; description note about §276 Abs.1 S.2
  de_inf.berufung    (verify legal_source — curie's §4.4 polish patch)

Follow-up surfaced — not for this proposal

• Frontend visibility toggle for appeal deadlines — m flagged that appeals "always fire" at the rule level but the UI could hide them on projects where the user doesn't want to see them. NOT a rule-corpus question; file as a separate frontend task if/when m signals.
• ccr.appeal in _archived_litigation — the Pipeline-A ccr.appeal row stays archived (m's call F2.1). No further action.
• Vertagungsantrag (ZPO §227) — never modelled; not in scope. Open follow-up if m wants it.

---

1. Gap 1 — Preliminary Objection (RoP 19)

Status: Real gap. Pipeline-A had inf.prelim (defendant, 1 month, R.19, "Rarely triggers separate decision; usually decided with main case") — archived without a fristenrechner replacement.

Verification — current UPC_INF / UPC_REV corpus has zero rules with rule_code matching R.19, RoP.019, or any "Preliminary Objection" variant; verified via SELECT * FROM paliad.deadline_rules WHERE rule_code ILIKE '%19%' OR name ILIKE '%vorab%' OR name ILIKE '%prelim%' AND lifecycle_state <> 'archived' returns empty.

Legal context — RoP 19 itself (Application of the Rules of Procedure, Part 1, Chapter 1, Section 4):

• R.19.1: The defendant may, within 1 month of service of the Statement of claim, lodge a Preliminary objection concerning (a) jurisdiction and competence of the Court including any objection to the decision of the Registry to assign a case to a particular division, (b) the language of the Statement of claim (R.14), or (c) the competence of the panel to which the action has been assigned.
• R.19.7 / R.19.8: The Court decides on a preliminary objection by way of order, typically before the interim conference, but may join it to the main proceedings.
• R.46: The Rules in Part 1, Chapter 1 (including R.19) apply mutatis mutandis to revocation actions — i.e. the defendant in a revocation action (the patent proprietor) may also lodge a preliminary objection within 1 month of service of the Statement for revocation.

The Pipeline-A note "Rarely triggers separate decision; usually decided with main case" is accurate practice — but the 1-month deadline to raise the objection is hard and statutory. That deadline is what the fristenrechner needs to model.

Rule 1.1 — Preliminary Objection on UPC_INF

• Rule code: inf.prelim
• Proceeding type: UPC_INF (id=8)
• Name (DE): Vorab-Einrede (R. 19 VerfO)
• Name (EN): Preliminary Objection (RoP 19)
• Party: defendant
• Anchor: parent_id = inf.soc (the existing root rule "Klageerhebung") — same anchor pattern as inf.sod (Klageerwiderung, also parent=inf.soc). inf.soc is the trigger-date anchor; computing 1 month after inf.soc reads as "1 month from service of the Statement of Claim", consistent with R.19.1's wording.
• Duration: 1, months
• Timing: after
• Priority: optional (party decides whether to raise the objection; the 1-month period is statutory once invoked)
• is_court_set: false (statutory period from service; not court-set)
• condition_expr: {"flag":"with_po"} (only renders when the defendant indicates a PO will be filed — same shape as existing with_ccr / with_amend flags)
• Legal source: UPC.RoP.19.1
• rule_code: RoP.019.1
• event_type: filing
• Notes: R.19.1 covers three independent grounds (a) jurisdiction/competence, (b) language under R.14, (c) panel competence. All share the same 1-month deadline. The UI rendering decision (one row vs. three rows by ground) is downstream UX, not a rule-corpus question.
• FLAG (F1.1): Flag name — with_po is suggested by analogy to with_ccr / with_amend / with_cci. Alternative names: with_preliminary_objection, prelim. m's call.
• FLAG (F1.2): Priority — proposed optional (defendant chooses); m may prefer recommended to surface it as a sanity-check chip on every defendant timeline. The Pipeline-A predecessor had is_optional=true / is_mandatory=false per the old binary schema, which maps cleanly to priority='optional' in the post-Slice-3 enum.

Rule 1.2 — Preliminary Objection on UPC_REV

• Rule code: rev.prelim
• Proceeding type: UPC_REV (id=9)
• Name (DE): Vorab-Einrede (R. 19 i.V.m. R. 46 VerfO)
• Name (EN): Preliminary Objection (RoP 19 in conjunction with RoP 46)
• Party: defendant (in a revocation action the patentee is the defendant)
• Anchor: parent_id = rev.app (the existing root rule "Nichtigkeitsklage" — analogous to rev.defence which also parents off rev.app)
• Duration: 1, months
• Timing: after
• Priority: optional
• is_court_set: false
• condition_expr: {"flag":"with_po"} (same flag as 1.1 — a PO is a PO; the user sets with_po=true on a UPC_REV project when the patentee plans to lodge one)
• Legal source: UPC.RoP.46 (R.46 makes R.19 applicable to revocation actions; cite R.46 as the operative provision because RoP 19's literal text only addresses infringement)
• rule_code: RoP.046 (or RoP.019.1 with a note — m's call; see FLAG F1.3)
• event_type: filing
• Notes: Functionally identical to Rule 1.1 but rooted on UPC_REV. The grounds are narrower in practice (language and panel competence are the main triggers — jurisdiction is rarely contested in pure revocation actions because the UPC's jurisdiction over revocation of unitary patents is exclusive). But the 1-month statutory window is identical.
• FLAG (F1.3): Legal-source citation — should this read UPC.RoP.46 (operative provision for revocation) or UPC.RoP.19.1 (substantive content)? Existing rules use the substantive citation (e.g. inf.def_to_ccr cites UPC.RoP.29.a, not the cross-reference that brings R.29 into the UPC_INF flow). I lean UPC.RoP.19.1 with rule_code='RoP.019.1' to match that pattern; the cross-reference to R.46 belongs in the description, not the citation field.
• FLAG (F1.4): Does paliad want counterclaim-defendant PO rules too? Specifically, when UPC_INF has with_ccr=true, the claimant (patentee) becomes the de-facto-defendant for the CCR portion. Does the claimant get a 1-month PO window from service of the CCR? My read of R.19 + R.46 + R.25: yes — the CCR triggers a fresh R.19 window for the claimant, anchored on service of the SoD-with-CCR. But this would be a third rule (inf.prelim_ccr, party=claimant, parent=inf.sod, 1 month, condition_expr={"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_po_ccr"}]}). I'm not drafting it pending m's confirmation; either it's truly there in the case law or it's an over-reading on my part. Lex-research won't help here because there's no relevant published UPC PO case on a CCR yet (R.46 + R.25 cross-reads are theoretical).

Summary for Gap 1: 2 new rules drafted (one on UPC_INF, one on UPC_REV). 4 FLAGs. Potential third rule (CCR-PO) deferred pending m's read.

---

2. Gap 2 — Cross-proceeding APP spawns (RoP 220.1(a))

Status: Real gap. Pipeline-A had three placeholder rules (inf.appeal, rev.appeal, ccr.appeal, all 2 months, RoP.220.1, is_spawn=true) — but their spawn_proceeding_type_id was NULL so they weren't functional spawns either. Fristenrechner UPC_APP currently starts standalone with app.notice as its root rule (party=both, 2 months, RoP.220.1).

Verification — current corpus has zero is_spawn=true AND is_active=true AND lifecycle_state<>'archived' rules; the spawn_proceeding_type_id column on paliad.deadline_rules is unused in the live data (Slice 7 wiring was the design intent but no real spawns have been seeded yet).

Legal context — RoP 220 (Decisions and orders which may be appealed):

• R.220.1(a): Final decisions under R.118 may be appealed. The appeal period is 2 months of service of the decision (R.224.1(a)).
• R.224.1(a): The Statement of appeal must be lodged within 2 months of service of the decision.
• R.224.2(a): The Statement of grounds of appeal must be lodged within 4 months of service of the decision (independent from R.224.1(a), not chained off it).

The spawn target — the proceeding rooted by app.notice (Berufungseinlegung, RoP.220.1, 2 months) and app.grounds (Berufungsbegründung, 4 months from decision) — is what the task brief calls the "UPC infringement-appeal (RoP 220.1(a) main-judgment appeal)" proceeding. Today that's UPC_APP (id=11); per t-paliad-204, the code may be renamed before m ingests these proposals, so I refer to it by role only.

Rule 2.1 — Appeal spawn from UPC_INF

• Rule code: inf.appeal_spawn
• Proceeding type: UPC_INF (id=8)
• Name (DE): Berufung gegen Endentscheidung
• Name (EN): Appeal against final decision
• Party: both (either party may appeal an R.118 final decision adverse to them)
• Anchor: parent_id = inf.decision (existing court-set rule "Entscheidung"). The chain: inf.soc → … → inf.decision (court-set, no statutory date) → inf.appeal_spawn (2 months after service of decision). Because inf.decision is IsCourtSet=true (per isCourtDeterminedRule in internal/services/fristenrechner.go), the appeal-spawn deadline only becomes a concrete date once the user anchors inf.decision via the smart-timeline click-to-anchor mechanism (Slice 2, POST /api/projects/{id}/timeline/anchor per memory ab966313-cae6-49b0-8223-9adb62a64370).
• Duration: 2, months
• Timing: after
• Priority: optional (party decides whether to appeal; the 2-month period is statutory once invoked)
• is_court_set: false (deadline is statutory once the decision is served)
• condition_expr: {"flag":"with_appeal"} (only renders when the user has indicated an appeal is contemplated — keeps non-appealing projects' timelines clean)
• Legal source: UPC.RoP.220.1
• rule_code: RoP.220.1.a
• event_type: filing
• is_spawn: true
• spawn_proceeding_type_id: → UPC infringement-appeal proceeding (currently UPC_APP, id=11; m picks final code at ingest per t-paliad-204).
• spawn_label (DE): "Berufungsverfahren öffnen"
• spawn_label (EN): "Open appeal proceedings"
• Notes: Spawning into the appeal proceeding creates a child project (or routes into the standalone UPC_APP fristenrechner depending on how spawn rendering works on the project page). The 4-month Statement of grounds period (R.224.2(a), app.grounds) is already a root rule on UPC_APP — once the appeal child opens, that timeline takes over. No need to also model app.grounds as a spawn rule from UPC_INF; the existing UPC_APP root rules cover it.
• FLAG (F2.1): Does the spawn fire on the CCR portion of the decision too? In a with_ccr=true UPC_INF, the R.118 final decision adjudicates both the infringement and the counterclaim for revocation. Either side may appeal either part. My read: one spawn covers both — there's only one R.118 decision, one 2-month window. The Pipeline-A ccr.appeal was a relic of the days when CCR was a separate proceeding type. Recommend dropping the third "ccr.appeal" entirely, because in the unified UPC_INF (CCR-as-flag) model it would duplicate Rule 2.1. m to confirm.
• FLAG (F2.2): Anchor — should the spawn rule chain off inf.decision (court-set, requires anchor-click) or be event-rooted on a final_decision_service trigger event (paliad has trigger_event id=88 "Endentscheidung (Zustellung)")? Both work. Chaining on inf.decision keeps the rule visually attached to its parent proceeding in the UI; event-rooted is more flexible if the user wants to compute an appeal deadline standalone without a project. Recommend parent_id = inf.decision to match how inf.cost_app chains off inf.decision already.
• FLAG (F2.3): Flag name — with_appeal mirrors the existing with_ccr / with_amend flag naming. Alternative: spawn rules might always fire (no flag), letting the timeline show the appeal window as a "predicted/court-set" placeholder. The latter is closer to what the SmartTimeline projection (projection_service.go) already does for cross-proceeding rules per memory 686f0b8c-02ed-4807-8785-b088e3a3e515 § 6 gap 7. If m wants the appeal window to always appear after the decision (unconditionally), drop condition_expr here and on Rule 2.2.

Rule 2.2 — Appeal spawn from UPC_REV

• Rule code: rev.appeal_spawn
• Proceeding type: UPC_REV (id=9)
• Name (DE): Berufung gegen Endentscheidung (Nichtigkeit)
• Name (EN): Appeal against final decision (revocation)
• Party: both
• Anchor: parent_id = rev.decision (existing court-set rule "Entscheidung")
• Duration: 2, months
• Timing: after
• Priority: optional
• is_court_set: false
• condition_expr: {"flag":"with_appeal"}
• Legal source: UPC.RoP.220.1
• rule_code: RoP.220.1.a
• event_type: filing
• is_spawn: true
• spawn_proceeding_type_id: → same UPC infringement-appeal proceeding as Rule 2.1. The UPC CoA hears both INF and REV appeals; in a with_cci=true UPC_REV (Verletzungswiderklage / counterclaim-for-infringement), the R.118 decision may also adjudicate the infringement piece, but again it's one decision, one appeal window.
• spawn_label (DE): "Berufungsverfahren öffnen"
• spawn_label (EN): "Open appeal proceedings"
• Notes: Functionally a mirror of Rule 2.1 on the revocation proceeding. Same FLAGs F2.1-F2.3 apply.

Rule 2.3 — (proposed) NOT drafted: separate ccr.appeal from UPC_INF with_ccr

See FLAG F2.1. In the unified model, the CCR portion of an UPC_INF decision is appealed via the same R.118 final-decision spawn (Rule 2.1) — a single 2-month window covers infringement, revocation, and patent-amendment claims because they all sit in one R.118 decision. Drafting ccr.appeal as a third rule would duplicate Rule 2.1 conditionally ({"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_appeal"}]}) and produce a redundant timeline row. Recommendation: do not seed. If m disagrees, the rule shape would be:

inf.appeal_spawn_ccr (UPC_INF)
  condition_expr: {"op":"and","args":[{"flag":"with_ccr"},{"flag":"with_appeal"}]}
  spawn_label: "Berufung Nichtigkeit öffnen" (specifically the CCR portion)

Only useful if the appeal UI needs to distinguish "appealing the infringement finding" from "appealing the revocation finding". Today's fristenrechner UI doesn't make that distinction; the appeal proceeding handles both.

Summary for Gap 2: 2 new spawn rules drafted. 3 FLAGs. The third Pipeline-A relic (ccr.appeal) is structurally redundant and recommended not to seed.

---

3. Gap 3 — ccr.amend / rev.amend (verification of "safe to drop" claim)

Status: No new rules needed. The migration's claim ("superseded by inf.app_to_amend / rev.app_to_amend — safe to drop") is confirmed for the patent-amendment scope. There is a separate concept (R.263 application to amend the case) that has never been modelled and probably shouldn't be — see § 3.2.

3.1 Verification — patent-amendment coverage

Pipeline-A's ccr.amend and rev.amend were both:

• duration_value=0, duration_unit='months', event_type='filing', is_spawn=true, party='claimant'
• legal_source=NULL, rule_code=NULL
• source proceeding=AMD (now archived)
• "Application to Amend Patent" / no German name

These were placeholder spawns into a hypothetical "AMD" (Application to amend the patent) proceeding type that never existed as a real fristenrechner tree. They modelled the concept "filing a patent amendment", not its deadline.

The unified UPC_INF / UPC_REV corpus already covers patent amendment with real deadlines and flag-gated chains:

Existing rule	Proceeding	Trigger / parent	Duration	Legal source	Flag-gating
inf.app_to_amend	UPC_INF	parent=inf.sod	2 months	UPC.RoP.30.1	with_ccr+with_amend
inf.def_to_amend	UPC_INF	parent=inf.app_to_amend	2 months	UPC.RoP.32.1	with_ccr+with_amend
inf.reply_def_amd	UPC_INF	parent=inf.def_to_amend	1 month	UPC.RoP.32.3	with_ccr+with_amend
inf.rejoin_amd	UPC_INF	parent=inf.reply_def_amd	1 month	UPC.RoP.32.3	with_ccr+with_amend
rev.app_to_amend	UPC_REV	parent=rev.defence	0 months (filed-with-parent)	UPC.RoP.49.2.a	with_amend
rev.def_to_amend	UPC_REV	parent=rev.app_to_amend	2 months	UPC.RoP.43.3	with_amend
rev.reply_def_amd	UPC_REV	parent=rev.def_to_amend	1 month	UPC.RoP.32.3	with_amend
rev.rejoin_amd	UPC_REV	parent=rev.reply_def_amd	1 month	UPC.RoP.32.3	with_amend

The flag-gated chain on UPC_INF (with_ccr+with_amend) is the post-2026-05-05 ship from t-paliad-131 PR-2 (memory ba1517a3-2294-4c58-aeb6-87e82067834d); the UPC_REV chain (with_amend and with_cci) is from the same PR. Both fully replace what ccr.amend / rev.amend ever could have represented.

Verdict on Gap 3: "Safe to drop" is correct. No new rules.

3.2 R.263 — Application to amend the case (not modelled, probably shouldn't be)

R.263 ("Leave to change claim or amend case") is conceptually different from R.30 (Application to amend the patent). R.263 governs amendment of the pleadings / case — adding a new infringement allegation, narrowing claims, etc. The current corpus has no R.263 rule.

I'm not proposing one because R.263 is purely court-discretionary (R.263.1: "An application may be made by a party at any time to … amend its case … Leave shall be granted only if … the requesting party could not with reasonable diligence have made the application earlier and the amendment will not unreasonably hinder the other party in the conduct of its action"). There is no statutory deadline computable from a fixed anchor — the party files when it needs to, and the court grants or refuses leave by order. Modelling it as a deadline_rule would either:

• (a) Produce a phantom row with no computable date (the existing is_court_set=true pattern would technically work but offers no UX value because the deadline is "whenever you need to amend").
• (b) Produce a misleading row anchored on the SoC date with some heuristic period.

Recommendation: don't seed. If m wants R.263 surfaced anywhere, it belongs as a checklist item on the project page, not as a fristenrechner rule.

FLAG (F3.1): Confirm "don't model R.263" is acceptable. If R.263 should be modelled, what anchor + duration heuristic should it use?

Summary for Gap 3: 0 new rules. 1 FLAG. The claim "safe to drop" is verified for patent amendment. R.263 is a separate concept and intentionally left unmodelled.

---

4. Gap 4 — zpo.* family vs. existing DE_INF / DE_INF_OLG / DE_INF_BGH

Status: No new rules needed for klage, vertanz, berufung. Existing rule de_inf.erwidg (Klageerwiderung) has a duration discrepancy worth m's attention. Task brief's mention of "Klageerweiterung" / "Vertagungsantrag" is a misread of Pipeline-A rule names — those concepts are not in scope here. § 4.1-4.4 verify each Pipeline-A rule; § 4.5 surfaces what would be a real gap if m wants ZPO §227 modelled.

4.1 zpo.klage (Klageerhebung, ZPO §253) — ✓ redundant

Pipeline-A: claimant, 0 months, filing, § 253 ZPO, legal_source=NULL.

Existing rule de_inf.klage on DE_INF: claimant, 0 months, filing. Functionally identical as a root rule (a 0-duration "trigger" anchor). Legal source on the existing rule is NULL — could be backfilled to DE.ZPO.253 as a minor polish, but no new rule needed.

Verdict: no gap. Optional polish: set de_inf.klage.legal_source = 'DE.ZPO.253' (one-line UPDATE; not a new rule). FLAG F4.1.

4.2 zpo.vertanz (Verteidigungsanzeige, ZPO §276(1) Satz 1) — ✓ redundant

Task-brief naming note: the brief described this gap as "Vertagungsantrag" but Pipeline-A's zpo.vertanz is actually Verteidigungsanzeige (contraction "VertAnz" not "VertA. (Antrag)"). The rule name in the snapshot reads "Verteidigungsanzeige" verbatim. Vertagungsantrag (§ 227 ZPO) is a different concept entirely — see § 4.5.

Pipeline-A: defendant, 2 weeks, filing, § 276 Abs. 1 S. 1 ZPO, deadline_notes "Notfrist ab Zustellung der Klageschrift".

Existing rule de_inf.anzeige on DE_INF: defendant, 2 weeks, DE.ZPO.276.1, "Anzeige der Verteidigungsbereitschaft". Same period, same legal basis, same party.

Verdict: no gap.

4.3 zpo.klageerw (Klageerwiderung, ZPO §276(1) Satz 2) — ⚠ duration discrepancy

Pipeline-A: defendant, 2 weeks, filing, § 276 Abs. 1 S. 2 ZPO, legal_source=NULL, deadline_notes "Vom Gericht gesetzt, mindestens 2 Wochen".

Existing rule de_inf.erwidg on DE_INF: defendant, 6 weeks, DE.ZPO.276.1, "Klageerwiderung", is_court_set=false.

This is a substantive discrepancy. Both rules cite the same statutory anchor (ZPO §276(1) Satz 2), but:

• Pipeline-A modelled the statutory floor ("mindestens 2 Wochen") with is_court_set implicit (the deadline_notes said "Vom Gericht gesetzt").
• DE_INF models a typical court-practice heuristic (6 weeks is a common Munich/Düsseldorf LG setting, though 4-8 weeks is the realistic range).

The DE_INF rule is strictly more useful for a practitioner planning a defence schedule (the 2-week floor is rarely the actual deadline; the court order sets the real date). But it's technically wrong to mark is_court_set=false because the date is set by court order — the 6 weeks is a guess at what the court will set, not a statutory period.

No new rule needed, but two corrections are worth flagging on the existing rule:

• FLAG F4.2 (correctness): Set de_inf.erwidg.is_court_set = true. The deadline date is set by the court's Klageerwiderungsfrist order under §276(1) Satz 2, not by the statute directly. This matches how Schriftsatznachreichung (§296a) was flagged in docs/proposals/orphan-concepts-2026-05-15.md § 2.1 FLAG F8.
• FLAG F4.3 (heuristic transparency): 6 weeks vs. the statutory 2-week floor — the deadline_notes (DE) on de_inf.erwidg should probably say "Vom Gericht gesetzt, mindestens 2 Wochen (§ 276 Abs. 1 S. 2 ZPO); typische Praxis: 4-8 Wochen" rather than just rendering as a hard 6-week deadline. UX consideration, not a rule-shape question.

Neither change is a new rule; both are PATCH operations on the existing row via /admin/rules.

4.4 zpo.berufung (Berufung, ZPO §517) — ✓ redundant (twice over)

Pipeline-A: both, 1 month, filing, § 517 ZPO, DE.ZPO.517, deadline_notes "Notfrist ab Zustellung des vollständigen Urteils".

Existing rules:

• de_inf.berufung on DE_INF: both, 1 month, DE.ZPO.517. Same shape.
• de_inf_olg.berufung on DE_INF_OLG: both, 1 month, DE.ZPO.517. Same shape (covers the OLG-instance entry point).

Either rule covers it. Verdict: no gap.

4.5 Real gap (if m wants): Vertagungsantrag (ZPO §227)

The task brief mentioned "Vertagungsantrag" by name. Pipeline-A had no Vertagungsantrag rule (the zpo.vertanz rule code is a contraction of Verteidigungsanzeige, not Vertagungsantrag — see § 4.2). The current corpus has no Vertagungsantrag rule either.

ZPO §227 governs applications to adjourn a hearing ("Aufhebung und Verlegung von Terminen, Vertagung der Verhandlung"). §227.1 requires "erhebliche Gründe", §227.2 gives examples (verhinderter Anwalt etc.), §227.3 restricts adjournment of evidence hearings (Beweisaufnahme). There is no statutory deadline for filing a Vertagungsantrag — it's "as soon as the ground arises and, in practice, as early as possible before the hearing date". The application is court-discretionary (§227.1: "kann").

I would not recommend modelling Vertagungsantrag as a deadline_rule for the same reason as R.263 in § 3.2: there's no statutory deadline anchor; it's a checklist concept, not a calendar deadline. But m may have a different view — flag F4.4.

FLAG (F4.4): Should Vertagungsantrag be modelled? If yes, what anchor + duration? Most natural seed would be condition_expr={"flag":"with_vertagung"} on the relevant hearing rule (de_inf.termin, de_null.termin, etc.), is_court_set=true, no duration. But that's an oddly-shaped rule that produces no useful date.

Summary for Gap 4: 0 new rules. 4 FLAGs (F4.1-F4.4). The migration's "redundant — safe to drop" claim is confirmed for klage / vertanz / berufung. klageerw exposes a discrepancy on the existing de_inf.erwidg rule (is_court_set=false is wrong; 6-weeks heuristic should be transparent in notes) — both are PATCH operations on the existing row, not new rules. Vertagungsantrag is a separate concept that probably shouldn't be modelled as a deadline_rule.

---

5. Track A — Polish UPDATEs on existing rows (no new rules, no legal review)

Distinct from new rules, three existing rows could be PATCH'd via /admin/rules to improve correctness or transparency. None of these are required for the gap-fill to be considered "done" — they're flagged so they don't get lost if m wants to address them in the same ingest session.

#	Row	Field	From	To	Reason
P1	de_inf.klage (DE_INF)	legal_source	NULL	DE.ZPO.253	Polish; matches existing convention (Rule 1.1's UPC.RoP.19.1 etc.).
P2	de_inf.erwidg (DE_INF)	is_court_set	false	true	Correctness; deadline is court-order-set per ZPO §276(1) Satz 2.
P3	de_inf.erwidg (DE_INF)	deadline_notes (DE)	(current text)	"Vom Gericht gesetzt, mindestens 2 Wochen (§ 276 Abs. 1 S. 2 ZPO); typische Praxis: 4-8 Wochen"	Transparency; the 6-week duration is a heuristic, not statutory.

---

6. Track B — Genuinely new rule drafts (this proposal's substantive output)

#	Gap	Rule code	Proceeding (by role)	Source
1.1	1 (PO)	inf.prelim	UPC_INF	RoP 19.1
1.2	1 (PO)	rev.prelim	UPC_REV	RoP 19.1 i.V.m. R.46
2.1	2 (APP spawn)	inf.appeal_spawn	UPC_INF, spawn → UPC infringement-appeal proceeding	RoP 220.1(a) / R.224.1(a)
2.2	2 (APP spawn)	rev.appeal_spawn	UPC_REV, spawn → UPC infringement-appeal proceeding	RoP 220.1(a) / R.224.1(a)

Total new rules: 4. Plus 3 optional polish PATCHes in § 5. None of the proposed rules introduce new flag-name conventions (other than with_po and with_appeal, which mirror existing with_ccr / with_amend / with_cci).

Future-work (not this proposal)

• Order-appeals spawn (R.220.2 / R.220.3) from UPC_INF / UPC_REV / UPC_PI → UPC_APP_ORDERS (15-day track). Today UPC_APP_ORDERS has only standalone root rules.
• Cost-decision-appeal spawn (R.221.1) from UPC_INF / UPC_REV → UPC_COST_APPEAL.
• CCR-defendant PO (FLAG F1.4): claimant's 1-month PO window when receiving SoD-with-CCR — only if confirmed against real case law or m's read.
• R.263 (case amendment) and ZPO §227 (Vertagungsantrag): both court-discretionary, no statutory deadline — recommend leaving unmodelled (FLAGs F3.1, F4.4).
• DE_NULL / DE_NULL_BGH appeal spawns: PatG §110 chains DE_NULL → DE_NULL_BGH (Berufung BGH). Currently DE_NULL_BGH is a standalone tree rooted on de_null_bgh.urteil_bpatg. Same pattern as the UPC spawn gap. Out of brief scope but worth a parallel proposal.

---

7. Open questions / FLAGs index

For convenience, all **FLAG**-marked items in one place. m's decision is needed on each before /admin/rules ingest of the corresponding rule (or rule edit).

ID	Section	Question
F1.1	§ 1.1	Flag name for Preliminary Objection — with_po vs with_preliminary_objection vs prelim.
F1.2	§ 1.1	Priority for PO — optional (recommended) vs recommended (always-surface as sanity-check chip).
F1.3	§ 1.2	Legal-source citation for UPC_REV PO — UPC.RoP.19.1 (substantive) vs UPC.RoP.46 (operative). Recommend substantive.
F1.4	§ 1.2	Add a third PO rule for CCR-defendant (party=claimant, fires when with_ccr=true)?
F2.1	§ 2.1	Recommend not seeding ccr.appeal as a third rule — CCR appeal is covered by inf.appeal_spawn (one R.118 decision, one window). Confirm.
F2.2	§ 2.1	Anchor for spawn — parent_id = inf.decision (chain) vs trigger_event_id = 88 final_decision_service (event-rooted). Recommend chain.
F2.3	§ 2.1	Flag-gated (with_appeal) vs always-rendered. Recommend flag-gated to keep non-appealing timelines clean; SmartTimeline's "predicted" rendering of cross-proceeding rules is the alternative.
F3.1	§ 3.2	R.263 (case amendment) — confirm not modelled as a deadline_rule.
F4.1	§ 4.1	Polish P1: backfill de_inf.klage.legal_source = 'DE.ZPO.253'?
F4.2	§ 4.3	Polish P2: set de_inf.erwidg.is_court_set = true?
F4.3	§ 4.3	Polish P3: improve de_inf.erwidg.deadline_notes to expose the 6-week heuristic vs the 2-week statutory floor?
F4.4	§ 4.5	Vertagungsantrag (ZPO §227) — confirm not modelled.

---

8. Sources cited

Citation key	Reference
UPC.RoP.19.1	UPC Rules of Procedure, Rule 19(1) — Preliminary objection
UPC.RoP.19.7	UPC RoP Rule 19(7) — Court decides preliminary objection by order
UPC.RoP.25	UPC RoP Rule 25 — Lodging of Counterclaim for Revocation (cross-ref for FLAG F1.4)
UPC.RoP.30.1	UPC RoP Rule 30(1) — Application to amend the patent (cross-ref for § 3.1)
UPC.RoP.46	UPC RoP Rule 46 — Part 1 Chapter 1 (incl. R.19) applies mutatis mutandis to revocation actions
UPC.RoP.118	UPC RoP Rule 118 — Final decisions on the merits
UPC.RoP.151	UPC RoP Rule 151 — Cost decision (cross-ref for existing inf.cost_app)
UPC.RoP.220.1.a	UPC RoP Rule 220(1)(a) — Appeal against R.118 final decision
UPC.RoP.220.2	UPC RoP Rule 220(2) — Order appeals with leave (cross-ref, future work)
UPC.RoP.220.3	UPC RoP Rule 220(3) — Discretionary review (cross-ref, future work)
UPC.RoP.221.1	UPC RoP Rule 221(1) — Cost-decision appeal (cross-ref, future work)
UPC.RoP.224.1.a	UPC RoP Rule 224(1)(a) — Statement of appeal lodged within 2 months
UPC.RoP.224.2.a	UPC RoP Rule 224(2)(a) — Statement of grounds within 4 months
UPC.RoP.263	UPC RoP Rule 263 — Leave to change claim or amend case
DE.ZPO.227	ZPO §227 — Vertagung und Terminsänderung
DE.ZPO.253	ZPO §253 — Klageschrift
DE.ZPO.276.1	ZPO §276(1) — Verteidigungsanzeige (S.1) und Klageerwiderungsfrist (S.2)
DE.ZPO.517	ZPO §517 — Berufungsfrist (1 Monat ab Zustellung)

---

9. What's next (if m approves)

1. Decide the 12 FLAGs in § 7 (mostly flag names, priorities, and the three PATCH operations on existing rows). None require legal-side research — they're product/UX calls.
2. Confirm the appeal target's final proceeding-code post-t-paliad-204 rename. Until then, ingest using whatever code lives at id=11 (currently UPC_APP) and rename via mig if t-paliad-204 lands with a different code.
3. Ingest the 4 new rules via /admin/rules POST (Slice 11a backend, Slice 11b frontend). Each goes into lifecycle_state='draft' first. Promote to published after spot-checking via the calculator preview endpoint with a test project (e.g. UPC_INF with with_po=true should show the new inf.prelim row 1 month after the trigger date).
4. Optionally apply the 3 PATCHes in § 5 in the same session.
5. Verify spawn rendering end-to-end — the spawn_proceeding_type_id column is unused in live data today, so this is the first real consumer. The SmartTimeline projection (per internal/services/projection_service.go, memory 686f0b8c-…) early-returns on spawn rules when "we don't have that rule in our map" — that code path needs to actually render a spawn row now, not no-op. May require a Slice 7 follow-up tweak in projection_service.go to honour spawn_proceeding_type_id and surface the appeal proceeding's root deadline as a spawned child row.

Estimated corpus delta after ingest: Track B = 4 new rules → paliad.deadline_rules row count grows from 249 to 253. Track A polish = 3 row-level PATCHes (no row count change). One new is_spawn=true row goes live for the first time, exercising the previously-unused spawn_proceeding_type_id wiring.