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 historically been influenced by intuition, authority, and political priorities. While these approaches have shaped practice, they often lack the foundational principles of scientific inquiry: reproducibility, testability, evidence-based validation, and transparent modeling. In many cases, planning relies on narrative and persuasion, with models treated as opaque tools and limited mechanisms for learning from outcomes. Models are treated as black boxes and planners are rarely held responsible when predictions fail. The language of the Chemistry of Transport Policy introduces a transformative framework to restore scientific integrity by pairing a machine-readable language with a falsifiable simulation process, to elevate planning from persuasion into precision. This formal grammar, first proposed by Dr. Kardi Teknomo in his monograph "Ideal Flow Network for Transportation Research - Unveiling the Hidden Secret of Nature to Solve Traffic Congestion" (to be published by Springer Nature), redefines policy-making as a repeatable, objective, and testable discipline.

In the absence of a formal language, policy-making tends to rely on narrative strength. Confidence in delivery can sometimes outweigh the rigor of model construction, creating an epistemic gap where feedback loops are limited and reproducibility is difficult. By reintroducing the scientific method, we can shift from belief-based approaches to evidence-based planning.

Reestablishing rigor begins with a formal, machine-readable syntax that encodes policy with clarity and precision. The Chemistry of Transport Policy offers a grammar that enables planners to define interventions as structured expressions, interpretable by both humans and machines. Just as chemical reactions follow defined rules, policy inputs are governed by syntactic and semantic logic—making them traceable, reproducible, and auditable.

An Ethical Framework Embedded in Code

At its foundation, this system promotes ethical practice. It is designed to cultivate four essential traits in planners and their work:

• Honesty: The grammar requires transparent declaration of every policy input. Assumptions are made explicit, and every scenario is traceable to its origin.
• Objectivity: The simulation engine applies quantitative logic uniformly. It evaluates each input as a testable hypothesis, independent of anecdote or persuasion.
• Responsibility: Because every model run is reproducible, planners are empowered to take ownership of their predictions. The process invites constructive scrutiny and continuous improvement.
• Adaptability: The feedback loop supports iterative learning. Discrepancies between predicted and observed outcomes become valuable opportunities for refinement and growth.

Embracing reproducible models strengthens accountability and fosters trust. By evaluating policy through verifiable simulations rather than rhetorical appeal, we create a foundation for ethical, evidence-based planning.

🛠️ 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 (See valid atomic action definitions). 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:

all_ramps ≡ [17216288,17216296,17216297,17216307,17216337,17216338,17216339]
// 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)

Note: The target syntax is extremely strict. For example, there must be no spaces inside the parentheses () of an atom.

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 $\mathcal{A}$ 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)

Operator Placement Rules

• A molecule cannot start or end with a binary operator (∪, →).
• Two binary operators cannot be adjacent.
• Negation (¬) must prefix a valid atom or identifier directly, without space.

Atom Formatting

• Each atom must follow the format: [coeff*]Action(location[,mode])[@time]
• Location is mandatory; mode and time are optional.
• Time must be a valid identifier or interval (e.g., @06:30-10:00).
• Examples:
  • TempRedCap(NodeA,HOV)@06:30-10:00 ✅
  • @8:00 ❌ (missing action and location)

Optionality & Branching

The grammar does not support branching logic or optional paths within a single molecule. If multiple policy paths are needed, define them as separate molecules:

OptionA ≡ AddCap(linkA);
OptionB ≡ AddCap(linkB);
                    

✅ Strict Syntax Rules: Quick Reference

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

Semicolon Usage: Use a semicolon ; only at the end of a complete definition for a named molecule or list (e.g., BasePolicy ≡ ...;). Do not place semicolons between atoms within an expression.

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)
Semicolons	End a full definition with a semicolon. MyPolicy ≡ AddCap(A);	Use semicolons inside an expression. 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]

Each atom must correspond to a valid atomic action.

🧪 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) Core Grammar Rules

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, notations and supports semantic interpretation of atoms, molecules, and policies, making it indispensable for grammar-based modeling of transport policy constructs.

<policy>         ::= <molecule> ;

<molecule>       ::= <identifier> "≡" <expression> ;

<expression>     ::= <term> { <operator> <term> } ;

<term>           ::= [ "¬" ] ( <atom> | <identifier> ) | <list_definition> ;

<atom>           ::= [ <coefficient> "*" ] <action_name> "(" <target> ")" [ <time> ] ;

<list_definition> ::= <identifier> "≡" "[" <element> { "," <element> } "]" ;

<element>        ::= <number> | <identifier> ;
    

<

Lexical Elements

<coefficient>    ::= <digit> { <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> | "_" } ;

<digit>          ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

<letter>         ::= "A" | "B" | ... | "Z" | "a" | "b" | ... | "z" ;

Pedagogic Notes

• Atoms are the smallest executable units (e.g., TempRedCap(...)).
• Molecules are named compositions of atoms and/or other molecules.
• Policies are top-level molecules intended for execution or evaluation.
• Negation (¬) can apply to atoms or entire molecules via their identifiers.
• Item lists can contain numbers or identifiers, and are reusable across atoms.

Guiding Principle: This document defines the semantic rules for creating valid and logical policies. All rules and patterns are expressed using the operators and structures formally defined in the EBNF grammar (∪, →, ¬, <atom>, etc.). No new syntax is introduced.

This documentation explains how to reason about policy molecules using only the constructs allowed by the formal grammar. All molecules must conform to the base syntax: [coeff*]Action(location[,mode])[@time] joined with ∪, →, and ¬.

Feasibility & Conflict Guardrails

A policy is considered semantically feasible if its constituent <term>s do not create a logical contradiction. The grammar may permit a syntactically valid string that is semantically nonsensical. The primary rule of feasibility is avoiding simultaneous, contradictory actions. The most common conflict arises when an atom and its negation are joined by ∪ (union), which implies simultaneous application.

Distinction of Conflict and Identity

An <expression> is infeasible if it contains an <atom> and its negation joined by the union operator ∪, applied to the same target at the same time.

In contrast, a sequence of an action followed by its inverse is a valid and common pattern, often representing a temporary change or an "undo" operation. This is expressed using the sequence operator →.

• Conflict: TempAddLink(A) ∪ TempRemLink(A) is infeasible. It attempts to add and remove the same link at the same time.
• Identity: TempAddLink(A) → TempRemLink(A) is feasible. It applies an action and then undoes it sequentially.

Concept	Valid Example (Sequential)	Invalid Example (Simultaneous Conflict)
Sequential vs. Simultaneous	AddLink(A) → RemLink(A) A link is added, and then later removed in a subsequent step.	AddLink(A) ∪ RemLink(A) A link cannot be added and removed at the same instant.
Sequential vs. Simultaneous	AddCap(link) → RedCap(link) Sequential application is valid.	AddCap(link) ∪ RedCap(link) Simultaneous contradiction.
Negation Conflict	¬AddDem(car) → AddDem(bus) Negates one mode and promotes another.	AddDem(car) ∪ ¬AddDem(car) Contradictory union.

Composition and Concurrency: The Union Operator ∪

The ∪ operator combines multiple <term>s into a single, concurrent package. All actions in a union are intended to be applied simultaneously.

• Use Case: Packaging a set of related changes for a single policy deployment.
• Example: RedCap(MainSt, car) ∪ AddLink(MainSt, bus_lane) represents the simultaneous reallocation of road space and addition of a bus lane.

Sequence and Causality: The Sequence Operator →

The → operator defines an ordered sequence of operations. This is used to model plans where one action must follow another.

• Use Case: Multi-stage projects, phased rollouts, or cause-and-effect chains.
• Example: (AddLink(Detour) ∪ OptSig(Detour)) → RemLink(MainSt). First, a detour is created and its signals optimized; only then is the main road link removed.

Representing External Conditions and Generative Logic

High-level logical concepts like conditional triggers ("if-then") and quantifiers ("for all") are not represented by unique symbols in the EBNF. Instead, they are handled by an external system that generates EBNF-compliant policy strings.

Conditional Logic (If-Then)

Conditional logic is managed by a controlling system (e.g., a traffic management center application). The condition is evaluated externally, and if it is met, the system generates and executes the corresponding policy molecule. The EBNF string represents the outcome of the condition, not the condition itself.

• Conceptual Logic: "If Congestion > 0.9, then execute RampMeteringPolicy."
• Generated EBNF: The system would execute a predefined molecule, e.g., RampMeteringPolicy ≡ TempOptSig(Ramp1) ∪ TempOptSig(Ramp2). The "if-then" logic lives in the application layer, not in the policy string.

Quantifiers (For All, There Exists)

Quantifiers are conceptual shorthands that are resolved into explicit EBNF expressions by a generator. The EBNF <list_definition> is the primary mechanism for defining the sets over which these operations apply.

• Conceptual Logic ("For All"): "Apply signal optimization to all intersections in the CBD."
• EBNF Implementation:
  1. Define the list: CBD_Nodes ≡ [NodeA, NodeB, NodeC].
  2. A generator script iterates through CBD_Nodes to produce the final molecule: OptSig(NodeA) ∪ OptSig(NodeB) ∪ OptSig(NodeC).
• Conceptual Logic ("There Exists"): This corresponds to a system validation or query, not a policy to be executed. For example, "Check if there exists a bus lane without signal priority." This is a query performed against the system's state, not an executable policy string.

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)