RFC-020: Date-Aware Reference Resolution (as_of)

Depends on

RFC-007 (Cross-Law Execution Model), RFC-008 (Awb Administrative Procedures), RFC-013 (Execution Provenance), RFC-019 (Law End Dates (valid_to) and Expired-Reference Handling)

Context

Problem. RFC-019 selects law versions against a single global calculation_date. That answers “is this law in force today?”, but Dutch law routinely requires resolving a referenced law as it stood on a different date, and that date must propagate to everything resolved beneath the reference:

• Eerbiedigende werking / overgangsrecht: the old law stays applicable to existing cases (Aanwijzing 5.64). Real corpus case: CEK23’s staartzin, “met dien verstande dat zij van toepassing blijft op subsidies die voor die datum zijn verstrekt” (RFC-019 example A).
• Statische vs. dynamische verwijzing (Aanwijzing 3.47): a static reference freezes the text on a date and survives later change/repeal. Statutory formula: “zoals dat luidde op ” (e.g. Wet IB 2001 art. 10bis.1: “zoals dat luidde op 31 december 2012”); Aanwijzing 3.47 itself: “zoals zij op een gegeven tijdstip luidden”.
• Ex nunc / ex tunc: the heroverweging in bezwaar (Awb art. 7:11) is in beginsel ex nunc, with exceptions; which event date governs is Awb + jurisprudence.
• Lex mitior (Awb art. 5:46 lid 4) even requires two dates in one decision: a bestuurlijke boete compares the rule at the overtreding and at the beschikking and must apply the one most favourable to the offender.

The event dates already exist: RFC-008 (“the lifecycle is law”) carries aanvraag_datum, besluit_datum, bekendmaking_datum as stage inputs. What is missing is a way for a reference to be resolved at one of those dates instead of the global calculation_date.

Decision

Add an optional as_of to a cross-law reference / open-term resolution: the referenced law (and everything beneath it) is resolved at that date, using RFC-019’s valid_from/valid_to selection.

Grounding: the law and jurisprudence this RFC is built on

1. Three temporal axes

Conflating these is the root confusion:

2. as_of on a reference, propagating down the subtree

• Default = dynamic (no as_of): follows the global calculation_date, the hoofdregel (Aanwijzing 3.47) and current behaviour.
• as_of: <date | $param>: a literal date models a statische verwijzing; a parameter (e.g. $besluit_datum) models ex tunc / eerbiedigende werking.
• Propagation: inherited down the subtree, innermost wins. A statische verwijzing inside a dynamic context freezes only its own subtree.
• Recorded per reference: the resolved date and selected version go into trace and receipt (RFC-013), mirroring RFC-019 §4, the audit answer to “which version of which law was used, on what date basis”.

3. The applicable date is computed by law, not by engine heuristic

• The engine hard-codes no ex nunc/ex tunc/eerbiedigende-werking rules (RFC-015: zero domain knowledge). The applicable date is produced by executing the relevant rule (Awb 7:11 and/or the target law’s own overgangsrecht) and passed as as_of. Event dates and date arithmetic exist (RFC-008, RFC-007 §3).
• There is no single statutory “applicable-date” article:
  • the ex-nunc reading of art. 7:11 is jurisprudential: the standard arrest Greenpeace (heroverweging “op basis van de feiten en omstandigheden ten tijde van de heroverweging en op basis van het op dat moment geldende recht en beleid”, r.o. 6.2.3; exceptions in 6.2.4-6.2.9); Berg en Dal anchors the exception side;
  • the overgangsrecht default is onmiddellijke werking (Aanwijzing 5.61); its exceptions live in the specific law’s overgangsbepalingen (Aanwijzing 5.60).
• Therefore: codified date rules are modeled as machine_readable and computed like any output; the jurisprudential defaults (ex nunc; onmiddellijke werking) are a documented Engine Policy default (RFC-015) annotated with their basis, overridable per reference via as_of. This refines RFC-008’s ex-nunc default; it does not contradict it.

4. Multiple dates in one beoordeling: lex mitior

Art. 5:46 lid 4 Awb makes the lex-mitior principle (art. 1 lid 2 Sr) van overeenkomstige toepassing on bestuurlijke boetes, so one besluit op bezwaar can be ex nunc on the merits while the boete compares two dates. This proves as_of must be per-reference, not one global date.

Four boundaries keep it faithful and out of the engine:

• Mandatory, not a free choice, and “favourable” means favourable to the offender, never “best result” in general.
• Punitive sanctions only (afd. 5.4.1 Awb); a begunstigende beschikking has a single applicable version via ex nunc/ex tunc + overgangsrecht.
• Only on gewijzigd inzicht: the change must rest on the legislature’s altered judgment of punishability or severity (ABRvS 21-05-2025); a technical or temporary change does not trigger it.
• The selector lives in the law: the engine provides per-reference as_of + an operation; which is favourable is domain knowledge in the rule (fixed fine → MIN; conduct no longer punishable → IF). The engine never “tries all dates and optimizes”.

5. Interaction with hooks/overrides and IoC

Hook and override candidates are already filtered by valid_from (RFC-007); RFC-019’s valid_to and this RFC’s as_of apply identically: an ended candidate drops out, as_of selects the applicable version. A conformance case (RFC-014) locks this in.

The IoC pattern (open_terms/implements, RFC-003) follows the same propagation rule: when a reference carries as_of, implementing regulations for the referenced subtree are selected at the propagated date, not at calculation_date. A statische verwijzing to an older version of a law therefore uses the implementing regulations that were in force on that date, the legally correct reading, and the only one consistent with “inherited down the subtree”. Selecting implementations at calculation_date would be an undocumented exception to that rule.

Worked examples

A. Ex nunc vs. ex tunc: Awb 7:11 heroverweging

Whether the heroverweging applies the law of the beslissing op bezwaar moment (ex nunc) or of the original besluit moment (ex tunc) is selected by which event date is passed as as_of:

(Illustrative: the corpus vreemdelingenwet_2000 does not yet expose verblijfsvergunning_verleend, and Awb 7:11 is not yet in the corpus Awb; the modeled chain today is the bezwaartermijn. The example shows the mechanism; modeling the heroverweging is implementation work.)

B. Statische verwijzing: frozen text by date

C. Lex mitior: two dates, take the favourable one (art. 5:46 lid 4 Awb)

Two inputs resolve the same output at the two legally relevant moments; the selector (MIN, since for a fixed fine the lower amount is favourable) lives in the law. Stays within the existing operation grammar: only as_of is new.

($besluit_datum is the existing RFC-008 BEHANDELING stage input. $overtreding_datum is not: a boete procedure needs its own lifecycle that adds it as a stage input; that lifecycle is future RFC-008 extension work, alongside modeling this pattern.)

Still open

• The precise form of the Engine Policy default for ex nunc / onmiddellijke werking (one policy flag vs. per-procedure defaults in the RFC-008 lifecycle), and how it carries its jurisprudential basis.
• Whether lex mitior warrants a reusable library pattern rather than hand-written MIN/IF-over-two-as_of per boete-law.
• Cross-law-derived validity (extrinsic termination): RFC-019 keeps valid_to static and defers a “terminates” mechanism that derives a law’s end from the terminating instrument. That is the same cross-law, date-aware territory as as_of and belongs alongside this model.
• No reset to calculation_date inside an inherited as_of context: propagation (§2) is “inherited down the subtree, innermost wins”, and calculation_date is an engine-level value that is not addressable as a $-parameter in law YAML, so a referenced law cannot declare “always resolve my sub-references at the current date” (e.g. a dynamic rate table). This is a deliberate constraint for temporal consistency. An explicit escape would need an engine change (injecting calculation_date as a reserved parameter, with name-collision and nested-subtree semantics to settle), not just a schema addition, so it stays out of scope until a real corpus case demands it.
• as_of: $param with the parameter absent at runtime: silently falling back to calculation_date would hide a caller error and contradict RFC-015’s zero-domain-knowledge policy, because the engine cannot know whether the date was optional. The expected resolution is a strict resolution error (mirroring how missing required inputs already fail), but this must be settled in the implementation.

Testing

Extends the cucumber-rs harness (features/bezwaartermijn.feature, features/einddatum.feature):

1. ex nunc vs ex tunc: the same reference resolves to different versions for as_of: $besluit_datum vs the default, with two versions of the target loaded.
2. statische verwijzing: a fixed-date as_of resolves correctly when calculation_date is past the target’s valid_to but as_of is within the validity window (interaction with RFC-019).
3. lex mitior: a boete computed at two as_of dates yields the favourable (lower) result.
4. propagation: an inner reference without as_of inherits the outer one; an inner as_of overrides for its subtree.
5. failure path: as_of past the target’s valid_to (e.g. as_of: '2027-01-01' on a law with valid_to: '2026-12-31') yields a RFC-019 §3 SelectionReason error (EndedOn) reported against the resolved date, never a silent miss.
6. failure path, symmetric: as_of before the target’s valid_from (law not yet in force, e.g. an overtreding_datum predating the law) yields the corresponding SelectionReason error (NotYetInForce).
7. IoC propagation: with an outer as_of, implementing regulations (open_terms/implements, RFC-003) are selected at the propagated date, not at calculation_date, the §5 rule, with two versions of an implementing regulation loaded.

Plus as_of cases in the Temporal conformance level (RFC-014).

Why

Benefits

• Legally faithful references: ex nunc/ex tunc, statische verwijzing and eerbiedigende werking are modeled by which date a reference resolves at, grounded in Awb, Aanwijzingen and jurisprudence, not in engine heuristics.
• Composes with RFC-019: a static as_of can resolve an earlier version even after the target’s valid_to; an ended reference at the default date still fails honestly (RFC-019 §3, stated relative to the resolved date).
• Reuses existing machinery: event dates (RFC-008), date arithmetic (RFC-007), version selection (RFC-019); only as_of and its propagation are new.

Tradeoffs

• Second date dimension: as_of must thread through cross-law resolution, the reference subtree, cycle detection and the memoization cache (the key must include the resolution date, or example C’s two lookups of the same output would collide).
• Policy surface: the jurisprudential defaults must be expressed and audited as Engine Policy rather than code.

Alternatives Considered

• One global date for all version selection (status quo + RFC-019). Rejected: cannot express ex tunc, statische verwijzing or eerbiedigende werking; each resolves a reference at a non-global date.
• Engine “tries all dates and picks the best” for lex mitior. Rejected: deciding what counts as favourable is domain knowledge; the two moments and the selector belong in the law (§4).
• Dates computed outside the engine. Rejected for the reason RFC-007 rejected it: the date rules (Awb, overgangsrecht) are themselves law and should be executed.

Implementation Notes

• Schema: additive as_of on source (literal date or $-parameter), encoded as the existing union pattern oneOf: [variableReference, {type: string, format: date}] so malformed dates and unprefixed parameter names fail validation. as_of is only meaningful when regulation is present (there is no law to version-select otherwise); the schema must make that conditional (e.g. if: {required: [regulation]}), not silently ignore it. source is additionalProperties: false, so this needs a new minor schema version (additive, non-breaking).
• Engine: thread as_of (default calculation_date) through the cross-law resolution path; inherit down the subtree, innermost wins; reuse RFC-019’s selection at the resolved date; include the resolved date in memoization and cycle-detection keys; report selection failures (RFC-019 §3 SelectionReason) relative to the resolved date. Date-keyed cycle detection catches same-date self-reference; a regressive chain (A at D referencing A at D−1, and so on) has a unique key per step and is backstopped by the engine’s existing cross-law depth limit (MAX_CROSS_LAW_DEPTH), a deliberate constraint, since static corpus YAML cannot generate ever-older as_of values itself.
• Receipt/trace: record the resolved date per reference (RFC-013).
• Policy: an Engine Policy entry for the ex-nunc / onmiddellijke-werking default, annotated with its jurisprudential basis.

References

• RFC-019 Law End Dates · RFC-001 YAML Schema · RFC-003 IoC/temporal filter · RFC-007 Cross-Law Execution · RFC-008 Awb Administrative Procedures · RFC-013 Execution Provenance · RFC-014 Conformance · RFC-015 Engine Policy
• Law, jurisprudence and drafting conventions: see the Grounding table above.
• Glossary of Dutch Legal Terms