CausalCityAI

Ι — Origin

How it started.

CausalCityAI began during a Google hackathon — initially a challenge problem, eventually an obsession. We became fascinated by the idea that locals understand cities in ways software does not: people know patterns, hidden behaviors, traffic habits, events, temporal rhythms, context. What if systems could learn them?

ΙΙ — The Problem

What we're solving.

Navigation apps tell you what traffic is doing right now. They don't tell you why, and they certainly don't tell you what will happen if you reroute 5,000 cars down a side street. Municipalities spend millions on infrastructure without knowing if it will trigger the Braess Paradox — where adding a road mathematically makes traffic worse.

Cities are dynamic systems. Traffic affects people. People affect traffic. Weather affects movement. Movement affects congestion. Congestion affects decisions. Everything interacts. A model that tries to predict the future, explain why it happened, and recommend a route will be terrible at all three.

ΙΙΙ — Differentiation

Why this, not that.

We build a digital twin of your city. Navigation apps tell you what traffic is doing — we tell you why, and what will happen if you change it. The key insight: cities must be treated as dynamic graphs, not static maps. Every observation is expressed as (entity, timestamp) → state — immutable, append-only, fully auditable. Social media posts are not blindly ingested; they are clustered, verified against official sources, and only then promoted to Canonical Events. Our synth.main Numba JIT physics generator produces 180 days of causally-linked synthetic traffic data in under 30 minutes — so the AI team doesn't wait for sensor deployments before training GNNs.

ΙV — Architecture

The 6-layer platform.

A model that tries to predict the future, explain why it happened, and recommend a route will be terrible at all three. Each layer does one thing.

1. L1
   Observation

   Collects raw signals: traffic feeds, weather, event schedules, social media indicators. Immutable and append-only.

2. L2
   Memory

   Stores the historical reality of the city. Without historical context, forecasting and causal discovery are impossible.

3. L3
   State Builder

   Converts messy real-world data into a consistent representation: (entity, timestamp) → state. Single source of truth.

4. L4
   Intelligence

   Three engines: Forecasting (what will happen?), Causal Discovery (why will it happen?), and Confidence Estimation.

5. L5
   Simulation

   Imagines alternate futures. If Intelligence predicts a traffic jam on Road A, Simulation asks: what happens if we reroute 500 users through Road B?

6. L6
   Decision

   Turns simulations into interventions: route recommendations, departure time adjustments, stop-reordering plans — factoring in Braess Paradox.

V — Capabilities

What it does today.

• ›Observation layer — traffic, weather, event schedules, social signals
• ›Memory layer — immutable append-only historical state
• ›State builder — (entity, timestamp) → state canonical representation
• ›Event clustering with source verification and trust tiers
• ›Forecasting engine — spatio-temporal GNNs
• ›Causal discovery — lag-based + multi-city structural analysis
• ›Confidence estimation — bootstrap validation + stability scoring
• ›Counterfactual simulation (Braess Paradox detection)
• ›Decision support — routes, timing, stop-reordering
• ›Synthetic dataset generation (180 days in ~28 minutes)

VI — Target Audience

Who we're building for.

VII — Open Questions

What we don't know yet.

• How much interpretability is required for municipal adoption?
• Can synthetic data replace real sensor deployments for model training?
• What city-level decisions most benefit from counterfactual simulation?
• How do we handle the Braess Paradox at scale with live user compliance?

Feedback wanted from: Urban planners, transportation researchers, mobility startups, governments, traffic engineers, systems engineers — and people who think this idea cannot work.