Where AI fits in

The whole system in four stages.

Two stages use AI. Two are ordinary, predictable software.

Stage 1
Reports come in
AI reads each maritime accident report - the entire document, not just the headlines - and pulls out structured information: who was involved, what happened, where, when, what was recommended. Alongside that, structured spreadsheets recording the same accidents are read in too.
AI-powered
Stage 2
CHIRP staff verify
A focused web tool lets CHIRP staff review what the AI extracted, correct anything wrong, and approve the rest. Nothing gets relied on for serious analysis until a human has signed it off.
Built software
Stage 3
A clean, searchable database
The verified data lives in a structured database with maps, timelines, dashboards, and search on top of it. This part is ordinary software - predictable, reliable, no AI making decisions about what you see.
Built software
Stage 4
Ask questions in plain language
Optionally, an AI assistant on top that can answer questions in plain English - but every answer is grounded in the database, with every claim linked back to the underlying reports. No invented facts.
AI-powered

One principle behind the whole thing: AI does the reading and the heavy lifting; humans always have the final say on what counts as a fact. The system never silently adds, modifies, or "discovers" things in the database on its own - every AI-generated piece of information goes through a human reviewer before it's relied on for analysis or reporting.

Step by step
Delivery

How this breaks down.

The 19 steps cluster into seven packages. Each one is scoped, quoted, and delivered as its own piece of work.

P1 Steps 1, 2, 3, 4, 5, 6, 7
Foundation
The AI ingestion pipeline (sentences, recommendations, and safety issues), the recognition of people, vessels, and places in each report, the search interface, and validation against a second country's reports.
Already contracted
P2 Steps 8, 9, 10, 11
Verification & provenance
The review tool for CHIRP staff, the audit trail behind every change, original PDFs stored alongside the data, and richer filtering.
P3 Step 12
Semantic layer
The AI similarity work - finding incidents that are related in meaning, not just in keywords.
P4 Steps 13, 14
Broader corpus & legislation
More report types and formats plus linking each finding to the relevant legislation.
P5 Step 15
Production hardening
Authentication, role-based access, API tokens, rate limiting, and monitoring - the security and operational floor needed before external partners like the Alan Turing Institute interact with the system.
Essential
P6 Steps 16, 17
Analytical frontend
Maps, timelines, dashboards, and recommendation tracking - the visual surface on top of a verified, hardened corpus.
P7 Steps 18, 19
Conversational layer
Plain-language questions about the corpus, and AI-assisted drafting for CHIRP staff - both grounded in verified data.
MVP

LLM-enhanced ingestion pipeline

Replaces the NLP pipeline to handle the full range of MAIB report formats - footnotes, page breaks, tables, sidebars - without bespoke rules. Validated against the MAIB corpus and one additional jurisdiction.

Narrative entity model

Extended schema that tracks named actors, vessels, organisations, locations, and equipment through each report - linked at the sentence level so downstream analysis can trace how any actor or object is referenced across an incident.

Full-text search endpoint

A new API endpoint enabling structured queries across documents, entities, recommendations, and safety issues - validating that the ingestion and extraction work has produced genuinely queryable data.


Post-MVP

01
AI-powered

Ingesting MAIB reports through the MVP pipeline

Running the MVP ingestion pipeline over the 659 usable MAIB reports - excluding 137 scanned pre-2005 documents where OCR is out of scope - to produce the structured corpus the Alan Turing Data Study Group will work from.

Happen simultaneously
02

Today the existing pipeline reliably understands roughly six in every ten MAIB reports - the ones in a predictable format.

We're replacing that with an AI-driven pipeline that reads each report end-to-end, pulls out every sentence, and ties each one to its place in the heading tree. That's enough for the DSG to reconstruct the full report from the database and work from the original text in the original order.

SHIELD codes appear throughout MAIB reports and are stored in the database as they appear in the text. Linking each code to the entities it references comes later.

AI's role An agentic system reads the full PDF, identifies each sentence and section heading, and stores them in the database in a form that preserves document order and structure. A human reviewer (see Step 8) verifies the result before it's relied on.
03

MAIB publishes structured data tables alongside its PDF reports. The ingestion stage reads these, mapping their columns into the database alongside the data extracted from the PDFs. Where a spreadsheet records an incident the database doesn't have yet, that gap gets surfaced for review - never silently created.

Not AI Standard structured-data import. The spreadsheets are pre-organised, so reading them is mostly column-mapping into the database. Where a row disagrees with the PDF (different vessel name, different date), the conflict is flagged for review rather than resolved automatically.
04

Once the AI ingestion pipeline is in place, we point it at reports from the United States. That proves two things: the system isn't quietly tied to UK formatting conventions, and adding further countries later is a manageable piece of work rather than a fresh build.

Sample size is the other reason this runs pre-DSG. 659 MAIB reports thins out quickly once split by vessel type and accident category; adding the USA gives the Data Study Group a broader base to draw patterns from.

AI's role The same model that handles MAIB reports is pointed at the USA source. Its output is checked against a human-labelled test set so we can measure how well it transfers.
DSG goal
05

Every MAIB report contains recommendations and identified safety issues. Once the sentences and structure are in the database from Step 2, we go further and pull each of these out as its own structured record - filterable, countable, and later linkable to the legislation and entities it touches.

This is post-DSG because the DSG can already find recommendations and safety issues in the raw text. Structured extraction makes them queryable at scale for everyone who follows.

AI's role The same model that extracted sentences identifies which of them are recommendations or safety issues and pulls them out as separate records with their own fields. Human reviewers confirm these in Step 8.
06

A typical incident report mentions a master, a chief officer, one or more named vessels, the operating company, the port, specific pieces of equipment. Today those references aren't tracked individually - they're just text.

The AI will start recognising each as a named entity and following it sentence by sentence through the report. That makes questions like "every report involving this vessel" or "every incident at this port" directly answerable for the first time.

AI's role The same language model that reads each report identifies the people, vessels, organisations, locations, and equipment it mentions, and links them to the sentences they appear in. Human reviewers confirm or correct these in Step 8.
07

As part of this step, the content produced by steps 2, 5, and 6 - sentences, recommendations, safety issues, and named entities - gets turned into vector embeddings, mathematical representations of meaning. Nothing is embedded before this step; the embeddings only exist once this endpoint is built.

The endpoint queries those embeddings alongside standard structured filters, so matches come back by meaning rather than by exact wording. It isn't a search box researchers click into - it's a machine-facing API that other parts of the system call: the review tool, the plain-language assistant later, and any partner integrations. If the ingestion has done its job, the endpoint's results reflect that.

AI's role An embedding model turns each piece of extracted content into a vector as part of this step, and turns each incoming query into one the same way. The endpoint returns the closest matches by vector similarity. The AI work sits inside the endpoint; callers just hit an API.
08

Automated extraction is useful, but it needs human eyes on it before it's used for analysis or for engagement with regulators. CHIRP staff get a clear, focused web tool for reviewing each report's extracted entities, classifications, recommendations, and safety issues - accepting what's right, fixing what's wrong, and flagging anything that's unclear.

This is what turns AI-generated data into verified data. Until this step happens, nothing the AI produced gets relied on for serious analysis.

Not AI A normal web app - forms, buttons, lists. The intelligence here is the human reviewer, not the software.
09

Every edit made in the review tool is logged. So you can always trace why a record looks the way it does, tell at a glance what's been human-verified versus AI-generated, and demonstrate that quality controls are in place to anyone who needs to see them - researchers, regulators, or partners.

Not AI Standard database logging. Every change writes a record showing the before, the after, and the person who made it.
10

For provenance, for audit, and for spot-checking. If anything in the database looks wrong or surprising, you can open the original document and check. The source report is always one click away from the record it produced.

Not AI File storage, linked to the corresponding database records.
11

As the corpus grows, blunt search becomes less useful. This step adds the ability to ask sharper questions - for example, incidents involving fishing vessels in the North Sea between 2020 and 2024 where loss of life occurred - without needing technical help to get them answered.

Not AI Database filtering. Same input, same output, every time.
12

Two reports might describe the same kind of incident using completely different words. The system will start recognising that they're related - so a search for "fatigue-related navigation error" surfaces cases that never used those exact words but describe the same underlying situation.

This is what makes the corpus useful for spotting patterns rather than just looking things up.

AI's role An AI model converts each sentence, recommendation, and safety issue into a mathematical representation of its meaning. Similar meanings end up close together in that representation, which is what makes "find similar" queries possible.
13

MAIB and CHIRP publish more than just full investigation reports. There are short safety bulletins, annual digests, sector-specific briefings, and CHIRP's own confidential incident reports. Each format carries a different shape of information, but they all cover the same underlying incidents and themes.

More report types from familiar English-language sources gives a richer picture than adding more countries with their own conventions. Depth over breadth.

AI's role The same ingestion pipeline reads the new document types. Where a format has its own conventions, the model is adapted with format-specific prompts. Human reviewers verify the output in Step 8.
14

Maritime safety operates under a stack of regulations - the Merchant Shipping Act, MARPOL, COLREGs, MCA codes, and many more. Linking each report to the specific laws and codes it relates to makes the corpus useful for regulatory analysis, advocacy, and policy work - letting researchers and CHIRP staff see what regulatory landscape each incident sits in.

AI's role AI proposes which legal instruments are relevant to each finding. Human reviewers confirm those links before they appear in the corpus.
15

Up to here, the database has been an internal CHIRP and Tandem tool. Once external partners - the Alan Turing Institute data scientists, partner organisations, future researchers - need access, the system has to be hardened to production standards.

That means proper authentication (logins, sessions), role-based access control (CHIRP admins can see and edit everything; a Turing data scientist gets read access to specific datasets; a partner sees only what's been agreed), API tokens scoped to particular use cases, rate limiting, monitoring and alerting, and a tighter audit trail tied to authenticated users.

Without this step, neither the analytical frontend nor any external API access ships safely.

Not AI Standard production engineering - the security, identity, and operational floor any production system needs. None of it involves AI.
16

The corpus becomes more useful when it's visible. Incident maps. Timelines. Recommendation status tracking. Trend views, sliceable by vessel type, country, and classification.

Designed for CHIRP Maritime, partner organisations, and stakeholders - not for data scientists.

Not AI Standard data visualisation. The numbers shown are exactly what's in the database - no AI judgement layered on top.
17

A core part of CHIRP's mission is improving safety over time. The system will start surfacing the evidence base: was a given recommendation implemented? Have similar recommendations been issued before? Did outcomes change once they were acted on?

Building this picture turns the corpus from a record of what has happened into an instrument for understanding whether safety advice is being acted on.

Not AI Structured tracking of recommendation status over time. The "similar recommendations" links lean on the similarity work from Step 12, but the tracking itself is plain database logic.
18

Once the data is verified and searchable, a natural-language interface becomes worthwhile rather than gimmicky. Ask "what are the most common contributing factors in fishing vessel groundings since 2020?" and get an answer with every claim linked back to the underlying reports.

Nothing ungrounded. Every answer cited. The AI is summarising what's in the database - it can't invent things that aren't.

AI's role A language model takes the user's question, pulls the relevant records from the database, and composes an answer that quotes from and cites those records. The database is the source of truth; the AI is the translator.
19

A starting point, not a deliverable. When CHIRP staff are writing reports, briefings, or follow-up communications, the system can offer draft summaries, paraphrasing, and suggested cross-references - always positioned as a draft for the human to refine.

The AI drafts. The human decides.

AI's role A language model produces a first draft, which a CHIRP staff member reviews, edits, and signs off. Nothing is ever published or sent on the AI's authority alone.
No steps match this filter. Try selecting a different category.