Fuse any vendor's radars, cameras and sensors into one set of tracks and alerts, on open records you own.

India is putting radars, cameras and drones along its borders faster than it is joining them up. On 22 May 2026 the Home Minister announced a Smart Border Project: a multi-layer "electronic wall" of drones, radars and smart cameras along about 6,000 km of frontier, building on the Comprehensive Integrated Border Management System (ETV Bharat, 22 May 2026), with pilots planned at 7 to 8 sites (The Tribune, 6 Jun 2026). The Ministry of Home Affairs defines CIBMS as the integration of manpower, sensors, networks, intelligence and command and control (MHA).

Integration is the hard part. Each vendor ships its own console and its own track numbers, so one boat seen by a radar, a thermal camera and a transponder becomes three objects on three screens. On a river at night it is harder still: registered fishing boats, a late ferry, swimmers, cattle and drifting debris share the water with the crossings that matter, and every false alarm costs an operator's attention. A fishing crew drifting toward the boundary needs a warning, not an intrusion alert. Background and sources: The frontier in October 2026.

• Defines five open records, in JSON Schema 2020-12 and documented field by field:
  DetectionTrackSensorStatusAlertZone
• Ships a Python SDK: typed records, validation with no third-party packages, an in-memory bus, a JSONL sink, and a worked adapter from NMEA 0183 radar targets to Detection records.
• Fuses reports into tracks: constant-velocity Kalman filtering, chi-square gates, optimal global nearest neighbour assignment, confirmation on 3 hits of 5, coasting through short gaps, and duplicate merging.
• Labels each track by trusting every sensor for what it is good at: thermal for swimmers and animals, transponders for registered vessels, radar for size and speed.
• Raises alerts from rules written as data: a virtual line set back 150 yards from the boundary, zone entry, loitering, a crew-safety warning for fishing boats near the boundary, and a person-in-the-water alert.
• Replays raw detections, fused tracks and ground truth on a map, with a track list and an alert log, and scores fusion against each sensor alone.

1. AdaptOne small adapter per sensor model turns vendor output into Detection records with honest error bars.
2. AssociateStatistical gates and an optimal assignment decide which report belongs to which track.
3. TrackA Kalman filter follows each object; tracks confirm on 3 hits of 5 and coast through short gaps.
4. ClassifyEach sensor's label counts as much as that sensor has earned in trials; speed rules out the impossible.
5. AlertRules from Zone records fire on confirmed tracks only, with safety alerts kept separate.
6. DecideAn operator verifies on camera and decides; every action goes to the SAKSHI audit chain.

To test the engine we built a seeded night on the Ichamati between Taki and Hasnabad: real river and boundary geometry from OpenStreetMap and the real weather for 20 October 2026, with simulated fishing boats, a ferry, an unregistered small boat that crosses, two swimmers, cattle swum across with a herder, drifting debris, a bird flock, and ten notional sensors with false alarms, delays and an outage. Every formula and threshold is on the methods page and in the methods note.

The same engine, the same night, the same sensor output, scored against ground truth every half second. Only the sensors it may use change. Simulated

OSPA, in metres, folds position error and missed or false tracks into one distance: lower is better, and 100 m means everything is missed. MOTA is 1 minus misses, false positives and identity switches per object instance. Objects counts how many of the 14 simulated objects were ever tracked; labelled right is the share of all object time tracked with the correct class; recall and precision score the alerts against ground truth. Fusion has costs too: 11 identity switches, mostly in a group of swimming cattle, and 2 short false tracks. One night is not a field trial: these numbers compare configurations, they do not predict performance on a real river. All metrics.

• System integrators: write one adapter per sensor model instead of one integration per pair of systems.
• Sensor makers: show what your radar or camera adds to a fused picture, scored the same way as everyone else's.
• Technical wings and control rooms: one picture of a river stretch, fewer duplicate and false alarms, and a log of every decision.
• Command systems: tracks and alerts by pull, push or file, including across an air gap.

• Objects, not people: a track is an object and its motion. No record holds a name, a face or any personal identifier.
• No identity targeting: rules use place, motion and object class only.
• Safety first: fishing crews near the boundary get a safety warning, and a person in the water raises a rescue-readiness alert.
• Software recommends; trained people decide. Nothing triggers an action by itself, and operator actions go to the SAKSHI audit chain.
• Sovereign by design: runs on-premise or air-gapped with no foreign cloud. Simulated data is labelled SIMULATED on every page and in its JSON.

• Everything here is simulated. Sensor models, classifier accuracy and detection ranges are assumptions until field trials replace them.
• Objects moving in a tight group swap identities; cameras estimate range poorly beyond about 1 km.
• The boundary line from OpenStreetMap is indicative, not a survey line, and the 150-yard setback line has no legal standing.
• SANGAM does not claim compatibility with any deployed command system; the integration patterns are offered as contracts to build against.

Pilot offer: one river stretch and the sensors you already have. We write the adapters, replay your recorded logs through the engine, and score it against your ground truth before anything goes live. contact@trinetra.in