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:
- Eurocent → generic
type_spec rounding/coercion mechanism declared in YAML
- Gemeente_code → generic scope field system where laws declare their own scope dimensions
- Layer hierarchy → externalize rank table as configuration (or keep as engine knowledge with strong justification)
- 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.
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)
service.rs:1349type_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.resolver.rs:285gemeente_codefor territorial filtering. Comment says "add provincie_code here later". Should be a generic scope field system driven by law metadata.priority.rs:23-47service.rs:1460regulatory_layermatches the open term'sdelegation_type. Knows which layers can delegate to which.Borderline (discuss)
article.rs:114, resolverProducesstruct and hook/procedure resolution framework. Values are strings from YAML, but the framework itself encodes Dutch administrative law concepts.operations.rs:855Not domain knowledge (keep in engine)
operations.rs:834)operations.rs:1010)operations.rs:1147)operations.rs:26)Approach
Each extraction should be done as a separate PR. Possible approaches per item:
type_specrounding/coercion mechanism declared in YAMLReferences
Supersedes #361.