Domain-Rules Anti-Patterns First
When modeling a legal/regulatory domain (pensions, taxes, insurance, social law etc.), the AI knows the positive entitlement/calculation/benefit rules reasonably well from training data. But the blocking clauses (anti-patterns, exceptions, traps, minimum requirements) — these are the rules where the AI is most likely to model incorrectly. They're often spread across multiple paragraphs of a statute, depend on specific personal constellations, and aren't part of typical "summary" content.
This skill exists because in a single pension-app session, three different anti-patterns had to be corrected that were initially missed:
- §51 para 3a SGB VI — unemployment-benefit time does NOT count toward the 45-year qualifying period for "particularly long-time insured" (block against last-minute unemployment-benefit application)
- §166 SGB VI — unemployment benefits DO accrue earnings points (these had been modeled as "negligible")
- §34 para 1 EStG — one-fifth rule for severance with cheaper-option-check (would have been modeled as a pure tax break)
Plus methodologically related from earlier sessions: brand-foundation origin question (name origin: pet vs initial); multi-choice vs open-question style.
When to use
- Modeling pension calculation (earnings points, qualifying periods, deductions, valuation factor, taxable portion)
- Modeling income tax (tariff formulas, allowances, special expenses, advertising costs, extraordinary income)
- Modeling insurance contributions / social security (health/care/pension/unemployment)
- Modeling inheritance/gift tax, allowances, tax classes
- Modeling contract-law constructs with statutory constraints
- Any "life-decision" app where a wrong calculation costs the user real money
When NOT to use
- Generic programming domains (database design, API contracts, file formats) — no anti-patterns in the legal sense
- Pure math/physics modeling (statics, heat conduction, circuits) — natural laws without blocking clauses
- Internal business logic where you ARE the rule-author — you know the traps yourself
- Quick prototypes where accuracy doesn't matter — the skill discipline slows down meaningful iteration
Iron rule
Before implementing a positive calculation rule, explicitly ask about blocking clauses + anti-patterns + minimum requirements.
Concrete question to the user:
Before I implement this [pension/tax/insurance] calculation — do you know of any blocking clauses or special rules I need to consider? Specifically:
- What conditions must be met (qualifying periods, contribution years, age, relationship status)?
- Are there blocks that typically kick in "shortly before the goal" (blocking last-minute strategies)?
- What special rules apply to special cases (special supply, regional valuation, severe disability etc.)?
- Is there a "cheaper-option check" or choice between several procedures?
The user knows this from their own pension statements, tax assessments, contracts with tax advisors or self-research — they have the relevant domain knowledge that the positive calculation alone does not capture.
Domain-specific cheat sheets — typical anti-patterns
Pensions (SGB VI — German pension code) — typical blocks
| Block |
Paragraph |
Effect |
| 45-year qualifying period for particularly long-time insured |
§51 para 3a SGB VI |
Unemployment-benefit time does NOT count (max the last 2 years before pension) |
| Early old-age pension long-time insured |
§236 SGB VI |
Deduction 0.3% per month before regular retirement age (max 14.4%) |
| Postponing past regular retirement age |
§77 SGB VI |
Bonus 0.5% per month (max not capped) |
| Pension splitting on divorce |
§76 SGB VI |
EP transfer on divorce, permanent (no "reversal" if ex-spouse dies before pension) |
| Regional valuation factor |
§256a SGB VI |
Decreases continuously, 2025 = 1.0 (alignment reached) |
| Unemployment benefits accrue EP |
§166 SGB VI para 1a |
80% × contribution ceiling / average earnings ≈ 1.5 EP/year |
| Additional-earnings limit (early pension) |
§34 SGB VI |
Fully abolished since 2023 |
Tax (EStG — German income tax code) — typical blocks / options
| Anti-pattern |
Paragraph |
Effect |
| One-fifth rule severance |
§34 para 1 EStG |
Cheaper-option check against regular taxation — at high taxable income often no advantage |
| Progression clause |
§32b EStG |
Tax-free income (unemployment benefits, child allowance, foreign income) raises tax rate on other income |
| Loss-offset restriction capital assets |
§20 para 6 EStG |
Stock losses only against stock gains |
| Speculation period private |
§23 EStG |
1 year for securities (abolished for stocks since 2009), 10 years for real estate |
| Advertising costs rental & lease |
§9 EStG |
Depreciation 2% (buildings), maintenance immediately, acquisition/production costs via depreciation |
| Taxable portion pension |
§22 No. 1 EStG |
Stepwise increase, 100% from pension start 2058 |
| Splitting tariff |
§32a para 5 EStG |
Only for married couples, joint assessment |
Social insurance — typical blocks
| Block |
Effect |
| Unemployment-benefit suspension |
12 weeks for own resignation without good reason (can be avoided via termination agreement, but risk clauses in agreement) |
| Severance suspension |
if severance above certain limits → unemployment-benefit claim delayed by months |
| Contribution ceiling / insurance-mandatory limit |
annually adjusted, affects health/care/pension/unemployment contributions |
| Assessment basis unemployment benefit |
80% of assessment earnings (capped by contribution ceiling) |
Workflow
Phase 1: Domain identification
- Which legal areas are affected? (e.g. pensions = SGB VI, taxes = EStG, unemployment = SGB III)
- Which person-specific constellations are relevant? (birth year, insurance status, contribution biography, family status)
Phase 2: Anti-pattern catalog
- Load the matching cheat sheet above (or extend it)
- Explicitly ask the user about blocks that apply in their specific constellation
- Document in the code comment AND in the spec: which block is HOW modeled
Phase 3: Positive rules (only now)
- Implement the calculation formulas
- Validate against the user's sheet / pension statement / tax assessment (control calculation)
Phase 4: Transparency
- UI must show which blocks took effect (e.g. "7.2% deduction due to 45-year block" instead of just "gross pension XYZ")
- Unmet entitlement preconditions explicitly displayed
Anti-patterns
- ❌ Only modeling the positive entitlement conditions from Wikipedia/training — you will miss the specific blocks
- ❌ "Negligible" assumptions without user confirmation — e.g. "unemployment benefits don't accrue EP" was wrong
- ❌ Flat tax rate instead of real tariff — flat is OK for quick estimate, but for decision apps the real §32a formula is needed
- ❌ Assumption: all special provisions are included in standard calculation — e.g. pension splitting, special supply, regional valuation
- ❌ Modeling without paragraph reference — code comment should contain the §-keyword so future iteration can find the rule
- ❌ Pure calculation without entitlement-condition check — user should see why which variant has which conditions
Real-world impact
- Pension-app session: 3 substantial user corrections due to missing block consideration. Plan B-A was first modeled as "deduction-free" (WRONG), then with 7.2% deduction correctly (user pointed to §51 para 3a). Plan B-A → Plan B-B difference was corrected from 10k lifetime to 170k lifetime. Without this correction, the user would have built a wrong negotiation strategy.
- Related patterns from earlier sessions: brand-foundation origin question; multi-choice vs open-question (user style prefers open).
- Lesson: in domain modeling, the
ask the blocks first discipline is the lever against 3-4 user corrections per session.
1---2name: domain-rules-anti-patterns-first3description: Use when modeling a domain that has formal legal/regulatory rules — pensions, taxes, insurance, employment law, inheritance law, social law, healthcare law, unemployment benefits/social benefits, contract law, civil code, tax code, social code, etc. Trigger on phrases like "calculate pension", "model tax", "insurance contribution", "entitlement to X", "qualifying period", "assessment basis", "retirement age", "deduction", "inheritance", "gift tax", "unemployment benefits", "old-age pension", "survivor's pension", "benefits suspension period", "one-fifth rule", "progression clause", "tax form V", "advertising costs", "special expenses", "allowance", "contribution assessment limit". Do NOT load for general programming domain modeling (database schemas, API contracts), for pure math/physics modeling (no legal/regulatory aspect), or for project-internal business logic where you are the rule-author.4---56# Domain-Rules Anti-Patterns First78When modeling a legal/regulatory domain (pensions, taxes, insurance, social law etc.), the AI knows the positive entitlement/calculation/benefit rules reasonably well from training data. But the **blocking clauses** (anti-patterns, exceptions, traps, minimum requirements) — these are the rules where the AI is most likely to model incorrectly. They're often spread across multiple paragraphs of a statute, depend on specific personal constellations, and aren't part of typical "summary" content.910This skill exists because in a single pension-app session, three different anti-patterns had to be corrected that were initially missed:11121. **§51 para 3a SGB VI** — unemployment-benefit time does NOT count toward the 45-year qualifying period for "particularly long-time insured" (block against last-minute unemployment-benefit application)132. **§166 SGB VI** — unemployment benefits DO accrue earnings points (these had been modeled as "negligible")143. **§34 para 1 EStG** — one-fifth rule for severance with cheaper-option-check (would have been modeled as a pure tax break)1516Plus methodologically related from earlier sessions: brand-foundation origin question (name origin: pet vs initial); multi-choice vs open-question style.1718## When to use1920- Modeling pension calculation (earnings points, qualifying periods, deductions, valuation factor, taxable portion)21- Modeling income tax (tariff formulas, allowances, special expenses, advertising costs, extraordinary income)22- Modeling insurance contributions / social security (health/care/pension/unemployment)23- Modeling inheritance/gift tax, allowances, tax classes24- Modeling contract-law constructs with statutory constraints25- Any "life-decision" app where a wrong calculation costs the user real money2627## When NOT to use2829- Generic programming domains (database design, API contracts, file formats) — no anti-patterns in the legal sense30- Pure math/physics modeling (statics, heat conduction, circuits) — natural laws without blocking clauses31- Internal business logic where you ARE the rule-author — you know the traps yourself32- Quick prototypes where accuracy doesn't matter — the skill discipline slows down meaningful iteration3334## Iron rule3536**Before implementing a positive calculation rule, explicitly ask about blocking clauses + anti-patterns + minimum requirements.**3738Concrete question to the user:3940> Before I implement this [pension/tax/insurance] calculation — do you know of any blocking clauses or special rules I need to consider? Specifically:41>42> 1. What conditions must be met (qualifying periods, contribution years, age, relationship status)?43> 2. Are there blocks that typically kick in "shortly before the goal" (blocking last-minute strategies)?44> 3. What special rules apply to special cases (special supply, regional valuation, severe disability etc.)?45> 4. Is there a "cheaper-option check" or choice between several procedures?4647The user knows this from their own pension statements, tax assessments, contracts with tax advisors or self-research — they have the relevant domain knowledge that the positive calculation alone does not capture.4849## Domain-specific cheat sheets — typical anti-patterns5051### Pensions (SGB VI — German pension code) — typical blocks5253| Block | Paragraph | Effect |54|---|---|---|55| 45-year qualifying period for particularly long-time insured | §51 para 3a SGB VI | Unemployment-benefit time does NOT count (max the last 2 years before pension) |56| Early old-age pension long-time insured | §236 SGB VI | Deduction 0.3% per month before regular retirement age (max 14.4%) |57| Postponing past regular retirement age | §77 SGB VI | Bonus 0.5% per month (max not capped) |58| Pension splitting on divorce | §76 SGB VI | EP transfer on divorce, permanent (no "reversal" if ex-spouse dies before pension) |59| Regional valuation factor | §256a SGB VI | Decreases continuously, 2025 = 1.0 (alignment reached) |60| Unemployment benefits accrue EP | §166 SGB VI para 1a | 80% × contribution ceiling / average earnings ≈ 1.5 EP/year |61| Additional-earnings limit (early pension) | §34 SGB VI | Fully abolished since 2023 |6263### Tax (EStG — German income tax code) — typical blocks / options6465| Anti-pattern | Paragraph | Effect |66|---|---|---|67| One-fifth rule severance | §34 para 1 EStG | Cheaper-option check against regular taxation — at high taxable income often no advantage |68| Progression clause | §32b EStG | Tax-free income (unemployment benefits, child allowance, foreign income) raises tax rate on other income |69| Loss-offset restriction capital assets | §20 para 6 EStG | Stock losses only against stock gains |70| Speculation period private | §23 EStG | 1 year for securities (abolished for stocks since 2009), 10 years for real estate |71| Advertising costs rental & lease | §9 EStG | Depreciation 2% (buildings), maintenance immediately, acquisition/production costs via depreciation |72| Taxable portion pension | §22 No. 1 EStG | Stepwise increase, 100% from pension start 2058 |73| Splitting tariff | §32a para 5 EStG | Only for married couples, joint assessment |7475### Social insurance — typical blocks7677| Block | Effect |78|---|---|79| Unemployment-benefit suspension | 12 weeks for own resignation without good reason (can be avoided via termination agreement, but risk clauses in agreement) |80| Severance suspension | if severance above certain limits → unemployment-benefit claim delayed by months |81| Contribution ceiling / insurance-mandatory limit | annually adjusted, affects health/care/pension/unemployment contributions |82| Assessment basis unemployment benefit | 80% of assessment earnings (capped by contribution ceiling) |8384## Workflow8586### Phase 1: Domain identification87- Which legal areas are affected? (e.g. pensions = SGB VI, taxes = EStG, unemployment = SGB III)88- Which person-specific constellations are relevant? (birth year, insurance status, contribution biography, family status)8990### Phase 2: Anti-pattern catalog91- Load the matching cheat sheet above (or extend it)92- Explicitly ask the user about blocks that apply in their specific constellation93- Document in the code comment AND in the spec: which block is HOW modeled9495### Phase 3: Positive rules (only now)96- Implement the calculation formulas97- Validate against the user's sheet / pension statement / tax assessment (control calculation)9899### Phase 4: Transparency100- UI must show which blocks took effect (e.g. "7.2% deduction due to 45-year block" instead of just "gross pension XYZ")101- Unmet entitlement preconditions explicitly displayed102103## Anti-patterns104105- ❌ **Only modeling the positive entitlement conditions from Wikipedia/training** — you will miss the specific blocks106- ❌ **"Negligible" assumptions without user confirmation** — e.g. "unemployment benefits don't accrue EP" was wrong107- ❌ **Flat tax rate instead of real tariff** — flat is OK for quick estimate, but for decision apps the real §32a formula is needed108- ❌ **Assumption: all special provisions are included in standard calculation** — e.g. pension splitting, special supply, regional valuation109- ❌ **Modeling without paragraph reference** — code comment should contain the §-keyword so future iteration can find the rule110- ❌ **Pure calculation without entitlement-condition check** — user should see why which variant has which conditions111112## Real-world impact113114- **Pension-app session**: 3 substantial user corrections due to missing block consideration. Plan B-A was first modeled as "deduction-free" (WRONG), then with 7.2% deduction correctly (user pointed to §51 para 3a). Plan B-A → Plan B-B difference was corrected from 10k lifetime to 170k lifetime. Without this correction, the user would have built a wrong negotiation strategy.115- **Related patterns from earlier sessions**: brand-foundation origin question; multi-choice vs open-question (user style prefers open).116- **Lesson**: in domain modeling, the `ask the blocks first` discipline is the lever against 3-4 user corrections per session.
Ed3Design