Sentriko — One trusted layer for every security sensor

The platform

One layer across a mixed fleet

Four layers, each useful on its own. Together they let a site run equipment from different manufacturers as one system. We've marked where each one stands today.

01 — Interoperability

Every machine, one format

Reads the proprietary 2D and 3D/CT output your scanners already produce and converts it to the open DICOS standard, so one workstation, one algorithm and one record work across equipment from different makers.

Working · 8 scanner families

02 — Fusion

One picture per lane

Brings every sensor on a lane or site into one operator view and one queue. Designed so data is segmented: each agency sees only what it is entitled to, and nothing is shared by default. X-ray first, then body scanners, trace detection and other sensors.

Operator workstation MVP running

03 — Trust

A record that survives an argument

Every image carries a provenance mark that shows if it has been altered, and every deployment and decision goes into a tamper-evident record held on your infrastructure.

Provenance running · ledger specified

04 — Marketplace

New detection, no new hardware

Add qualified detection apps from third-party developers, including threats your manufacturer has no business case to build, on the equipment you already own.

How the marketplace works → Catalogue front end built

Working running today · In build part running in development, part specified. Nothing is yet deployed in live operations — see Where we are.

The problem

The agility gap

Threats change at the speed of software. Screening capability changes at the speed of hardware procurement. That gap is where the risk sits — and it is structural, not anyone's fault.

Every machine is an island

Each manufacturer brings its own image format, its own workstation and its own records. A mixed fleet means operators, analysts and agencies working from separate pictures of the same lane.

One lane, several incompatible views

Capability arrives late

A new threat is identified. Detection for it means a change request into a manufacturer's roadmap, then a validated release, then a fleet rollout. Operators describe a multi-quarter process at best.

Measured in release cycles, not weeks

Some capability never arrives

Wildlife trafficking. Biosecurity. Lithium-ion cells in the wrong place. Real screening problems, each a narrow market — and manufacturers reasonably decline to build detection with no fleet-wide business case behind it.

Niche threats have no OEM roadmap

Experience walks out of the door

Screening officer turnover runs high across the industry. Every departure takes interpretation skill with it, and automated detection is the only part of the capability that doesn't resign.

Detection software doesn't have a notice period

We publish a cost-of-latency model covering throughput, penalty exposure and staffing that quantifies this for a given site. It's built on operator interviews and public data and is available on request — we'd rather walk you through the assumptions than put a headline number on a web page.

How it works

One layer, on the equipment you already have

Sentriko sits alongside your existing screening equipment. It reads the image formats the machines already produce, brings them into one operator view, runs additional detection where you choose to, and keeps a verifiable record of all of it.

01 — CONNECT

Read what the machines already output

Our ingestion layer converts proprietary manufacturer image formats into a common representation, so one algorithm can run across equipment from different makers.

02 — FUSE

See one picture per lane

Images and results from every connected sensor arrive in one operator workstation and one queue, whichever manufacturer made the machine.

03 — EXTEND

Add capability from a catalogue

Browse detection models that have been qualified before listing, see what each does and what it costs, and deploy to chosen equipment from one console.

04 — VERIFY

Prove what happened

Images are provenance-marked, and every deployment and detection event is written to a tamper-evident record held at your site.

Architecture

Built for people who can't take chances

The questions every security director asks, answered before you have to ask them. These are the platform's design commitments; Where we are shows what is running today.

Does this affect my certification?

No. Your equipment manufacturer's own detection is certified and stays exactly as it is — we do not modify, replace or interfere with it. The marketplace targets supplementary, non-mandated detection: threat types that sit outside the certified detection standard. That distinction is deliberate and it is the foundation of the whole design.

Where does my screening data go?

Nowhere. Detection runs on an edge node inside your environment. Screening images do not leave your network. The system operates fully offline — detection, logging and audit all continue with no connectivity — and synchronises catalogue and licensing information to a control plane only when a connection is available and permitted.

Who else sees it?

Only who you decide. Sharing between agencies is designed to be segmented and default-deny: each party sees the data it is entitled to under your policy, and nothing leaves a site unless that policy allows it.

Can I prove what happened?

Yes. Every deployment, configuration change and detection event is written to a permissioned, tamper-evident ledger held locally at each site. It runs offline and re-anchors when the site reconnects. The audit record is yours, held on your infrastructure, and it survives an argument.

Is there a language model in the detection path?

No. Detection models run under a standard inference runtime with deterministic, reproducible behaviour. There is no generative model anywhere in the decision path. We think this matters enough to state plainly rather than leave you to work out.

The marketplace

A marketplace needs both sides

The marketplace sits on top of the platform. Operators want capability that already exists; developers want customers who already have the integration. Interoperability solves the second, so the catalogue can solve the first.

For operators

Security directors

Add detection for threats specific to your route network or region
Keep your existing equipment and your existing certification
One console across equipment from different manufacturers
Priced per integration per year, not per capital purchase

Request more information →

For algorithm developers

AI and detection labs

Build the integration once, reach equipment from multiple manufacturers
Standard inference runtime — bring the model you already have
A route to airport buyers without a multi-year enterprise sales cycle
A deliberately low platform fee, because supply is what the market needs first

Founding developer programme. We plan to co-fund the first algorithms onto the platform directly. If you build detection for a threat type the major manufacturers won't touch, we want to talk.

Get SDK early access →

Who is building this

Thirty years inside the problem

David Pilgrim

Founder, CEO & Principal Engineer

Three decades in screening, detection and critical infrastructure systems, including senior product and business roles at Smiths Detection and Rapiscan Systems. He has sold, specified and delivered screening programmes across Asia Pacific, Europe and the Middle East, and holds an MSc in Engineering Management from the University of East London.

Sentriko exists because the same conversation kept happening. Customers asked for vendor-neutral, open capability. Inside the manufacturers, it was consistently seen as a distraction from selling hardware. The demand was never in doubt; the incentive to build it simply sat with the wrong party.

Why this specific model works. Earlier in his career, David led a project at a previous company to build a custom detection algorithm for a threat a Tier 1 international hub needed and no standard product covered. Long after leaving, the customer's Operations Director told him at a trade show what it had done for them: passenger wait times had gone from 15–45 minutes down to around five.

That result belongs to that operator and that project, not to Sentriko. But the mechanism is exactly what Sentriko productises — the right algorithm for the actual threat, on the equipment already installed. The difference is that it took a bespoke engagement then, and it should take a catalogue selection now.

Sentriko on LinkedIn →

Where we are

Honest status

Sentriko is early. We would rather you knew exactly how early than found out later.

Q3 2026 — done

Working demo

Format conversion working across eight scanner families
End-to-end demo — ingest, deploy, detect, audit
Three Singapore provisional patent applications filed — patent pending

NOW Q4 2026

Hardening

Operator workstation and site mesh network running as MVPs
Reliability, security review and deployment tooling to pilot standard
Founding developer conversations; first algorithms packaged onto the platform

2027

Pilot and open catalogue

First operator pilots in the beachhead markets
SDK and developer onboarding opens
Air cargo alongside aviation

First markets: Asia Pacific and the Nordics — regions chosen for regulatory openness to new screening approaches — plus air cargo sold direct to freight operators.

Get in touch

Request more information

Ask a question, request a briefing, or simply subscribe for updates. Tell us who you are and we'll send what's relevant to you.

We reply personally. Nothing is shared with third parties.