Behavior DSL — Regulations as Versioned Artifacts

The scenario

On January 1, 2027, Boverket publishes an updated BBR (Boverkets Byggregler) with stricter energy requirements for climate zone III (northern Sweden). Suppose the maximum allowed specific energy use for residential buildings drops from 90 kWh/m^2 to 80 kWh/m^2. This change affects every house design that Trähusfabriken has compiled for delivery sites north of Sundsvall.

In a traditional workflow, someone reads the Boverket announcement, manually checks which projects are affected, and reruns the energy calculations. Some projects get missed. Some get rechecked unnecessarily.

With Behavior DSL, the BBR is not embedded in code. It is a versioned, sealed artifact — a ruleset expressed in a structured language, validated, and evaluated by a deterministic step. When the BBR artifact changes, the system knows exactly what to invalidate.

  BBR v2026 (sealed)                    BBR v2027 (sealed)
  sha256:4a12...                        sha256:8f93...
  ┌────────────────────┐                ┌────────────────────┐
  │ climate_zone_III:  │                │ climate_zone_III:  │
  │   max_energy: 90   │   ──update──→  │   max_energy: 80   │
  │   ...              │                │   ...              │
  └────────┬───────────┘                └────────┬───────────┘
           │                                     │
           ▼                                     ▼
  Uses BBR v2026                        Uses BBR v2027
  → previous result valid               → must re-evaluate
    (BBR fingerprint unchanged)           (BBR fingerprint changed)

The fingerprint of every energy check includes the BBR version used. When the BBR fingerprint changes, every energy check that used the old BBR must re-run. Every design that used only unchanged climate zones (I and II) still reuses its previous result — their specific rules haven’t changed.

The system can report: “47 designs used BBR v2026 climate zone III rules. Of those, 31 still pass under v2027. 16 require design modifications.” No manual triage. No missed projects.

Key properties

The boundary between data and logic. The BBR is neither pure data (it contains conditional logic: if building type is residential AND climate zone is III, then max energy is 85) nor pure code (it is a versioned, inspectable, diffable artifact). The Behavior DSL makes this boundary explicit: the rule engine is a step; the ruleset is versioned reference data. Both are fingerprinted. Both participate in reuse decisions. But they change at different rates — the engine changes rarely, the rules change when regulations update.

Automatic propagation of regulatory changes. The runtime does not need a special “regulatory change” feature. The propagation falls out of fingerprint-based reuse: change an input artifact, and all downstream computations that depend on it must re-run. This is the same mechanism that handles updated emission factors in the VSME pipeline or updated dependency versions in LodeTime. The generality of the pattern is the point.

Diffable regulations. Because both BBR v2026 and BBR v2027 are sealed artifacts with structured source, the change is diffable: “climate zone III max_energy changed from 95 to 85; all other zones unchanged.” This diff is an artifact itself — it can be attached to the re-evaluation run as context for why the run was triggered.

Composability with Population Sim. When the BBR updates, the evolutionary optimization can be re-run against the new rules. Candidates that passed under the old rules but fail under the new ones are automatically excluded. The fitness landscape shifts, and the optimizer adapts — but the history of the old landscape is preserved for comparison.