Every claim is tied to a source
A source record carries the issuing authority, title, version, effective date where known, and content identity. Citations are passage-level and pinned to a specific version.
SHEET 02 / 06 / PROBLEM
The knowledge exists. Its basis is hard to find.
To answer a technical question about a ship, an engineer consults regulations, class publications, manufacturer instructions, maintenance records and service reports together. The difficulty is not only finding the information. It is also preserving who issued it, which version it is, and whether it applies to the case at hand.
- FRAGMENTATION
Sources live in different places and formats
Regulatory texts, class publications, manufacturer documents and operational records are kept in separate systems. Information on the same topic never appears in one place.
- REVISION
Choosing the right version is a task of its own
Rules and documents are revised over time. An event must be assessed against the version in force at that date; the latest version is not always the right one.
- BASIS
The conclusion survives, its basis is lost
When an assessment is written into a report, the exact section of the exact document it relied on is often not recorded. Verifying or challenging it later becomes difficult.
- APPLICABILITY
Relevant is not the same as applicable
A paragraph found by search may be relevant to the topic. Whether it applies to that ship, that equipment and that condition must be shown separately.
FIG. 2 · SOURCE FRAGMENTS
- REGULATION · IMOSOLAS / MARPOL requirement
- CLASS PUBLICATION · IACSClass rule or recommendation
- INDUSTRY GUIDANCE · OCIMFOperational guideline
- MANUFACTURER DOCUMENT · OEMEquipment instruction
- OPERATIONAL RECORD · PMSMaintenance record
- FIELD DOCUMENTService report
SHEET 03 / 06 / APPROACH
From source to decision, an unbroken chain.
The core idea of BMMS is that every step stays attached to the one before it. If a link in the chain cannot be established, the system does not fill the gap with a guess; it shows the missing link.
- IMPLEMENTED IN BACKEND
- Implemented on the server side and exercised by automated tests. Does not mean an end-user product interface.
- PARTIALLY IMPLEMENTED
- Core data model and services exist; scope is being extended.
- DEVELOPMENT GOAL
- Accepted development direction; not yet implemented.
THE FULL CHAIN IN THE PROJECT DOCUMENTSSource → SourceVersion → Passage → Authority → Applicability → Obligation → Evidence → Engineering Assessment → Human Decision → Residual Obligation → Assurance State → Audit History
-
IMPLEMENTED IN BACKEND
Source and version
A document is recorded with its issuing authority, version and, where known, effective date. The raw document is stored unchanged; a correction is added as a new version.
-
IMPLEMENTED IN BACKEND
Passage
The document is split into sections with stable identities. A citation points to a specific passage in a specific version, so the same citation still shows the same text years later.
-
PARTIALLY IMPLEMENTED
Applicability
Whether a retrieved passage applies to this ship, this equipment and this event is assessed separately. If the context is insufficient, the state remains “indeterminate”.
The authority, revision and applicability foundation is in place; its scope is being extended.
-
PARTIALLY IMPLEMENTED
Obligation and evidence
Applicable requirements are linked to the evidence claimed to satisfy them. Missing evidence does not mean the requirement does not exist.
Links between claims and evidence exist in the backend. Establishing a complete obligation set is a separate line of development.
-
PARTIALLY IMPLEMENTED
Expert decision
The final assessment belongs to an authorised person. The reviewer and the person holding decision authority are kept distinct; AI output is not treated as verified evidence.
Review status is held in the data model; the reviewer interface is at prototype stage.
-
DEVELOPMENT GOAL
Assurance state
The conclusion is recorded together with its scope, the source versions used, the evidence set, the decision authority and any residual obligations. It is re-evaluated when conditions change.
-
IMPLEMENTED IN BACKENDRecords are written to an append-only audit history. An old record is never deleted; it is superseded by a new one.
SHEET 04 / 06 / WORKED EXAMPLE
Same sources, different context, different outcome.
Change the context below. Watch which passage is treated as applicable, where the evidence attaches, and in which case no conclusion is produced.
QUESTION
Does the fuel used on this voyage meet the sulphur content requirement?
1 · RETRIEVED PASSAGES
Passage A — Limit applicable inside an ECARepresentative source · with version and passage identity
Passage B — General limitRepresentative source · with version and passage identity
2 · EVIDENCE
Bunker delivery noteRepresentative document
3 · STATE
Representative scenario. The topic is simplified from the fuel sulphur limits under MARPOL Annex VI. Passage and document names are illustrative; they are neither quotations from a real source nor output produced by BMMS. The purpose is to show the states the system is designed to distinguish.
SHEET 05 / 06 / SCIENTIFIC APPROACH AND QUALITY
What does trustworthiness rest on?
In BMMS, quality is not measured only by the rate of correct answers. The basis, scope and uncertainty of a conclusion must also be explicit, measurable and auditable.
RETRIEVED≠AUTHORITATIVE≠CURRENT≠APPLICABLE≠SUFFICIENT
The core distinction in the project's rule set: retrieving a passage does not mean it comes from an authoritative source, is current, applies to this case, or is sufficient on its own. These distinctions are defined as invariants in the code and project documents.
What enters the system is explicit
The rights basis on which each source family was admitted is recorded. Being able to access a document does not mean having the right to process it; material with unclear rights is held for review.
The unknown stays unknown
When the basis cannot be established, an “indeterminate” or “review required” state is recorded explicitly. Having identified no gap does not prove that the case is closed.
Decisions belong to an authorised person
Model output is never stored as verified evidence without an explicit, recorded human approval. Having reviewed a record is not the same as holding decision authority.
Which method ran is never hidden
The default retrieval method is lexical. Semantic and hybrid methods were tested in an experiment with pre-registered criteria; because they did not meet the promotion criterion, they remain experimental and are never switched on silently.
An easy test is a failed test
Alongside the aggregate score, critical failures such as false closure, missed obligations and failure to abstain are tracked separately. A calibration set on which current models hit a ceiling was marked “too easy” and not used for ranking.
ENGINEERING DISCIPLINEArchitecture decision records (ADR)Immutable evidence storeStrict type checkingFailure and edge-case testsAutomated quality gates on every changeIndependent review
SHEET 06 / 06 / STATUS AND CONTACT
Where does the project stand?
The breakdown below is based on the project's own task and decision records.
COMPLETED
Core foundation
- Authority, source and version model
- Immutable evidence store with content identity
- Passage extraction from documents, stable passage identity
- Lexical evidence retrieval and evidence bundles
- Abstention, provenance and audit records
- Regulatory authority, revision and applicability foundation
- Semantic and hybrid retrieval experiment (pre-registered; not made default)
IN PROGRESS
Controlled pilot preparation
- Testing the workflow under real conditions in a controlled, single-organisation setting, with sources whose rights basis is established
- Reviewer interface at prototype stage
Pilot readiness is not considered complete until it is demonstrated with runtime evidence on a specific release.
GOAL
Accepted development direction
- Multiple source families: IMO / SOLAS / ISM, MARPOL / MEPC, IACS, OCIMF and authorised manufacturer documents (where rights permit)
- Case-based evaluation set
- Operational modules for equipment, maintenance, certificate and obligation tracking
- Signed export and verifiable evidence package
An accepted architecture direction is not an authorisation to implement.
BMMS is a research and development project. It is not a production system, and it is not certified or approved by any authority.
COLLABORATION
Let's test the method together.
What the project needs most is critical, independent scrutiny. We welcome conversations on academic review, research contributions and collaboration in the areas below.
Academic review
Critical examination of the epistemic distinctions, the representation of uncertainty and the evaluation design.
Research contribution
Document structure extraction, information retrieval evaluation, source traceability and decision processes in which humans and AI work together.
Domain expertise
Expert input on maritime engineering, classification and regulatory frameworks.
Case-based evaluation
Jointly developing realistic case scenarios with calibrated difficulty.
Methodological questions such as source traceability, making uncertainty explicit and recording expert decisions are shared across many disciplines. Perspectives from other fields are valuable too.
CONTACT
You are welcome to speak with the project team during and after the presentation.