How the products work, and how to build with them.

Overview

Product methods notes

Every product ships a methods note: what data it uses, the assumptions it makes, where it fails, and how to check it. A note is published while its product is still in build, and changes until the product passes review.

Products not listed have not published a note yet. Rows are added from the product registry when this page loads.

Sangam SDK

Sangam is our open sensor-fusion layer. Any sensor maker or integrator can publish detections in the open schema, and Sangam fuses them into tracks and alerts that other systems can read. The detections, tracks and alerts Sangam shows on this site come from a seeded simulator, set on real geography and the real weather of the scenario hour, and are labelled Simulated.

Open schemas

JSON Schema files, versioned with the SDK. Every record carries type and schema_version, so one JSONL stream can mix record types.

Quick start

from trinetra.sangam.sdk import Detection, Polar, Point, Classification, Bus, JsonlSink

det = Detection(
    id="RDR-1:42:0", sensor_id="RDR-1", sensor_type="radar",
    time="2026-10-20T16:05:12.400Z",
    polar=Polar(range_m=812.5, sigma_range_m=7.5,
                bearing_deg=103.2, sigma_bearing_deg=0.6,
                origin=Point(22.58731, 88.93522, 15)),
    classification=Classification("small_boat", 0.62),
)
det.validate()            # [] when valid
bus = Bus()
with JsonlSink("detections.jsonl").attach(bus, ["detections"]):
    bus.publish("detections", det)

Commands

cd pipeline
python3 -m trinetra.sangam run                  # fetch geography and weather, simulate, fuse, export
python3 -m trinetra.sangam run --offline        # rebuild from cached responses, no network
python3 -m trinetra.sangam validate FILE.jsonl  # check records against the open schemas
python3 -m trinetra.sangam examples             # run the SDK examples

Conventions

• Positions in WGS84 decimal degrees; covariances in an east-north frame, in square metres.
• Bearings in degrees clockwise from true north. Times in ISO-8601 UTC with a trailing Z.
• Classes: small boat, large vessel, person, animal, debris, or unknown. Sensor types: radar, EO, IR, acoustic, AIS, fence.
• Alert levels use the same four words as every product: normal, watch, warning, danger.

Sangam detects, tracks, classifies and alerts. It does not compute firing solutions. Product page.

Pipelines and data contract

The system is static web pages plus Python pipelines. Pipelines fetch public data or run seeded simulations and write JSON exports that the pages read. The deployed site never depends on a running server.

Module layout

pipeline/trinetra/<id>/             fetch, compute, export (python3 -m trinetra.<id> run)
dashboard/<id>/                     console views for the product
dashboard/data/<id>/manifest.json   provenance for every export
dashboard/data/<id>/*.json          exports read by the pages
products/<id>.html                  public product page
docs/products/<id>.md               methods note
tests/test_<id>.py                  offline tests with recorded fixtures

Run a pipeline

cd pipeline
python3 -m trinetra.varuna run            # fetch, compute, export
python3 -m trinetra.varuna run --offline  # rebuild from cached responses

The manifest

Every product writes dashboard/data/<id>/manifest.json with its sources, licences, retrieval times and files. Timestamps are ISO-8601 UTC; coordinates are [lat, lon] to four decimal places; units appear in field names where they could be ambiguous, such as discharge_m3s. Simulated records carry "simulated": true, and simulators record their seed. A failed fetch never destroys the last good export; the data is marked stale instead.

{
  "module": "varuna",
  "generated_at": "2026-10-21T04:38:59Z",
  "simulated": false,
  "seed": null,
  "sources": [{"name": "Open-Meteo Flood API (GloFAS v4)", "license": "CC BY 4.0",
               "url": "https://open-meteo.com/en/docs/flood-api",
               "retrieved_at": "2026-10-21T04:14:18Z"}],
  "files": [{"path": "board.json", "rows": 18, "bytes": 31414}],
  "notes": "Advisory only."
}

Data API

Every public export is also served at a stable path, /api/v1/<module>/<file>, which maps to /dashboard/data/<module>/<file>. Responses are JSON with cross-origin access open, so a browser app on another site can read them. Start with a product's manifest to find its files, sources and licences.

curl https://trinetrahq.com/api/v1/varuna/manifest.json
curl https://trinetrahq.com/api/v1/varuna/board.json

Setu, our developer portal, lists every dataset with its licence, attribution and code samples. Respect each source's terms: the Open-Meteo free tier, for example, is for non-commercial use.

Testing and QA

python3 -m pytest tests/test_varuna.py -q         # unit tests, no network
python3 -m http.server 8000                       # serve the site locally
node tools/qa/qa.mjs products/varuna.html --a11y  # browser QA: errors, links, 375 px, WCAG AA

A page passes QA with zero console errors, no broken internal links, no horizontal scroll at 375 px, and no serious accessibility findings. Text colours meet WCAG AA on every surface.

Deployment

• Public site. The repository root is served as static files. Directories are linked with a trailing slash (/safety/) and files with their extension (/products/varuna.html).
• Customer deployments. The same files and pipelines run on the customer's servers, on-premise or air-gapped. Pipelines rebuild from cached data with --offline. See deployment models.
• Optional local API. python3 -m trinetra serve starts a FastAPI server for local analysis. Nothing on the public site needs it.
• Secrets. Optional keys live in a .env file that is never committed. No key is needed to build or view the site.

Console guide

The console is where operators work; it asks you to sign in first. Live products appear in the sidebar under their group, and products still in build are listed together at its foot.

Sign in

The public demo uses a password check in the browser. It is a demo gate, not access control, and shows only public data and labelled simulations. Ask your Trinetra contact for access. Customer deployments use the customer's own sign-in.

Operations

Overview, daily brief, alerts and requests for information over the public-record corpus.

Products

Safety, hazards, sensors and airspace, response, analysis and training, governance and public groups, each opening the product's own views.

Events

Map, timeline, method and district views of incidents and seizures, with every claim linked to its source document. Private individuals appear as role labels.

System

Sources and their health, and the audit log of operator actions.

Public pages

• Safety hub: flood, heat and sea-state advisories, free and without an account.
• Darpan: seizures and interdictions from official releases, with CSV download.
• Transparency report: what the platform collects, a personal-data scan of public files, and a ledger anyone can verify.
• Research: notes with every claim sourced and our own data published.

Company documents

Doctrine

Seven red lines and eight commitments, with how each is enforced.

Trust and security

Deployment models, data retention, oversight, law, and responsible disclosure.

Build contract

Architecture and the rules every contributor builds against.

Design system

Tokens, components, chart and map helpers, and accessibility rules.

Data and licences

Each product's manifest lists its exact sources and retrieval times.

Help

Integration and pilot questions: contact@trinetra.in. Security reports: security@trinetra.in. Corrections to a methods note: press@trinetra.in.