JunctionTwin · Traffic simulation
Stress-test a junction before you build it.
A road junction is poured once and argued about for a decade. JunctionTwin rebuilds it digitally first, fills it with the traffic that actually uses it, and pushes the design until it fails — so the failure happens on a workstation instead of on the road.
Why this problem
Our roads break the assumptions most simulators make.
Established traffic tools model lane-following vehicles on well-regulated networks, and they do it well. The two groups most at risk on Indian roads are precisely the ones those models represent worst.
480,583
Road accidents recorded across India in 2023 — up 4.2% year on year.
172,890
Lives lost in a single year, 83.4% of them working-age adults.
44.8% + 20%
Two-wheeler riders and pedestrians as a share of those deaths.
Source: Ministry of Road Transport & Highways, Road Accidents in India 2023.
What it does
Six steps, from drawing to evidence.
Rebuild
Reconstruct a real junction — geometry, lanes, approaches, signal logic — as an OpenUSD scene.
Populate
Fill it with agents calibrated to observed behaviour: two-wheelers, autos, trucks, pedestrians, livestock.
Break it
Run peak demand, incidents, rule-breaking and edge cases until throughput or safety collapses.
Measure
Flow, queue length, delay, conflict points, time-to-collision and lane utilisation — numbers, not impressions.
Compare
Test alternative layouts side by side and quantify the difference instead of arguing about it.
Report
Deliver an evidence pack an engineering or municipal team can act on the next morning.
The hard part
The question is not whether the design looks good.
It is whether it survives a Tuesday at 6pm.
A simulation that only models well-behaved vehicles will approve a junction that fails in its first week. Every behaviour listed here is routine on the roads we intend to model — and an edge case for a simulator built elsewhere.
- Pedestrians crossing mid-block, against signals, in groups
- Animals entering or standing in the roadway
- Two-wheelers filtering between lanes and through gaps
- Drivers ignoring lane markings and right-of-way
- Late merges, hesitation and sudden stops
- Breakdowns, collisions and blocked movements
How a design earns approval
Six regimes, each producing numbers rather than opinions.
A design that fails any of them goes back to the drawing board — on a workstation, not on a construction site.
Regime 01
Baseline demand
Does the design improve flow when traffic is comfortable?
Regime 02
Peak demand
Where do queues form first, and how fast do they propagate upstream?
Regime 03
Demand +25–50%
At what growth level does the design lose capacity entirely?
Regime 04
Human behaviour
What happens under hesitation, late merging and poor lane discipline?
Regime 05
Heavy vehicles
Do trucks and buses create blind-spot conflicts with two-wheelers?
Regime 06
Incidents
What does a single blocked lane do to the whole junction?
How it is built
Accelerated computing, because the sweep is the product.
One simulated afternoon proves nothing. The value is in running hundreds of variants — layouts, demand profiles, driver behaviours, incidents — and that only becomes affordable on GPU.
OpenUSD scene graph
Junction geometry as a physically accurate, interoperable scene — the digital twin itself.
Synthetic data
Domain randomisation over lighting, weather, camera placement and vehicle mix, so models see more than one afternoon's footage.
Generated edge cases
Rare and dangerous traffic situations that are unsafe — or impossible — to capture from real recordings.
Video → trajectories
Junction camera feeds turned into vehicle counts, classes and paths, which is what the model is calibrated against.
Behaviour models
Detection and trajectory models fine-tuned on synthetic plus local footage, then evaluated against held-out days.
Parallel sweeps
Hundreds of design variants and demand profiles evaluated per run on GPU, rather than one scenario at a time.
Where we actually are
Stated plainly, because you will find out anyway.
Built
Three production AI products serving real users, a decade of Unity and real-time 3D work, and in-house computer-vision and LLM engineering.
Not built
JunctionTwin itself. No simulation code, no calibrated junction, no pilot. This is a concept backed by a team, and we are not going to dress it up as more.
Next
One engineer is working through the simulation and synthetic-data stack. Junction selection and traffic-data sourcing in Hyderabad are the immediate step.
The first 90 days
A plan with a milestone that can fail.
Days 1–30
Pick one junction
Select a real junction, collect geometry, traffic counts and 20+ hours of video, and build the scene.
Days 31–60
Calibrate against reality
Detection and tracking on the footage, then tune agent behaviour until simulated flow matches measured flow.
Days 61–90
Try to break it
Run the six-regime stress matrix across three layout variants, and publish the results — including the bad ones.
The test we have set ourselves
Simulated baseline flow within ±10% of measured flow at the real junction, across three separate time windows.
If calibration cannot get inside ±15%, we will publish that too and revise the approach before going further. A model nobody has tried to falsify is a rendering, not a simulation.
Let's build
Have something worth building?
Tell us who it helps. If it makes people better off, we'd love to build it with you.