03 / Verifiable intelligence

SeaVerity.
From a reported position to reviewable evidence.

Maritime observations, AI aggregation and independent verification, brought together in a traceable evidence layer above vessel-position data.

Contribution
Technology & product architecture
Public status
In development · Public proof-of-concept description
Explore the product
Visit SeaVerity
Reporters: Collect permitted observations → AI aggregation: Correlate images, time and location → Controller nodes: Approve, reject or challenge → Maritime events: Deliver traceable context Reporters: Collect permitted observations → AI aggregation: Correlate images, time and location → Controller nodes: Approve, reject or challenge → Maritime events: Deliver traceable context
FIG. 01 / FROM OBSERVATION TO A TRACEABLE EVENT Public conceptual workflow. AI structures the observations; independent controller nodes review what becomes accepted evidence.

The problem

A vessel’s reported position is valuable, but it cannot describe everything happening around the ship. A port operation, a visible condition or an unexpected gap in a signal can require additional context. A professional needs to understand which evidence supports an interpretation and what remains uncertain.

SeaVerity approaches this as a verification problem. It combines permitted real-world observations with AI-assisted analysis and independent review. Its public concept adds a visual evidence layer above the Automatic Identification System (AIS), the vessel-broadcast system widely used to understand maritime positions and movements.

Mickael’s contribution

Mickael’s contribution connects technology and product architecture: the flow from an observation, through processing and verification, to an event that a professional can inspect. It brings together his work on AI products, decentralized systems and explicit trust boundaries.

The product challenge is to give every part of that flow a clear purpose. Contributors provide observations; software structures them; reviewers evaluate the supporting evidence; a user receives contextual information. This case study describes the public architecture and the engineering considerations behind making that chain useful.

Inside the architecture

The public SeaVerity design begins with approved reporters near ports or aboard vessels. They collect permitted visual observations of maritime activity. An observation becomes useful when its image, time and location can be considered together.

AI groups related reports, identifies candidate vessels and event types, checks context and compares available sources. Its role is to turn incoming material into structured evidence that can be reviewed. Independent community-operated controller nodes then approve, reject or challenge the proposed event before it enters the verified layer.

Accepted observations become traceable maritime events. The product is intended to enrich the AIS picture, adding context that a position signal cannot supply on its own. The mobile-app concept extends the evidence supply through contributions made from compatible phones.

Engineering decisions that matter

Preserve the path back to the observation. An interpretation becomes more useful when the person reading it can inspect what supports it. Provenance links an output to its inputs and processing history. It also makes corrections easier to understand when new evidence changes the picture.

Give AI and verification different jobs. Fast aggregation helps manage incoming information. Acceptance of an event requires its own rules and review. Keeping those responsibilities distinct makes it possible to question a model’s interpretation without discarding the original observation.

Represent uncertainty in the product. Evidence may be incomplete, inconsistent or open to more than one explanation. The interface should help a user understand those limitations and identify where review is needed. An apparently precise answer can be less useful than a well-explained uncertainty.

Separate execution integrity from source truth. Hardware attestation can provide evidence about which software processed an input. It cannot, by itself, prove that a photographed vessel was at a particular location. Those conclusions depend on source checks, correlation and the verification process.

From primitives to products

The public concept covers observations such as vessel presence, operations, congestion, weather and visible conditions. For a professional workflow, the value lies in connecting those observations to a specific question and keeping the supporting context accessible.

A useful event record could let an analyst move from an unusual signal to the observations associated with it, then inspect how the interpretation was reached. That describes the product objective, rather than a promise of a particular coverage level or response time. The engineering work is to make the evidence usable inside the decisions maritime teams already make.

A distributed contributor and review network also creates product questions around permissions, participation and evidence quality. Those mechanisms must reinforce the reliability of the information customers receive.

Current maturity & further reading

The public SeaVerity page identifies the system as in development and describes a Fujairah proof of concept. Its planned features, participation rules and geographic availability may evolve with testing. This case study presents that development-stage architecture without treating plans or demonstration figures as operating results.

The official product and mobile-app pages below explain the observation network, the role of AI and the intended independent control layer.

A difficult problem.
A useful conversation.

Working on sensitive data, an AI product or distributed infrastructure? Let’s talk about the system you need to build.

Discuss your architecture
DIRECT CONTACT / MICKAEL CANU