How TriNetra works
One dataset, read from three positions in time, with a fourth engine that holds every reader to account.
The three eyes
Colour in TriNetra's console means exactly one thing: which of the three engines you're looking through.
स्मृतिSmriti — the recorded past
Ask where one vehicle went. A full plate, a partial, or a single camera returns the chronological list of every sighting, joined into a path along the real street route between each pair of cameras — never a straight line drawn between two dots.
दृष्टिDrishti — live, now
Density per camera, vehicles in motion, and alerts as they are raised: a clone flagged when one plate appears in two places at once, a hop flagged when it would have needed an impossible speed to happen.
भविष्यBhavishya — ahead of the record
The seasonal shape of a junction, scaled by how far today departs from it. Deliberately the simple model, backtested against a naive predictor rather than asserted — a forecast that cannot beat "the same as now" is not worth showing.
From one camera frame to a city-wide picture
Four stages, each of which has to survive the one before it degrading.
- A camera sees a vehicle. Detection and plate reading run at the edge. Every reading carries its confidence, its lane, its heading and a visual fingerprint of the vehicle, so the record survives a plate that could not be read at all. Indian plate grammar is validated on the way in — formats like DL3CAB1234 and their state-code variants.
- Readings become one vehicle. The same car at six cameras is six unrelated readings until something joins them. Plate text, the visual fingerprint, and whether the journey was physically possible in the time available are scored together into a single identity.
- Identities become journeys. Consecutive sightings are map-matched onto the street network, so a trajectory follows roads that exist. Where two cameras have no route between them, the segment is marked degraded rather than quietly bridged. Routes come from a 1,980-pair travel matrix built on the New Delhi road network.
- Journeys become the city. Origin-destination flow, per-junction baselines, bottleneck detection and camera health are all derived from the same passages — one record, read four ways, with no separate pipeline to fall out of step.
The digital twin
The forecast answers what happens if nothing changes. The digital twin answers what happens if something does. Pick two cameras and the road between them is shut; the simulator runs the city twice — once as it is, once with that road closed — and reports the difference per road segment. The closure lands at the midpoint of the route, not at either end: shutting a road where it meets a camera only stops traffic entering that one junction, which reroutes trivially and demonstrates nothing.
Kavach — accountability by design
A system that can follow any vehicle across a city is only acceptable if following one leaves a mark. Four things are true of every lookup TriNetra performs.
- A stated purpose. Every signed-in session carries why it exists and which case it belongs to. Both are mandatory on every endpoint that touches vehicle data — a request without them is refused before it reaches the database.
- A role that is enforced. Patrol, investigator, auditor and administrator see different consoles. The interface hides what a role cannot reach, but hiding is not the control: the gate runs server-side and answers with a refusal regardless of what the interface offered.
- A ledger that cannot be edited quietly. Each query appends a row whose hash includes the hash before it. Altering or removing an entry after the fact breaks the chain from that point onward, and the break is detectable by anyone who verifies it.
- No anonymous lookup. There is no path through TriNetra that searches for a vehicle without recording who asked, why, and under which case. That is a property of the architecture, not a policy written beside it.
Read the full detail in the privacy policy.