Skip to content
SAHASRANSHUTECHNOLOGIES
Flagship productMaritime SecurityPilot-ready

The sea produces more than any watch can read. We show the few contacts that matter, with the evidence attached.

Maritime security software that fuses radar, cooperative reporting and electro-optical observation into one operating picture, raises only what warrants a decision, and leaves the judgment, and the record of it, with the person accountable.

See the capabilitiesProduct page
Maritime Security
Live
East coast AOI62 tracks correlated
TRK-0417 · selected17.68 N · 83.27 E · 11.2 kn · 3 sources
Contacts for review03 open
  • TRK-0417Reporting gap, track persistsHigh
  • TRK-0392Course change in a protected laneReview
  • TRK-0355Identity requires verificationMedium
Evidence · TRK-0417Reporting gap on one hull
EO 04:41
Declared
Fishing vessel
Observed
18.4 kn sustained
AIS
Off 02:10–04:40
Explanations
3 retained
Evidence discipline
Competing explanations retained
Human decision recorded
InvestigateDismiss with reason
AIS · currentCoastal radar · currentEO feed · currentRegistry · synced 04:00
Watch 2 · 04:52 IST
Sources fusedAIS · Radar · EO · Registries
DeploymentCoastal edge to control room
Built forAuthorities · Ports · Offshore · Integrators
Judged byTriage time · Warning horizon · Precision
Why the demand exists
01

Sources do not agree

Radar, cooperative reporting and imagery describe the same hull differently, and reconciling them is still largely done by hand.

02

Volume beats attention

No operator can sustain review across every track, so prioritisation has to be defensible rather than arbitrary.

03

Evidence has to survive handover

When the watch changes, the context is lost unless the reasoning travels with the track.

04

Integration, not replacement

Authorities already own their sensors and systems. The product has to sit alongside them.

What the product does

Six capabilities. Each one answerable to the watch that uses it.

Every capability below exists to change what an operator does with the next contact, not merely what they know about it. They are described as they work, with the reasoning each one leaves behind.

01Multi-source fusion

One hull, one track, whatever the sensor.

Radar returns, cooperative reporting and electro-optical imagery each describe a vessel in their own vocabulary, and today the reconciliation is done by hand. The product correlates them into a single, continuously maintained track, so the watch reads one account of the coastline rather than three that disagree.

  • Cooperative and non-cooperative sources correlated into one picture
  • Track continuity held through reporting gaps and sensor handoffs
  • Every contribution to a track kept, attributed and open to inspection
Track fusion · TRK-0417
3 sources · 1 track
AIS GAP · 02:10–04:40TRK-0417CONTINUITY HELD THROUGH GAP · 3 SOURCES ATTRIBUTED
AIS reportRadar plotEO detectionFused track
Track age 06:32 · last fix radar
02Behaviour and identity analytics

Identity is what a vessel does, not what it declares.

Self-reported identity is an assertion. Behaviour is evidence. The product reads speed, course, loitering, rendezvous and the pattern of a hull over time, and holds each against what a vessel of its declared type, route and destination would ordinarily do.

  • Behavioural baselines by vessel class, route and season
  • Anomalies scored against expectation, not a fixed threshold
  • Declared identity tested against observed conduct
Vessel assessment · TRK-0392
Deviation · review
Declared
Type
Fishing vessel
Flag
Coastal state
Destination
Chennai · ETA 06:00
Draught
3.1 m
Observed
Sustained speed
18.4 kn
Loiter
02:10–04:40, 3 nm off lane
Rendezvous
1 contact, 22 min
Night AIS
Switched off twice
Speed over ground · last 8 hClass baseline 5–8 kn
EXPECTED FOR CLASSNOW

Assessment. Conduct is inconsistent with the declared class on four counts. Identity requires verification before the approach is cleared.

03Mission areas and watchlists

Attention is finite. Direct it where the mandate is.

An authority's obligations are specific: a lane to protect, an installation to guard, a list of hulls to follow. The product turns those obligations into standing areas of interest and watchlists, so the picture is organised around what the institution is answerable for.

  • Geofenced mission areas with entry, exit and dwell rules
  • Watchlists with provenance, review dates and ownership
  • Priorities set by mandate and adjustable by the watch
Mission areas · East coast
4 areas · 2 active
PROTECTED LANEPLATFORM · 2 NM STANDOFFANCHORAGE ADWELL 41 MIN
WatchlistOwner · Ops 2
  • TRK-0392
    Identity unverifiedReview 12 Sep
  • IMO ····418
    Prior sanction interestReview 30 Sep
  • TRK-0355
    Dark near platform, AugReview 04 Oct
  • Hull ····72
    Partner agency requestReview 18 Oct
Area rules
EntryAlert
Dwell> 30 min
ExitLog
04Competing explanations

A conclusion is only as good as the alternatives it survived.

When a track goes dark near a protected lane there is more than one explanation. The product keeps them side by side, with the evidence for and against each, and records which one the analyst accepted and why. The reasoning becomes part of the record rather than a memory.

  • Hypotheses ranked, with the evidence attributed to each
  • Analyst judgment recorded alongside the alternatives considered
  • Confidence expressed and contradiction preserved, not averaged away
Explanations · TRK-0392
3 hypotheses retained
  • H1Transshipment at sea0.58
    For
    Rendezvous 22 minAIS off during contactCourse reversal
    Against
    Sea state 4
  • H2Shelter from weather0.27
    For
    Sea state 4Nearby hulls also slowed
    Against
    Only hull to go darkRendezvous
  • H3Equipment fault0.15
    For
    Intermittent AIS in July
    Against
    Both outages during contactFault not reported
Analyst decision

Investigate. H1 accepted; H2 and H3 retained on the record.

Recorded 04:52 · Watch 2 · Kumar
05Historical replay and reporting

What happened is a question the system should answer.

After an incident, the enquiry begins. The product replays the picture as the watch saw it, minute by minute, with the alerts raised, the actions taken and the evidence available at the time. The report is produced from the record, not from recollection.

  • Full-picture replay at any past moment
  • Timeline of alerts, reviews, handovers and overrides
  • Reports assembled from the audit trail, ready for review
Replay · 11 Sep · 01:40–06:10
Playback 04:52
02:10
03:25
04:40
04:52
Alerts raised2both reviewed
Overrides0none recorded
Time to decision28 minfrom first alert
Incident reportAssembled from record · ready
06Interoperable track and event APIs

It joins the estate the authority already owns.

Sensors, command systems and vessel traffic services are already installed and already paid for. The product publishes tracks and events over open interfaces and consumes the feeds already in place, so it strengthens the existing architecture rather than asking anyone to replace it.

  • Standards-based track and event exchange
  • Deployment from the coastal edge to the control room
  • Roles, audit and retention aligned to institutional policy
Interfaces · Track and event exchange
Open standards
Consumes
  • AIS receiversNMEA · terrestrial and satellite
  • Coastal radarASTERIX plots and tracks
  • EO / IR feedsRTSP and still capture
  • RegistriesVessel, licence and watchlist data
Publishes to
Command & controlVTSPartner agenciesReportingData platform
Event · track.qualified200 · published
{
  "track_id": "TRK-0417",
  "sources": ["ais", "radar", "eo"],
  "position": { "lat": 17.68, "lon": 83.27 },
  "area": "EAST_COAST_AOI",
  "assessment": {
    "level": "review",
    "reasons": ["ais_gap", "lane_deviation"],
    "hypotheses": 3,
    "confidence": 0.58
  },
  "decision": {
    "by": "watch-2",
    "action": "investigate",
    "at": "2026-09-11T04:52:00+05:30"
  }
}
From sensor to decision

A detection is not yet an alert. An alert is not yet a decision.

The distance between them is where most of the work, and most of the failure, sits. The product moves every contact through four stages, and leaves a record at each.

  1. 01

    Observe

    Radar, cooperative reporting, electro-optical feeds and registries arrive as they are, in their own formats and on their own clocks.

  2. 02

    Correlate

    Observations that describe the same hull are joined into one track, with each source's contribution attributed and retained.

  3. 03

    Qualify

    Behaviour is measured against expectation and mandate. Only what warrants a decision is raised, and it arrives with its reasoning.

  4. 04

    Decide

    The watch reviews, investigates or dismisses. The judgment, the alternatives and the outcome are recorded for the next watch and the enquiry after.

The operating problem

The signal that mattered is usually found afterwards, scattered across tracks, sensors, registries and manual work that were never meant to be read together.

What the product produces

A prioritised picture that carries its reasoning with it, so a watch can move from detection to investigation, and hand over to the next watch, without the evidence thinning at each step.

Container vessels alongside a terminal under gantry cranes
Where the consequences are real

A coastline produces far more observation than any watch can absorb, and the cost of a connection not drawn is counted in incidents, not in tickets.

The obligation, for the authority and for the software it relies on, is to make the few things that matter visible among the many that do not, and to be able to show afterwards why they were raised.

Built for

Four institutions, one obligation to see clearly and answer for it.

Maritime authorities

Coastal surveillance, exclusive economic zone enforcement and the coordination of a response across agencies.

Ports and terminals

Approach monitoring, berth and anchorage security, and a defensible record of every vessel movement.

Offshore operators

Standoff protection for platforms, wind arrays and subsea assets, with early warning of an approach that does not fit.

Systems integrators

A fusion and evidence layer that sits alongside the sensors and command systems already delivered to the customer.

Where it stands

What is built, what a pilot adds, and how it will be judged.

People who evaluate systems for a living discount a page that has only upside. This one states the position plainly, because a pilot conversation goes faster when it starts from the truth.

Built and demonstrable
  • Working track fusion and prioritisation over representative scenarios
  • Operator console with evidence, timeline, and analyst review states
  • Event and track APIs for downstream integration
What the pilot adds
  • Planned pilot milestone: connect to the authority’s operational sensor feeds
  • Planned pilot preparation: security assessment, certification and accreditation aligned with the authority’s requirements
Pilot scorecard
  • Detection to triage timeHow long from first observation to a watch decision.
  • Warning horizonHow far ahead of the event the picture raised it.
  • Precision at KOf the top contacts raised, how many warranted the attention.

Agreed with the authority before testing begins, so the standard cannot move once the results arrive.

Beyond the coastline

The same architecture for evidence, applied where else a missed signal has consequences.

Ingestion, fusion, confidence, operator workflow and audit were built once. Three further products apply them, each at an earlier stage than the flagship and each described at the stage it has actually reached.

Offshore wind turbines in open water under a clear sky
In development · Design partners
Product / 02

Renewable Energy Forecasting

Bring foresight to generation. Bring confidence to every scheduling decision.

Independent power producers, renewable asset owners, captive and open-access generators, coordinating agencies and utility scheduling teams

Read the product page
A dense grid of surveillance cameras mounted on a wall
In development · Pilot scoping
Product / 03

Computer Vision

Turn visual awareness into informed action across your operations.

Manufacturers, warehouses, refineries, ports, terminals, energy facilities and safety and security teams

Read the product page
An analytics dashboard showing distribution charts on a monitor
Working prototypes · Seeking a pilot bank
Product / 04

Customer Protection Platform

Harm is rarely a single event. It is a sequence that no one was positioned to see whole.

Retail and commercial banks, payment institutions, and fraud and financial-crime operations teams

Read the product page
How we work

Judgment is the product. Software is how it reaches more people.

Every product begins with a single recurring decision, works alongside the systems already in place, and earns its expansion through results an operator can verify. Nothing here scales on the strength of a demonstration.

01

Begin with a decision

What will the operator do differently?

Every product starts with one recurring decision that matters, where better evidence changes what a person does, not merely what they know. Software that changes no decision is a report. We are not in the business of reports.

02

Respect what is already there

Does it work with what the institution already owns?

Institutions have spent years, and a great deal of money, on sensors, cameras, feeds and control rooms. Our responsibility is to add to that inheritance, not to ask anyone to set it aside on our account.

03

Be answerable

Can every judgment be examined afterwards?

Confidence, source, review, override and outcome remain connected, so the system improves without uncertainty being quietly set aside. A system that cannot be audited has no claim on decisions of consequence.

04

Earn the right to grow

Has it proved enough to deserve more?

We begin narrow, measure honestly, and widen scope only when the product has shown its worth in operation. Growth that runs ahead of evidence is a claim, not a result.

A common foundation

One architecture for evidence, proven first at sea.

Data ingestion, event handling, confidence and contradiction, operator workflow, audit, observability and controlled deployment are shared across the portfolio. What is particular to each field stays particular.

Fusion
Confidence
Workflow
Governance
Commercial discipline

Start narrow. Prove the value. Expand on evidence.

Beachhead: One urgent workflow and one accountable buyer

Pilot: Representative data and a scorecard agreed in advance

Expansion: More sites, sources, modules or users, as the evidence warrants

Commercial terms: Priced to the value actually created

The pilot

The smallest proof that would change your mind.

A pilot is not a demonstration. It runs on representative data, with the people who will live with the result, and it is judged against a baseline agreed before the work begins, including the result that would tell us we were wrong.

01

Agree on what must improve

Name the operator, the present failure, the data that actually exists, the baseline, and the decision that has to get better. Ambiguity at this stage is the most expensive thing in the engagement.

02

Connect to the real thing

Integrate representative feeds and the systems already in use, set the operating rules, and fix the scorecard before testing begins, so that the standard cannot move once the results arrive.

03

Run it with the people who will own it

Work through realistic scenarios. Keep the misses and the overrides, not only the highlights, and compare the quality and speed of response with the baseline agreed at the start.

04

Scale only what the evidence supports

Turn measured results into a deployment plan, a support model, an integration scope and commercial terms that reflect the value actually created.

The company

Engineering discipline, applied where the consequences are real.

Sahasranshu is an engineering-led product company in Bengaluru. We build systems that can be inspected, integrated and held to account, for institutions that cannot treat reliability as an aspiration.

Siddarth Pai, Founder and CEO of Sahasranshu
Siddarth Pai · Founder & CEO

A career spent building the systems that other systems depend on.

Siddarth is a platform architect and software engineer. At GE Healthcare, JPMorgan Chase and Walmart Global Tech he worked on distributed systems, data pipelines and event-driven architecture, in settings where throughput, reliability and observability are not features but obligations.

Education
University of Connecticut
University of Connecticut
MS, Business Analytics and Project Management
Manipal Institute of Technology
Manipal Institute of Technology
M.Tech
Previously
  • Walmart Global Tech
  • JPMorgan Chase
  • GE Healthcare
  • Infosys
  • Tech Mahindra
Distributed systems
Event-driven data
Controlled workflows
Integration architecture
Bengaluru, India Product-led People in command
Work with us

Show us the watch floor that still depends on manual triage.

We work with maritime authorities, ports, offshore operators and systems integrators on bounded engagements with a defined end, and with utilities, industrial sites and financial institutions on the products that follow. If the evidence does not support going further, that is a useful result, and we will say so plainly.

siddarth.pai@sahasranshu.com
+91 97427 21697Bengaluru, India