RFC-008: Awb Administrative Procedures

Context

RFC-007 introduced hooks: articles that fire when another article’s produces annotation matches. This enables reactive execution: Awb 3:46 (reasoning requirement, motiveringsplicht) fires on any BESCHIKKING, Awb 6:7 (objection period, bezwaartermijn) fires on any BESCHIKKING, Awb 6:8 (start/einddatum) fires on any BESCHIKKING.

But an individual decision (beschikking) is not an instant computation. It is an administrative law (bestuursrecht) process that progresses through stages over time:

1. The interested party (belanghebbende) submits an application (aanvraag, Awb 4:1).
2. The administrative body (bestuursorgaan) investigates during the processing (behandeling) phase, possibly requesting additional information (Awb 4:5), possibly extending the decision deadline (beslistermijn, Awb 4:14). This can take weeks, months, or in complex cases years.
3. The administrative body (bestuursorgaan) makes a decision (besluit, Awb 1:3).
4. The decision (besluit) is communicated to the interested party (belanghebbende): notification (bekendmaking, Awb 3:41).
5. The objection period (bezwaartermijn) starts the day after notification (bekendmaking, Awb 6:8 lid 1) and runs for six weeks (Awb 6:7).
6. The interested party (belanghebbende) may file an objection (bezwaar, Awb 6:4).

If hooks fire without awareness of lifecycle stages, all Awb obligations trigger at once, including Awb 6:8 (objection period date calculation), which needs bekendmaking_datum. But notification (bekendmaking) hasn’t happened yet at decision time. Treating a missing bekendmaking_datum as “skip this hook gracefully” is a workaround, not a design.

The problem: the decision and the notification (bekendmaking) are different moments in time, with different inputs, producing different outputs, governed by different articles of law. They must not fire in the same execution step.

Who defines the lifecycle?

The lifecycle of an individual decision (beschikking) is not defined by the Vreemdelingenwet or the Zorgtoeslagwet. It is defined by the Algemene wet bestuursrecht (Awb), the General Administrative Law Act. That is the purpose of the Awb: to define the general administrative procedure that all administrative bodies (bestuursorganen) follow, regardless of which specific law they are executing.

The Awb defines stages. Specific laws fill in the content at each stage. Other laws (Termijnenwet, KB gelijkgestelde dagen) hook into specific stages. This relationship already exists in law; it needs to be expressed in the schema.

Terminology: procedure vs. lifecycle

In Awb terminology, what we describe here is a procedure, the objection procedure, the appeal procedure, the preparation procedure. The Awb never uses the word “lifecycle”; that is software engineering jargon.

However, in the Awb “procedure” typically refers to one phase (the objection (bezwaar) procedure, the appeal (beroep) procedure). The entire journey from application (aanvraag) to final/irrevocable (onherroepelijk) spans multiple procedures. In engineering, “lifecycle” captures this overarching concept: the full life of a decision (besluit) from birth (application) to final state (final/irrevocable (onherroepelijk), withdrawn (ingetrokken), or expired).

This RFC uses both terms deliberately:

• Procedure (procedure: in YAML): the domain term, used in the machine-readable specification because the YAML is a law specification and should speak the language of law.
• Lifecycle: used in prose when discussing the engineering concept of an entity progressing through states over time.

Both refer to the same thing: the Awb-defined sequence of stages that a decision (besluit) progresses through.

What goes wrong without lifecycle stages

1. Semantic confusion: Awb 6:8 hooks on BESCHIKKING but should only fire when notification (bekendmaking) has occurred. Without stages, parameter absence becomes implicit control flow.
2. Incorrect composition: hooks that belong to different stages fire in the same execution, mixing outputs from different moments in time.
3. No way to model waiting: an engine without stages cannot express “the decision (besluit) is taken, now waiting for notification (bekendmaking).”
4. Manual actions invisible: an administrative body (bestuursorgaan)‘s investigation, decision-making, and notification (bekendmaking) are real-world actions that the law regulates (decision deadline (beslistermijn) per Awb 4:13) but cannot be represented without stages.

Decision

The lifecycle is law

The Awb defines a lifecycle for administrative law (bestuursrecht) processes. This lifecycle is expressed in the YAML specification as a first-class construct. Laws do not define their own lifecycles; they declare which Awb-defined lifecycle they participate in through produces.

A lifecycle is a sequence of stages. Each stage:

• Has a name (e.g., AANVRAAG, BESLUIT, BEKENDMAKING)
• May produce outputs (computed automatically by the engine)
• May require inputs that come from external events (human decisions, real-world actions)
• May have hooks from other laws that fire when the stage is reached

Procedure selection

A single legal_character can have multiple procedure variants. Both a regular individual decision (beschikking) and a UOV (public consultation procedure) individual decision (beschikking) have legal_character: BESCHIKKING, but they follow different Awb procedures: the UOV omits objection (bezwaar) entirely (Awb 7:1 lid 1 sub d). Selecting the wrong procedure produces a legally invalid outcome.

The produces annotation gains an optional procedure_id field to disambiguate:

When procedure_id is omitted, the engine selects the default procedure for the legal_character. The Awb defines which procedure is the default.

Procedure definition in Awb

The Awb defines procedures for BESCHIKKING as machine-readable constructs. Multiple procedures can apply to the same legal_character:

The complete beschikking lifecycle

The diagram below shows the full individual decision (beschikking) lifecycle including parallel tracks. The main track (application (aanvraag) → appeal (beroep)) is strictly sequential. Three mechanisms can run in parallel: penalty payment (dwangsom, when the decision deadline (beslistermijn) expires), interim relief (voorlopige voorziening, after objection (bezwaar)/appeal (beroep)), and the administrative repair loop (bestuurlijke lus, within appeal (beroep)).

Hooks bind to stages, not just legal_character

The applies_to in hooks (RFC-007) gains a stage field:

This is the key insight: hooks apply to the Awb’s lifecycle, not to the specific law’s decision (besluit). The Aliens Act (Vreemdelingenwet) produces a BESCHIKKING and thereby enters the Awb lifecycle. The Vreemdelingenwet does not know about Awb 6:8. Awb 6:8 does not know about the Vreemdelingenwet. They are connected through the lifecycle defined by the Awb.

The besluit as state container

A decision (besluit) progresses through the Awb lifecycle and accumulates outputs at each stage. The decision (besluit) itself is the state container; there is no separate “case” or “zaak” (case file) abstraction. This follows the Awb, which defines everything in terms of the decision (besluit).

Execution becomes multi-step

When the engine executes a law that produces a BESCHIKKING:

Step 1: BESLUIT stage

Step 2: BEKENDMAKING stage (days/weeks later)

bekendmaking_datum is a genuine external event (the orchestration layer signals that notification (bekendmaking) has occurred). pasen_datum is also an external parameter, the computus algorithm is not in Dutch statute law, so the caller provides Easter Sunday’s date, consistent with the zero-domain-knowledge principle (RFC-007). Gelijkgestelde dagen (bridge days equated to public holidays) are resolved internally via IoC from harvested KB’s.

The engine yields between stages, returning:

• What it computed so far (accumulated outputs)
• What stage it’s at
• What inputs are needed to advance to the next stage

The orchestration layer persists the decision (besluit) state and feeds new inputs when they become available.

What is state, precisely?

The decision (besluit) state consists of:

The engine itself remains stateless in the sense that it does not maintain decision (besluit) state internally. The decision (besluit) state is an external record (database row, event store, file) managed by the orchestration layer. The engine receives the decision (besluit) state as input and returns the updated state as output.

This is important: the engine is still a pure function per stage. But the composition of stages into a decision (besluit) lifecycle is now explicit, governed by the Awb lifecycle definition, and persisted externally.

Automatic vs. manual stage transitions

Some stage transitions are automatic (engine computes the next stage’s outputs immediately). Others require external events:

The lifecycle definition distinguishes these: stages with requires fields that are not computable from previous outputs need manual input. The engine signals this by yielding with a description of what’s needed.

Why

Benefits

Conceptual correctness. The model matches the legal reality: a decision (besluit) is a process with stages, not an instant computation. The Awb defines the process, specific laws fill in the content.

Separation of concerns. Decision logic (Vreemdelingenwet) is separate from procedural logic (Awb lifecycle). Each law does what it’s supposed to do. The lifecycle connects them.

Temporal accuracy. Outputs are computed at the right moment. The objection period (bezwaartermijn) end date is calculated when the notification (bekendmaking) happens, not when the decision (besluit) is made. The feestdagenkalender uses the correct year for the notification (bekendmaking) date, not the decision (besluit) date.

Auditability. The decision (besluit) record shows exactly what happened at each stage, when, and with what inputs. This supports the reasoning requirement (motiveringsplicht, Awb 3:46) and provides a complete administrative trail.

Extensibility. New lifecycle stages can be added by the Awb without changing specific laws. New hooks can bind to any stage. The lifecycle is data (YAML), not code.

Real-world fidelity. The model naturally handles long-running processes (asylum decisions that take months), manual steps (administrative body (bestuursorgaan) investigation), and asynchronous events (notification (bekendmaking) by post).

Tradeoffs

Complexity. The engine moves from “pure function” to “state machine executor.” The orchestration layer must now manage decision (besluit) state persistence. This is a lot of implementation work.

Backward compatibility. Existing laws that produce BESCHIKKING without a lifecycle still work; they complete in a single stage. But new laws should use the lifecycle model. RFC-007 hooks without stage default to BESLUIT for backward compatibility.

State management. Decision (besluit) state must be persisted somewhere. The engine doesn’t dictate where (database, event store, file system), but the orchestration layer must handle it.

Alternatives Considered

Alternative 1: Implicit stages via parameter presence

• Awb 6:8 hooks on BESCHIKKING and skips when bekendmaking_datum is absent.
• Rejected: uses parameter absence as control flow. Semantically wrong, the hook doesn’t “fail to fire,” it fires at the wrong time. Silently skipping hooks hides the lifecycle.

Alternative 2: Multiple explicit executions (no lifecycle)

• Caller invokes the decision law first, then separately invokes Awb 6:8 with the results plus bekendmaking_datum.
• Rejected: makes the lifecycle invisible. The caller must know which Awb articles to invoke and in what order. The machine-readable specification should capture this.

Alternative 3: Event sourcing / CQRS

• The original poc-machine-law approach: a Case aggregate with event sourcing.
• Rejected: couples the law specification to infrastructure (aggregates, event types, projections). The lifecycle should be expressed in law YAML, not in infrastructure code. However, an event-sourced persistence layer is a valid implementation of decision (besluit) state management.

Implementation Notes

The procedure is a new top-level construct in the schema (procedure: key), defined at the law level (not article level). It references stages, and hooks reference stages.

The engine needs:

• Procedure index: maps (legal_character, procedure_id) → procedure_definition, loaded from Awb YAML. When procedure_id is omitted in produces, selects the procedure marked default: true.
• Stage-aware hook resolution: find_hooks gains a stage parameter. Hooks without stage default to BESLUIT.
• Decision (besluit) state: a struct carrying accumulated outputs, current stage, and context. Passed in and returned by the engine.
• Yield mechanism: the engine returns either a completed result or a “waiting for input” signal with the next stage’s requirements.

The decision (besluit) state is not stored in the engine. It is passed in by the caller and returned with updates. The engine remains a library, not a service.

Schema version: The procedure: top-level key and the procedure_id field on produces are new constructs not present in schema v0.4.0. They land in schema v0.5.0 (see the Schema Reference version history), alongside the hooks and overrides from RFC-007. Awb YAML files using procedure: must reference v0.5.0 or later.

Yield mechanism. The largest architectural change is the yield mechanism. The current engine returns Result<ArticleResult>, a terminal result. Multi-stage execution needs the engine to return either a completed result or a “yielded” state waiting for input to proceed to the next stage. Two implementation approaches:

1. New return type: enum ExecutionOutcome { Complete(ArticleResult), Yielded(StageState) }, replaces Result<ArticleResult> at the stage execution boundary. StageState carries accumulated outputs, current stage, and required inputs for the next stage.
2. Separate method: add execute_stage alongside the existing evaluate_article_with_service. The existing method remains unchanged for single-stage laws; execute_stage handles lifecycle-aware execution.

Decision (besluit) state is external (passed in, returned out), which is compatible with the stateless engine design. The engine uses &self (immutable borrows) for execution, so there is no architectural conflict with multi-stage execution, each invocation is still a pure function over its inputs.

Nested lifecycle recursion. A decision on objection (besluit op bezwaar) is itself a decision (besluit), creating recursive nesting. The engine’s cycle detection (ResolutionContext.visited) operates within a single invocation; cross-invocation nesting is the orchestration layer’s responsibility. The engine should provide a max_nesting_depth configuration to help the orchestration layer detect excessive recursion. In practice the Awb chain is naturally finite (individual decision (beschikking), decision on objection (besluit op bezwaar), appeal (beroep), higher appeal (hoger beroep)), but a configurable depth limit provides a safety net.

Open Questions

1. Do all decisions (besluiten) share the same lifecycle? Resolved: No. Each legal_character has its own lifecycle, defined by the relevant Awb chapters. A BESCHIKKING has application (aanvraag) → processing (behandeling) → decision (besluit) → notification (bekendmaking) → objection (bezwaar). A BESLUIT_VAN_ALGEMENE_STREKKING (general rule, besluit van algemene strekking) has a different procedure (Awb afdeling 3.4, Staatscourant publication, no objection (bezwaar), direct appeal (beroep)). The Awb defines these different procedures, the lifecycle definition in YAML follows the Awb structure per type.

2. Nested lifecycles. Resolved: An objection (bezwaar) is itself a decision (besluit, Awb 7:12), which starts its own lifecycle (with its own notification (bekendmaking), and possibility of appeal (beroep) before the administrative court (bestuursrechter)). The engine applies the same lifecycle pattern recursively, a decision on objection (besluit op bezwaar) enters the Awb lifecycle just like the original individual decision (beschikking). If a law inadvertently creates infinite recursion, that is a defect in the law, not in the engine.

   Note that RFC-007’s cycle detection does not cover this case. RFC-007 detects cross-law circular references within a single engine invocation (Law A → Law B → Law A). Nested lifecycle recursion (individual decision (beschikking) → decision on objection (besluit op bezwaar) → its own objection (bezwaar) → …) happens across separate engine invocations initiated by the orchestration layer. The orchestration layer is responsible for detecting excessive lifecycle nesting depth, not the engine. In the Awb this chain is naturally finite (individual decision (beschikking) → decision on objection (besluit op bezwaar) → appeal (beroep) → higher appeal (hoger beroep) terminates), but the orchestration layer should enforce a configurable maximum nesting depth as a safety measure.

3. Parallel stages. Resolved: The main lifecycle track (application (aanvraag) → processing (behandeling) → decision (besluit) → notification (bekendmaking) → objection (bezwaar) → appeal (beroep)) is strictly sequential, each stage depends on completion of the previous one. However, three genuinely parallel tracks can be spawned from the main lifecycle:

   • Penalty payment for late decision (dwangsom bij niet-tijdig beslissen, Awb 4:17-4:20): activates when the decision deadline (beslistermijn) expires without a decision (besluit). Runs parallel to the ongoing processing (behandeling) phase. The penalty payment decision (dwangsombesluit) is itself an individual decision (beschikking) with its own lifecycle.
   • Interim relief (voorlopige voorziening, Awb 8:81-8:87): activates after objection (bezwaar) or appeal (beroep) is filed. Runs parallel to the objection (bezwaar)/appeal (beroep) procedure. Can collapse into the main track via short-circuit ruling (kortsluiting, Awb 8:86) where the interim relief judge (voorzieningenrechter) immediately decides the main case.
   • Amendment decision (wijzigingsbesluit) pending objection (bezwaar)/appeal (beroep) (Awb 6:19): if the administrative body (bestuursorgaan) takes a new decision (besluit) while objection (bezwaar)/appeal (beroep) is pending, it is incorporated into the existing procedure.

   Additionally, two alternative paths exist as branches (not parallelism): direct appeal (rechtstreeks beroep, Awb 7:1a, skipping objection (bezwaar)) and the uniforme openbare voorbereidingsprocedure (Awb afdeling 3.4, replacing regular preparation with public consultation and eliminating objection (bezwaar)). The administrative repair loop (bestuurlijke lus, Awb 8:51a-8:51d) is a loop within appeal (beroep), not a parallel track, the administrative court (bestuursrechter) suspends appeal (beroep), the administrative body (bestuursorgaan) repairs the defect, then appeal (beroep) resumes. See Appendix A for the full procedure analysis and Appendix B for Mermaid state diagrams.

4. Decision deadline (beslistermijn) enforcement. Resolved: The decision deadline (beslistermijn) is calculated by a hook at the AANVRAAG stage, Awb 4:13 provides the default (“redelijke termijn”), specific laws override via lex specialis (same pattern as bezwaartermijn_weken). The engine does not enforce the deadline: if besluit_datum exceeds the decision deadline (beslistermijn), the engine continues normally but annotates the decision (besluit) with a warning. Exceeding the decision deadline (beslistermijn) does not invalidate the decision (besluit), it expands the lifecycle with new available paths for the interested party (belanghebbende): notice of default (ingebrekestelling, Awb 4:17), penalty payment (dwangsom, Awb 4:18), and appeal (beroep) against failure to decide in time (Awb 6:2 lid 1 sub b). These are modeled as conditional branches in the lifecycle state machine.

5. Withdrawal (intrekking) and revocation. Resolved: Withdrawal (intrekking, Awb 10:4-10:5) is a state transition in the original decision (besluit)‘s lifecycle, not a separate lifecycle. An individual decision (beschikking) continues to exist after notification (bekendmaking), it can be final/irrevocable (onherroepelijk), withdrawn (ingetrokken), amended, or expired. The withdrawal (intrekking) itself is a nested decision (besluit, same pattern as question 2): it requires motivation, notification (bekendmaking), and can be challenged via objection (bezwaar). The original individual decision (beschikking)‘s state changes as a consequence of the withdrawal (intrekking) decision completing its own lifecycle.

References

• RFC-007: Cross-Law Execution Model (hooks, overrides, temporal computation)
• Awb Hoofdstuk 3: Algemene bepalingen over besluiten (bekendmaking, motivering)
• Awb Hoofdstuk 4: Bijzondere bepalingen over besluiten (beslistermijn, aanvraag)
• Awb Hoofdstuk 6: Algemene bepalingen over bezwaar en beroep (termijnen)
• Awb Hoofdstuk 7: Bijzondere bepalingen over bezwaar en administratief beroep
• PG Awb - Artikel 4:17 (dwangsom)
• PG Awb - Artikel 8:81 (voorlopige voorziening)
• PG Awb - Artikel 8:86 (kortsluiting)
• PG Awb - Bestuurlijke lus (8:51a-8:51d)
• PG Awb - Afdeling 3.4 UOV
• PG Awb - Artikel 7:1a (rechtstreeks beroep)
• Glossary of Dutch Legal Terms

Appendix A: Detailed Awb Procedure Stages

A.1 Primary Decision Phase (Primair Besluit)

A.2 Dwangsom bij Niet-Tijdig Beslissen (Parallel Track)

This is a parallel track: the ingebrekestelling can be sent while BEHANDELING is still ongoing (once the beslistermijn has expired). The dwangsom runs concurrently with the ongoing decision procedure.

A.3 Bezwaar Phase (Rechtsbescherming)

A.4 Beroep Phase (Judicial Review)

A.5 Hoger Beroep

A.6 Voorlopige Voorziening (Awb 8:81-8:87: Parallel to bezwaar/beroep)

The voorlopige voorziening is the most important parallel track:

• Connexiteitsvereiste (8:81 lid 1): A voorlopige voorziening can only be requested if bezwaar or beroep has been filed (or simultaneously).
• Runs parallel: The voorlopige voorziening procedure runs concurrently with the bezwaar or beroep procedure. They are independent proceedings with the same judge.
• Kortsluiting (8:86): The voorzieningenrechter can, during the voorlopige voorziening hearing, immediately decide the main case (beroep) too. This collapses two parallel tracks into one.
• Timing: If bezwaar is decided before the voorlopige voorziening hearing, the request is converted to one connected to the subsequent beroep (8:81 lid 5).

A.7 Bestuurlijke Lus (Awb 8:51a-8:51d: Loop within beroep)

• During beroep, the court can issue a tussenuitspraak (interlocutory judgment) identifying a defect in the decision.
• The bestuursorgaan gets a deadline to repair the defect (by taking a new or amended decision).
• Meanwhile, the beroep procedure is suspended (not terminated).
• After repair (or failure to repair), the court resumes and issues the final uitspraak.

The bestuurlijke lus is a loop within the beroep phase, not a parallel track.

A.8 Uniforme Openbare Voorbereidingsprocedure (UOV, Awb Afdeling 3.4)

The UOV applies when a specific law prescribes it, or when the bestuursorgaan voluntarily chooses to apply it (3:10). Common for: environmental permits, spatial planning decisions, complex infrastructure.

When the UOV applies, bezwaar is excluded (7:1 lid 1 sub d). Rechtsbescherming goes directly to beroep.

A.9 Besluit van Algemene Strekking (BAS) Lifecycle

A besluit van algemene strekking (e.g., verordening, beleidsregel, ministeriele regeling) has a fundamentally different lifecycle:

Key differences from beschikking: no aanvraag (not applied for by belanghebbende), no bezwaar (Awb 8:3 lid 1 sub a excludes bezwaar/beroep against AVVs), no individual bekendmaking (publication in official gazettes), rechtsbescherming only via exceptieve toetsing.

Appendix B: Additional Lifecycle State Diagrams

B.1 Beschikking Lifecycle (Simplified, Complete)

B.2 Parallel Tracks (Focused Diagram)

B.3 UOV Procedure (Afdeling 3.4)

B.4 Besluit van Algemene Strekking Lifecycle