Skip to content

refactor(engine): extract hardcoded Dutch legal domain knowledge #472

@ehotting

Description

@ehotting

Context

The engine's design principle is "zero built-in domain knowledge" — everything should come from the law YAML files. However, several pieces of Dutch legal domain knowledge have leaked into the engine code. This issue tracks their identification and extraction.

Real domain knowledge (should extract)

# What Where Description
1 Eurocent rounding service.rs:1349 Engine treats type_spec.unit == "eurocent" as special: rounds float outputs to integer. Should be a generic TypeSpec mechanism where rounding behavior is declared in YAML, not hardcoded per unit name.
2 Gemeente_code scoping resolver.rs:285 Hardcoded field name gemeente_code for territorial filtering. Comment says "add provincie_code here later". Should be a generic scope field system driven by law metadata.
3 Regulatory layer hierarchy priority.rs:23-47 Full Dutch constitutional hierarchy hardcoded as rank ordering: Verdrag(0) > EuVerordening(1) > Grondwet(3) > Wet(4) > AMvB(6) > MinisterieleRegeling(7) > GemeentelijkeVerordening(9) > Beleidsregel(10) etc. 12 layers with hardcoded ranks used for lex superior resolution.
4 Delegation type validation service.rs:1460 Engine validates that an implementing regulation's regulatory_layer matches the open term's delegation_type. Knows which layers can delegate to which.

Borderline (discuss)

# What Where Notes
5 Legal character / AWB procedures article.rs:114, resolver The Produces struct and hook/procedure resolution framework. Values are strings from YAML, but the framework itself encodes Dutch administrative law concepts.
6 Date arithmetic clamping operations.rs:855 Jan 31 + 1 month = Feb 28. Cites HR ruling on termijnberekening. Standard calendar math but documented with Dutch legal reference.

Not domain knowledge (keep in engine)

# What Why keep
7 Age calculation (operations.rs:834) Standard whole-years definition
8 Day of week (operations.rs:1010) ISO 8601
9 Float→int safety (operations.rs:1147) Numerical correctness
10 Precision limits (operations.rs:26) Numerical correctness

Approach

Each extraction should be done as a separate PR. Possible approaches per item:

  1. Eurocent → generic type_spec rounding/coercion mechanism declared in YAML
  2. Gemeente_code → generic scope field system where laws declare their own scope dimensions
  3. Layer hierarchy → externalize rank table as configuration (or keep as engine knowledge with strong justification)
  4. Delegation type → derive validation rules from the hierarchy configuration

References

  • RFC-003: Inversion of Control
  • RFC-013: Execution Provenance
  • How It Works — concepts — states the zero-domain-knowledge principle

Supersedes #361.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions