VTMIS data reconciliation decides which value to use when Vessel Traffic Management and Information System (VTMIS) records and anchorage records disagree. They can differ because they describe different facts, arrive at different times or follow different ownership rules.
The rule that settles most disputes is simple: the owning source wins for its field, and a newer value only replaces an older one from the same source. Reconciliation applies that rule while preserving the evidence behind the disagreement.
Choosing the newest timestamp is not enough. An observed position, an arrival estimate and an approved allocation can each be current without carrying the same authority or meaning.
Who Owns Vessel Identity, Call Estimates and Allocation State?
Ownership is rarely whole-record. A traffic system may own observed position, the port's call management may own the expected arrival window, and the anchorage application owns the approved allocation. Write ownership down at that level of detail.
| Fact | Typical Owner | Anchorage Application Role |
|---|---|---|
| Observed position | Traffic or sensor systems | Consumer, with freshness state |
| Vessel identity and master data | Reference system | Consumer, with mapping recorded |
| Expected arrival window | Call or community system | Consumer, may hold a working copy |
| Anchorage request and approval | Anchorage application | Owner |
| Operator decision and audit | Anchorage application | Owner |
VTMIS data comes from a vessel traffic service, guided internationally by IMO Resolution A.1158(32), adopted in December 2021. IALA Guideline 1089 on the Provision of a VTS explains how that service informs and manages traffic.
Integrating VTMIS With An Anchorage Application describes one possible source interface, though the actual source mix depends on the port. Ownership agreed there should not be relitigated in each new integration.
Separate who supplies an observation from who may approve a decision, and record both responsibilities in the ownership matrix.
Match Vessel Identity Before Comparing Values
Reconciliation fails if two systems disagree about which vessel they describe. Match on IMO number first, use the Maritime Mobile Service Identity (MMSI) as a secondary key, and tie each visit to a port call reference.
Route any mismatch between those identifiers to review instead of merging automatically. An MMSI can change when a vessel is reflagged, while the IMO number stays with the hull.
Separate the Requested, the Approved and the Observed
Preserve Different Facts Instead of Choosing One Winner
Three different facts are routinely collapsed into one field and then argued about: the position a vessel requested, the allocation the port approved, and where the vessel is actually observed to be. All three are needed.
The S-211 Port Call Message Format makes the same distinction for port call times, separating estimated, requested, confirmed and actual values rather than overwriting one with another.
Keeping them separate makes exceptions visible. A vessel observed outside its approved allocation is an operational event; if the record overwrites the approval with the observation, the exception and its audit trail both disappear.
Resolve Two Different Readiness Values
Illustrative example
This contract makes the terminal authoritative for berth readiness, while the anchorage application owns allocation approval. Arrival time means arrival of the message, not authority over its contents.
| Source | Value for C-182 | Effective or Received Time | Authority |
|---|---|---|---|
| Terminal revision 4 | Berth ready 13:00 | Issued 09:00; received 09:02 | Owns berth readiness |
| Local operator note | Berth ready 12:30 | Entered 09:03 | Advisory note only |
| Anchorage approval record | AL-7 approved, version 2 | Approved 08:45 | Owns allocation state |
The Reconciled Record and Audit Trail
{
"call_id": "C-182",
"berth_ready_at": "2026-09-18T13:00:00Z",
"readiness_source": "terminal",
"source_revision": 4,
"local_note": "12:30 reported by operator",
"conflict_id": "CF-12",
"resolution": "terminal_precedence; note_retained",
"resolved_by": "coordinator-2",
"resolved_at": "2026-09-18T09:05:00Z",
"allocation_version": 2
}The newer local note does not win because it is not the authoritative field source. The coordinator retains it and can ask the terminal to correct revision 4.
If the terminal becomes unavailable, the last accepted value shows its age, and an approved temporary override needs its own reason, expiry and reconciliation task. Nothing in this readiness conflict changes allocation version 2.
Publish Only the Resolved Fact
| Field | Resolution | Audit and Downstream Action |
|---|---|---|
| Berth readiness | Terminal revision 4 remains authoritative at 13:00 | Publish that revision and the conflict-resolution reference to permitted consumers |
| Operator note | Retained as advisory evidence, not discarded | Preserve author, time and explanation of the disagreement |
| Allocation AL-7 | Remains approved at version 2 | No allocation change emitted; later changes require the authorized workflow |
A consumer should acknowledge the resolved revision or expose a processing failure. A new receipt timestamp does not make an older conflicting value authoritative.
When VTMIS Shows a Vessel Outside Its Allocation
Now suppose VTMIS observes vessel C-182 anchored 0.3 nautical miles outside its approved position in allocation AL-7. VTMIS owns the observed position, while the anchorage application still owns the approval.
| Field | Value | Owner | Result |
|---|---|---|---|
| Observed position | 0.3 nautical miles outside AL-7 at 10:20 | VTMIS | Stored as observed evidence with its timestamp |
| Approved allocation | AL-7, version 2 | Anchorage application | Unchanged; the observation does not overwrite it |
| Exception | Position outside allocation | Anchorage coordinator | Raised with both values visible and assigned for review |
Neither value wins outright, because they answer different questions. The coordinator contacts the vessel or the VTS operator, and any change to AL-7 goes through the authorized allocation workflow.
Define Event Precedence and Staleness
Precedence rules decide which update wins. Use approved source authority first, then source sequence or version where available, then trustworthy event times.
Check clock quality and correction semantics, because timestamps alone do not establish ordering. A late-delivered older observation must never overwrite a newer one.
- A single time base in UTC, with observation time stored separately from receipt time.
- Per-source freshness thresholds after which a value is shown as aged.
- Explicit behavior when a higher-precedence source is unavailable.
- A record of which source supplied each displayed value.
Confirm these rules against how the port actually operates, not an idealised model. AIS, VTMIS and Anchorage Management Integration shows how the main sources fit together.
Handle Duplicates, Conflicts and Gaps
A version check, such as the Optimistic Offline Lock pattern described by Martin Fowler, rejects a write when the stored version has changed. It protects a record update, but it cannot decide who owns a disputed fact.
Duplicate records often come from identity mismatches, such as the same call entering twice under different references. Detect them, present them as a merge decision and keep both originals, because a mistaken merge can join two different calls.
Conflicts need a tolerance and an owner. Within an approved numerical tolerance, apply the agreed precedence rule and keep provenance. Beyond it, raise a review with both values visible.
Identity and approval conflicts need explicit rules rather than a numerical tolerance. Gaps deserve the same honesty: a missing value should read as missing, not as zero or an unqualified last known value.
Run VTMIS Data Reconciliation Continuously
Reconciliation is not only an exception path. Run a scheduled comparison between systems that hold overlapping facts, and report differences as an owned queue rather than a log nobody reads.
- Scope: which entities and fields are compared, and how often.
- Output: a worklist with age, severity and assignment.
- Manual override: permitted, attributed, reversible and recorded.
- Trend: whether the difference count is rising, and where it originates.
Retained event history makes each difference explainable. As When Port Systems Need an Event-Driven Architecture describes, replayable events show how each side reached its value.
Test the Disagreements Deliberately
Acceptance tests should include the cases that cause arguments later. Cover a late observation arriving after a newer one, two sources disagreeing beyond tolerance, and a duplicate call.
Add a source outage during an active allocation, and an operator override followed by a contradicting update from the owning system.
Score each case on whether the resulting record is explainable, not only on whether the system recovered. Carry these requirements into procurement so they are answered before contract, not discovered during testing.
Take one disagreement through detection, assignment, resolution and audit. The result should preserve the source evidence and explain which operational record changed.
For a delivered example, Anchorage Management System Digital Transformation describes an SDLC Corp anchorage project. Ask for its reconciliation evidence when you plan acceptance testing.
Conclusion
VTMIS data reconciliation works when ownership is defined for each disputed field. Test the rule with conflicting values, delayed messages and a temporary override, and make the result explain both the selected value and the evidence set aside.
Give unresolved conflicts an owner and a visible status. When the source returns, reconcile temporary work rather than silently erasing it or leaving the override active indefinitely.
How SDLC Corp Can Help
Discuss field ownership and reconciliation with SDLC Corp when evaluating our Anchorage Management Software and Software Integration Services. Bring real examples where source values and local records disagree.
We will scope a design that preserves provenance, routes conflicts to the right owner and propagates only authorized resolutions. Acceptance tests cover delayed updates, lost responses and manually reviewed corrections before any implementation commitment.
Frequently Asked Questions
Should the Latest Timestamp Always Win?
No. Compare meaning, source authority and provenance before time. A newer observation may describe a different fact from the approved record, while a late message can carry an older value.
What Is a Source of Truth in Port Data?
It is the system that owns a specific field, not a whole record. VTMIS may be the source of truth for observed position while the anchorage application owns the approved allocation for the same vessel.
How Should Vessel Identity Be Matched Across Systems?
Match on IMO number first, use MMSI as a secondary key, and link each visit to a port call reference. Send any mismatch to review rather than merging records automatically.
What Happens When VTMIS Shows a Vessel Outside Its Allocation?
The observation is stored as evidence and the approval stays unchanged. An exception is raised with both values visible, and any change to the allocation goes through the authorized workflow.
What If the Owning Source Is Unavailable?
Use the approved rule for that field: retain the last known value with its age, permit a recorded temporary value, or block the dependent action. Make the condition and responsible owner visible.
Can an Operator Override an Integrated Value?
Only for the fields and roles authorized by the operating policy. Preserve the original value, reason and expiry or review condition, then reconcile the override when the source becomes available.
