Chemistry of Transport Policy

Tools in the Virtual Lab

• Scenario Examples: Load pre-built examples to understand how real-world policies are modeled.
• Policy Canvas: This is your main workspace. Build policies here and toggle between simplified names (`AddCap`) and formal symbols (`ΔC⁺`).
• Molecular Composer: Build a policy atom-by-atom. Select an action, define its properties, then add it to the canvas.
• AI Prompt Generator & Validator: Use the generator to translate plain language into a formal prompt for an AI, and use the validator to check any policy string for correctness.

Principles

• Atomicity: All interventions are expressed as atomic actions with defined semantics (e.g., ΔC⁺(ij) for capacity addition).
• Composability: Complex policies are molecular sequences of atomic actions, governed by logical operators (`→`, `∪`, `¬`).
• Reproducibility: Policies can be simulated, audited, and replicated across contexts. Transparency is embedded in the syntax.
• Equity by Design: Distributive impacts can be evaluated before implementation, not after harm.

By formalizing policy in a symbolic language, we eliminate ambiguity and reduce the discretionary power of authorities to experiment on the public. The grammar becomes a safeguard, ensuring that every intervention is legible, testable, and justifiable.

📜 Toward a Scientific Language of Transport Policy

Transport policy has long been shaped by intuition, authority, and political expediency. This formal grammar, proposed by Dr. Kardi Teknomo in his monograph "Ideal Flow Network for Transportation Research - Unveiling the Hidden Secret of Nature to Solve Traffic Congestion" (published by Springer Nature), transforms policy into a repeatable, objective, and testable discipline.

🛠️ Core Principles of the Language

1. A Policy is a Commitment (No 'OR' logic): A policy must be a single, unambiguous commitment. Any optionality or "OR" condition must be defined as a separate, distinct scenario. For example, a base policy and a policy "with an optional bypass" must be written as two separate molecules.
2. Composition over Definition (No new atoms): Complex actions must be composed from the fundamental atomic set, not defined as new atoms. This ensures every policy is reducible to its core, auditable components.
3. Hierarchy and Modularity: A complex molecule can be composed of atoms and other, simpler molecules. This allows for building layered, modular policies that remain transparent and auditable.

For example, a high-level concept like "Activate Ramp Meter" is not a new atom. It is a molecule composed of fundamental actions. A complex policy for ramp metering with an HOV bypass can be built hierarchically:

// First, define a base molecule
BaseMetering ≡ TempRedCap(all_ramps,HOV)@06:30-10:00

// Then, compose a more complex molecule using the base
HOVBypassPolicy ≡ BaseMetering ∪ ¬ TempRedCap(all_ramps,HOV2)
                

High-Level Concept	Molecular Translation	Interpretation
MeterOn	TempRedCap(ramp)	Ramp metering is fundamentally a temporary capacity reduction.
HOVBypass	¬ TempRedCap(ramp, HOV)	A bypass is the logical negation of the metering action for a specific vehicle class.
IncidentOverride	TempOptSig(ramp, incident)	An incident override is a temporary optimization of the ramp's signal.

The Policy Language Grammar

A policy is a string of Atoms and Operators. Think of atoms as the "nouns" and "verbs" of your policy, and operators as the "conjunctions" that connect them.

Atomic Actions

An atom is the smallest unit of change. The full syntax for an atom is:

coeff*Action(location,mode)@time

Each action must be followed by a single argument in parentheses: Action(argument)

Component	Requirement	Example
coeff	Optional number. Omitted if 1.	3*AddCap(...)
Action	Required. The type of change in Name or Symbol. Each atomic action name must be one of the following: AddCap ≡ ΔC⁺, RedCap ≡ ΔC⁻, AddLink ≡ ΔA⁺, RemLink ≡ ΔA⁻, RevDir ≡ ΔA↔, AddNode ≡ Δ𝒱⁺, RemNode ≡ Δ𝒱⁻, IncSpeed ≡ ΔU⁺, DecSpeed ≡ ΔU⁻, OptSig ≡ ΔS, AddDem ≡ Δκ⁺, RedDem ≡ Δκ⁻, TempAddCap ≡ δC⁺, TempRedCap ≡ δC⁻, TempAddLink ≡ δA⁺, TempRemLink ≡ δA⁻, TempIncSpeed ≡ δU⁺, TempDecSpeed ≡ δU⁻, TempOptSig ≡ δS, TempAddDem:δκ⁺, TempRedDem ≡ δκ⁻, TempRevDir:δA↔, TempAddNode ≡ δ𝒱⁺, TempRemNode ≡ δ𝒱⁻	AddCap(...) or ΔC⁺(...)
location	Required. The physical or logical target.	AddCap(ij_road)
mode	Optional. The transport mode.	AddCap(ij_road,bus)
@time	Optional temporal annotation or time window. Use @ for input, or (...) for formal. Can use either Standard time format @HH:MM-HH:MM (24-hour format), or Formal time format (HH:MM,HH:MM) or named of time: @ followed by letters, numbers, underscores, or hyphens.	...@08:00-10:00 or @weekend or (post-quake)

Operators Explained

Operators define the relationship between atomic actions. They must be surrounded by spaces.

Operator	Name	Meaning & Use Case
∪	Union	Means "AND / Combined With". Use for concurrent actions in a single policy package. Order does not matter. Example: A weekend pedestrianization plan is a union of removing car links AND adding pedestrian demand. TempRemLink(cbd_streets,car)@weekend ∪ TempAddDem(cbd_streets,pedestrian)@weekend
→	Sequence	Means "THEN". Use when the order of actions is critical. Action A must happen before Action B. Example: An incident response plan is a sequence of first adding emergency access THEN closing the affected lane. TempAddLink(emergency_access) → TempRedCap(ij_lane3)
¬	Negation	Means "NOT / Preserve". Use to explicitly state that an action must not occur on a specific target. This is useful to define constraints or prevent changes on critical infrastructure. Example: A city-wide signal optimization policy must not touch the signals on emergency routes. OptSig(all) ∪ ¬OptSig(hospital_route)

✅ Strict Syntax Rules: Quick Reference

The validator is strict to ensure policies are unambiguous. Follow these rules carefully.

Rule	✅ Do	❌ Don't
Spacing	Separate all elements with spaces. AddCap(A) ∪ AddCap(B)	AddCap(A)∪AddCap(B)
Operators	Place an operator between two actions. AddCap(A) ∪ AddCap(B)	AddCap(A) AddCap(B)
Location	Every action must have a location. AddCap(location)	AddCap()
Time Format	Use the @ prefix for time or use parentheses. AddCap(A)(09:00,10:00)	AddCap(A)[09:00,10:00]
Order	A binary operator (∪, ) cannot be at the start or end.	∪ AddCap(A)

The Policy Input Grammar

The validator is strict to ensure every policy is unambiguous. The required input syntax of an atom is: [coeff*]Action(location[,mode])[@time]

🧪 Valid Examples

• AddCap(nodeA)
• TempRedCap(linkB)@08:00-10:00
• IncSpeed(segment_12)
• AddNode(newNode1) ∪ RemLink(linkX)

🚫 Invalid Examples

• AddCapnodeA → Missing parentheses
• RedCap() → Empty argument
• TempAddCap(node1)@8:00-10:00 → Incorrect time format; should be TempAddCap(node1)@08:00-10:00

🌐 Extended Backus-Naur Form (EBNF) Grammar

This formal grammar is codified in the language of Extended Backus-Naur Form (EBNF), based on the ISO/IEC 14977:1996 international standard. This standard ensures a precise, machine-readable, and unambiguous method for defining language rules, making it indispensable for grammar-based modeling of transport policy constructs.

(* Practical Transport Policy Grammar *)
policy      ::= expression
expression  ::= term { ("∪" | "→") term }
term        ::= "¬"? atom
atom        ::= [ coefficient "*" ] action_name "(" target ")" [ time ]
coefficient ::= digit+
action_name ::= "AddCap" | "RedCap" | "AddLink" | "RemLink" | "RevDir" | "AddNode" | "RemNode" | "IncSpeed" | "DecSpeed" | "OptSig" | "AddDem" | "RedDem" | "TempAddCap" | "TempRedCap" | "TempAddLink" | "TempRemLink" | "TempRevDir" | "TempAddNode" | "TempRemNode" | "TempIncSpeed" | "TempDecSpeed" | "TempOptSig" | "TempAddDem" | "TempRedDem"
target      ::= location [ "," mode ]
location    ::= identifier
mode        ::= identifier
time        ::= "@" ( hhmm "-" hhmm | identifier )
operator    ::= "∪" | "→" | "¬"
hhmm        ::= digit digit ":" digit digit
identifier  ::= letter ( letter | digit | "_" )*

Sufficiency, Necessity, and the Path to an Exhaustive System

The molecular policy language is designed to be a necessary and sufficient foundational layer for describing any transport policy that results in a discrete change to a network model for the Ideal Traffic Assignment framework. To become truly exhaustive for ALL transport policies, including economic, behavioral, and qualitative ones, should relies on a modular, two-layer architecture:

1. The Core Atomic Language: A small, stable set of atoms describing direct changes to network structure, control, and demand.

2. External Translation Models: A suite of models that translate the complex, continuous, and probabilistic effects of high-level policies into the discrete language of the atoms.

This structure ensures the core language remains rigorous and unambiguous, while providing a clear interface to model any policy imaginable.

Translation Models: Bridging Policy and Atoms

The following table provides examples of how high-level policies can be translated into atomic language using external models.

Policy Type	Example Policy	Potential Translation Model	Atomic Output
Economic	Implement a congestion charge in the CBD during peak hours.	An Demand Model that calculates the expected demand reduction based on price elasticity and travel patterns.	TempRedDem(car, CBD)@peak_hours
Land-Use	Rezone a suburban area for high-density, transit-oriented development.	A Four-Step Travel Demand Model that forecasts the long-term increase in transit ridership from the new development.	AddDem(transit, suburban_zone)
Behavioral	Launch a public marketing campaign to encourage cycling.	A Probabilistic Choice Model (e.g., Logit model) that estimates the potential mode shift to cycling based on survey data.	AddDem(bike, citywide, certainty=0.6)
Qualitative	Improve the perceived safety of a transit station by adding better lighting.	A Stated Preference Survey Model that correlates perceived safety improvements with a willingness to use transit more frequently.	AddDem(transit, station_area)