Skip to main content

Shipment tracking agent

The latest event is not current shipment truth.

A shipment tracking agent turns authorized carrier, warehouse and partner events into a source-linked movement timeline. The pattern Werkon would validate preserves package and shipment differences, event times, custody boundaries and conflicting evidence. Software determines status from approved rules; accountable transport and service teams investigate exceptions, correct records and decide claims or customer remedies.

Object identity and event meaning

Order, shipment, consignment, handling unit, container, pallet, package, item, vehicle, leg and booking identifiers need explicit relationships. Access to one public reference does not authorize every linked record. Minimize addresses, contents, value, precise location, dangerous-goods, health, customs and claim details according to role and purpose.

Preserve event source, identifier, business step, disposition, read point, location, object relationships, schema, correction and occurrence, capture, receipt and processing times. Arrival order is not event order. Duplicate identifiers do not prove semantic duplication, aggregation does not establish a current parent-child link, and common vocabulary does not prove factual correctness.

Status, estimates and disputed delivery

Keep planned and actual legs, handoffs and custody distinct, with package-level evidence separate from shipment-level status. A scan is not custody, a GPS point is not continuous presence and a sensor reading is not product condition. Promised dates, scheduled windows, carrier estimates and approved upstream model estimates need their own sources and uncertainty; this agent does not invent an ETA.

Missing scans, delayed events, delayed movement and disputed delivery are different exceptions. Signatures, photos and delivered labels have limits: they may not establish recipient authority, correct place, quantity or condition. Accountable owners investigate damage, loss, theft, customs, security and claims, while corrections and appeals remain available.

Tracking boundary

Answer the shipment question without making the event stream more certain than it is.

Tracking crosses organizational, object and custody boundaries. Four jobs preserve a useful answer and every unresolved gap.

01

Requester, object, and disclosure scope

Verify tenant, requester role and relationship, purpose and authorized channel; resolve order, shipment, consignment, container, handling unit, package, item and leg identifiers; and expose only the minimum suitable status and location detail.

Required evidence: Tenant and requester, role and relationship, purpose, authentication and authorization, channel, object identifiers and graph, shipment and package scope, partner boundaries, disclosure class, redaction, language, local time, retention and denied fields.

02

Source event and provenance evidence

Retrieve original events from authorized sources, preserve event, source and record time plus vocabulary and schema versions, validate required values and keep duplicates, corrections, ordering and conflicts explicit.

Required evidence: Source organization and system, event identifier and type, business step, disposition and action, objects, read point and business location, related events and aggregation, source, event, receipt and record times, time-zone offset, schema and vocabulary versions, validation, duplicate key, correction and conflict.

03

Current shipment state and gap

Apply explicit source authority and allowed transitions by object, partner, mode and leg; distinguish planned, physical, custody, condition and delivery states; and report unknown, partial or disputed status rather than infer continuity.

Required evidence: State model and version, object and leg, prior and candidate states, transition result, authoritative event set, last confirmed state and time, as-of time, partial quantities, current parent relation, planned next milestone, estimate source, conflicting evidence, missing expected evidence and correction.

04

Customer answer, exception, and service outcome

Provide a plain-language, time-stamped answer with evidence limits, open one typed exception for missing or conflicting state, preserve accepted ownership and reconcile later delivery, condition, claim and recovery.

Required evidence: Question and channel, answer fields and redactions, evidence references, as-of time, uncertainty and next step, exception type and case, affected objects, facts and unknowns, severity candidate, owner, delivery and acceptance, action, proof of delivery, recipient correction, condition, claim, complaint and recovery.

Question-to-recovery path

Keep query, event, state, answer, and service outcome separate.

A fast answer is harmful when it leaks data or flattens conflicting shipment evidence into false certainty.

  1. 01

    Authorize the question and resolve objects

    Verify requester, role, purpose and channel; resolve every supplied reference to the correct tenant and object graph; set disclosure and location precision; and reject ambiguous or cross-tenant identifiers.

    Owner
    Customer-service, partner, identity, privacy and shipment-data owners
    Evidence
    Requester and relationship, authorization, purpose, channel, references, matched shipment objects, package and leg scope, disclosure fields, redaction, location precision, language, denied access and correction route.
  2. 02

    Retrieve and validate source evidence

    Query only authorized event, order, transport, warehouse, carrier, sensor and service records; preserve raw values and provenance; validate schema, vocabulary, identifiers and time; and label source failures and stale coverage.

    Owner
    Transport, warehouse, carrier, partner, sensor and data owners
    Evidence
    Query sources and time, source responses and failures, original events, object links, business terms, locations, times and offsets, schema and vocabulary versions, validation, freshness, duplicate, correction, ordering and conflicts.
  3. 03

    Derive the current supportable state

    Order evidence under deterministic rules, apply source authority and allowed transitions by object and leg, preserve partial and conflicting states, separate plans and estimates and return unknown when no defensible state exists.

    Owner
    Shipment-state, operations and transport owners
    Evidence
    State-machine version, ordered evidence, source-authority rule, current object relations, transition results, last confirmed event and state, partial quantities, conflicting and missing events, planned milestone, estimate source and as-of time.
  4. 04

    Answer clearly or open an exception

    State the exact object, current supported status, last event, as-of time, planned next step and limits; create a typed case for missing, invalid, conflicting, sensitive or disputed evidence and transfer it to an accepting owner.

    Owner
    Customer-service, transport, security, customs and claims owners
    Evidence
    Question and intent, answer and redactions, evidence references, uncertainty, exception identifier and type, affected objects, facts and unknowns, severity candidate, route, delivery, acceptance, fallback and customer follow-up.
  5. 05

    Correct state and reconcile service

    Let accountable sources issue corrections, preserve the changed timeline and answer, then join delivery, recipient, condition, return, loss, damage, claim, complaint and recovery evidence without calling case closure physical resolution.

    Owner
    Carrier, warehouse, transport, customer-service, claims and recovery owners
    Evidence
    Correcting source and event, superseded state and new state, reason and reviewer, corrected answer, owner action, pickup and facility evidence, custody, proof of delivery, recipient correction, condition, return, loss, damage, claim, complaint, recovery and residual gap.

Authority map

Separate conversational help, deterministic shipment state, and physical authority.

A model can explain an event timeline. It cannot authenticate a scan, decide custody or close a disputed delivery.

01

Deterministic tracking controls

Software owns tenant boundaries, requester authorization, disclosure, object graphs, source connectors, schemas, vocabularies, units, clocks, deduplication, correction, source authority, state transitions, rate limits, retention, exception routing and receipts.

  • Requester, shipment, consignment, container, package, item, leg and event identifiers
  • Source, schema, vocabulary, required-field, time, duplicate, ordering and correction validation
  • Object relation, source authority, allowed transition, partial shipment and as-of state rules
  • Query, answer, exception, owner, correction, delivery and recovery receipts
02

Bounded AI assistance

Models can resolve question intent, find permissioned evidence, translate controlled terms, summarize a source-linked timeline, explain a known code and draft clarification or handoff text while identity, disclosure and shipment truth stay outside them.

  • Question intent, object-reference and language candidates
  • Source-linked timeline, conflict, missing-context and status-summary drafts
  • Plain-language business-step and disposition explanations
  • Clarification, exception summary and customer-handoff drafts
03

Accountable shipment and service authority

Qualified transport, warehouse, carrier, customs, security, customer-service, compliance and claims owners correct source records, determine custody and condition, contact partners, commit to customers, investigate loss or damage and close recovery.

  • Event correction, source authority and shipment-state decisions
  • Custody, condition, customs, security, dangerous-goods and incident interpretation
  • Customer commitment, replacement, refund, return and communication decisions
  • Loss, damage, delivery dispute, claim, complaint, recovery and final closure

Tracking components

Build an object and event ledger, not a status-label scraper.

Useful tracking depends on exact identity and qualified events across partners. Four ledgers keep the answer inspectable.

01

Requester and shipment-object ledger

Bind requester, role, relationship, purpose, channel and disclosure to order, shipment, consignment, transport equipment, container, pallet, package, item, leg, stop and customer references plus current aggregation and partner boundaries.

Operating contract: Tracking code is not identity, public lookup is not full disclosure, order is not shipment, shipment is not package, package is not item, container relation is not permanent, customer reference is not globally unique and one package state is not the whole order state.

02

Event and provenance ledger

Preserve source, original event, business step, disposition, action, read point, business location, objects and relations, event and record times, offset, schema and vocabulary versions, validation, duplicate, correction and conflict.

Operating contract: Shared vocabulary is not shared truth, event ID is not semantic uniqueness, capture is not occurrence, newest receipt is not latest physical event, scan is not custody, location event is not continuous presence, provenance is not trust and late event is not false event.

03

Shipment state and estimate ledger

Version source authority and allowed transitions by object, partner, mode and leg; preserve confirmed, partial, disputed and unknown state, last event, as-of time, missing evidence and separately sourced promised, scheduled, carrier and model estimates.

Operating contract: Planned is not accepted, accepted is not picked up, in transit is not continuously moving, arrived facility is not out for delivery, geofence is not arrival, out for delivery is not delivered, delivered label is not complete good-condition receipt and ETA is not state.

04

Answer, exception, and outcome ledger

Link question, authorized answer, redactions, evidence, uncertainty and correction to exception type, owner and accepted handoff plus later pickup, custody, delivery, recipient, condition, return, loss, damage, claim, complaint and recovery.

Operating contract: Answer shown is not understood, case created is not owner accepted, owner accepted is not action, corrected label is not physical correction, signature is not universal recipient proof, photo is not condition proof, closed ticket is not claim resolution and claim closure is not satisfaction.

Delivery path

Prove one shipment flow, partner set, and question family first.

Begin where identifiers, source authority, event corrections and physical service can be reconciled without exposing sensitive movement data.

  1. 01

    Choose one bounded tracking flow

    Select one tenant, mode, carrier or partner set, shipment and package family, event vocabulary, customer question set and exception owner with stable identifiers and observable delivery evidence.

  2. 02

    Map identity, disclosure, and state

    Inventory requester relationships, object graphs, source systems, events and clocks, business vocabularies, source authority, allowed transitions, partial states, estimates, sensitive fields, exception types, owners and corrections.

  3. 03

    Build source-grounded answers

    Implement permissioned queries, durable evidence storage, validation, deduplication, ordering, corrections, deterministic state, object-scoped summaries, as-of times, visible gaps, minimal disclosure, exception routing and receipts.

  4. 04

    Test broken event histories

    Exercise recycled and cross-tenant references, partial shipments, changed aggregation, late and future events, duplicates, corrections, source conflict, missing leg, outage, spoofed link, restricted location, damaged package, wrong recipient and disputed delivery.

  5. 05

    Release narrowly and reconcile service

    Compare answer accuracy, authorization, freshness, unknown states, corrections, false delivery, exception acceptance, customer effort, physical delivery, returns, claims, complaints and recovery before expanding sources or audiences.

Release controls

Six controls before a tracking answer can claim current status.

Shipment visibility crosses commercial and personal boundaries. These controls preserve honest state and minimum disclosure.

Requester and object scope are verified
Authenticate the requester, relationship, purpose and channel; resolve durable shipment, package, item and leg identifiers; constrain partner and tenant boundaries; minimize location, contents and recipient detail; and block ambiguous or recycled references.
Original events and provenance are preserved
Keep source and organization, raw event, object relations, business terms, locations, event and record times, offset, schema and vocabulary versions, validation and corrections; protect sensitive internals; and never treat common syntax as factual proof.
Order, duplicates, and conflicts stay explicit
Validate required fields and clocks, deduplicate by domain meaning, apply correction relationships, separate occurrence from receipt order, retain conflicting sources and gaps and never let the newest received event win without source and transition rules.
State is deterministic and object-specific
Version source authority and allowed transitions by mode, partner, object and leg; trace partial quantities and current aggregation; distinguish planned, physical, custody, condition and delivery states; and return unknown or disputed instead of inference.
Answers show freshness and evidence limits
Name the exact object, last confirmed event, current supported state, as-of time, planned next milestone and separately sourced estimate; explain uncertainty plainly; preserve correction; and never promise arrival, delivery, refund or claim outcome.
Missing and conflicting truth becomes owned work
Create one attributable exception, route sensitive cases to qualified owners, preserve delivery and acceptance, distinguish missing scan from missing shipment and reconcile pickup, custody, delivery, condition, recipient, return, loss, damage, claim and recovery.

Outcome evidence

Measure trustworthy answers and owned gaps, not tracking queries.

A fast answer with stale or overexposed data creates more customer and operational work. Proof must reach physical service.

Baseline

  • Requester and partner roles, shipment and object families, identifiers, carriers and modes, source systems, event and vocabulary versions, disclosure classes, state models, estimate sources, exception types, owners and retention rules
  • Current customer and operator time from identifier resolution through source query, event review, answer, correction, exception handoff, carrier or facility investigation, delivery, return, claim and recovery
  • Current unauthorized attempts, unknown references, source failures, stale statuses, invalid and late events, duplicates, conflicts, state corrections, false delivery, missing custody, exception misroutes and owner delay
  • Current pickups, facility receipts, departures, arrivals, attempts, deliveries, recipient corrections, condition issues, refusals, returns, loss, damage, claims, complaints and recovery evidence

Outcome evidence

  • Correct requester, object scope, source event, ordering, state, estimate, disclosure, answer, exception and recovery handling against authoritative evidence
  • Authorized answer, current supported status, successful correction, accepted exception and observed delivery by partner, mode, shipment family, language and question type
  • Cross-tenant leak, stale answer, invalid state, unsafe merge, false custody, false condition, false delivery, lost exception and unsupported customer promise prevention
  • Customer and operator effort, source latency, answer correction, exception aging, physical delivery, return, loss, damage, claim, complaint and recovery against the prior channel with shipment and event mix visible

Guardrails

  • Wrong tenant, requester, shipment, package or leg; public code exposing precise location, contents or recipient; recycled identifier; cross-partner leakage; malicious tracking link; inaccessible answer or correction; and data retained beyond purpose
  • Common vocabulary called factual truth, newest receipt called current event, duplicate applied twice, correction ignored, object aggregation stale, one package called whole shipment, source conflict hidden and expected event invented
  • Scan called custody, GPS called presence, sensor reading called acceptable condition, geofence called arrival, out for delivery called delivered, signature or photo called universal proof and estimate presented as committed state
  • Exception lost, security or customs status diagnosed, replacement or refund promised without authority, closed case called recovery and faster answer presented as delivery, satisfaction, saving or reduced claims

Fit test

Use this pattern when identifiers, event authority, and correction paths are durable.

Good reason to begin

  • One flow has stable tenant, requester, order, shipment, consignment, container, package, item and leg identifiers plus explicit partner relationships and disclosure rules.
  • Source systems expose original events, source organizations, event and record times, schema and vocabulary versions, corrections and honest query failures, latency and coverage gaps.
  • Qualified owners define source authority, object relations, allowed state transitions, partial shipment handling, sensitive states, estimate semantics, exception routes and correction authority.
  • Physical pickup, facility, custody, delivery, recipient, condition, return, loss, damage, claim, complaint and recovery evidence can be reconciled beyond status labels.

Resolve before beginning

  • Requester relationship, object identity, partner boundary, disclosure scope, event source, clocks, vocabulary, state model, correction, exception owner or delivery evidence is undefined.
  • The process cannot distinguish order from shipment, shipment from package, event time from receipt time, syntax from truth, scan from custody, planned from actual, estimate from state or case closure from recovery.
  • Success is defined by query deflection or answer speed without authorization, source latency, unknown states, corrections, false delivery, customer effort, exceptions, claims and physical outcomes.
  • The agent is expected to expose precise or sensitive data, scrape labels without provenance, infer missing events, diagnose loss or damage, fabricate delivery, promise remedies, close disputes autonomously or guarantee tracking and delivery.

Source basis

Sources behind the control model.

  • 01

    GS1

    EPCIS Standard 2.0.1

    GS1's archive identifies 2.0.1, published in July 2025, as the latest EPCIS version. EPCIS enables applications to capture, query and share visibility events. It does not authenticate a physical occurrence, prove source honesty, resolve semantic duplicates or event order, establish current aggregation, custody, condition, recipient authority, complete delivery or outcome.

  • 02

    GS1

    Core Business Vocabulary Standard 2.0.0

    GS1 identifies 2.0.0 as the current CBV standard for structures and values used with EPCIS. Controlled business terms improve interoperable meaning but do not prove correct use, event truth, source authority, current shipment state, custody, condition, delivery, compliance or service outcome.

  • 03

    GS1

    Global Traceability Standard 2.0.0

    GS1 identifies this as the current framework for interoperable supply-chain traceability and describes who, what, when, where and why data across object lifecycles. A traceability framework does not verify a particular identifier, partner, event, chain of custody, physical condition, delivery, legal compliance or recovered customer outcome.

  • 04

    World Wide Web Consortium

    PROV-O: The PROV Ontology

    This W3C Recommendation defines classes and properties for representing and exchanging provenance about entities, activities and agents. Provenance structure does not prove that an asserted source is authentic, an activity occurred, a record is complete, a shipment state is current, custody transferred, condition is acceptable or delivery succeeded.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore governed AI agents

Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.

Open path02

Design logistics and transport operations

Frame movement identity, dispatch, routes, tracking, custody, exceptions and service around accountable evidence.

Open path03

Prepare governed route plans

Recommend feasible routes from approved work, time-valid conditions, explicit constraints, dispatcher release and observed execution.

Open path04

Connect supply-chain and logistics decisions

Join demand, inventory, movement, exceptions and realized service without turning forecasts or events into operational truth.

Open path