Splenta

Transport - transportation management (TMS)

Blueprint - in design - not yet built

One controlled record
for how goods move.

This page describes the intended design for the Splenta family's transportation system of record - one place that would know what was planned, who accepted it, where it is, why it is late, whether it was delivered, and what the freight cost. It is a blueprint today, not running software.

TMS / TransportOrderDesigned
TO-4821source: wms.package.ready
WH-01 / Dock-3HUB-NDEL / 560102

designed lifecycle

plannedtenderingbookedin_transitdelivered

CX-Freight

carrier

LTL / 2-day

service

3

packages

evidence the record would hold

booking response . label . manifest . tracking id . tracking events . POD . freight cost evidence

Illustrative concept from the TMS blueprint - designed, not live data. No running service backs this card.

A container cargo ship at sea
A container ship in transit. Photo is illustrative, not a TMS deployment.

Designed capabilities

What one movement record is designed to hold.

These are the capabilities the blueprint sets out - one short line each. None is built yet, so each is written as an intent, not a claim.

Order

Transport orders

Designed to turn each request to move goods into one controlled order - source reference, promise, mode and lifecycle.

Movement

Shipments & loads

Designed to hold the concrete movement - packages, stops, service level, carrier and tracking id - as one record.

Carrier

Carriers & tendering

Designed to tender to carriers, capture acceptance, and confirm bookings against contract and serviceability rules.

Tracking

Tracking events

Designed to normalize carrier, telematics, manual and system milestones into one append-only timeline.

Delivery

Proof of delivery

Designed to capture signature, photo, OTP or document as delivery evidence that is never silently edited.

Finance

Freight-cost evidence

Designed to reconcile quoted, booked and invoiced freight, and hand the variance to finance with evidence.

Exceptions

Exceptions & claims

Designed to classify delays, missed pickups, damage and overcharge, and recommend the safest approved next action.

The designed movement sequence

Planned to delivered, one ordered path.

Every movement is designed to walk one ordered sequence, with a control on each transition - no booking without carrier acceptance, no delivered without proof. This is the designed shape, not a running pipeline.

01

Planned

Order becomes a shipment plan

02

Tendering

Offered to carriers

03

Booked

Carrier accepts

04

In transit

Tracking events land

05

Delivered

Proof of delivery captured

The problem

Logistics truth scatters the moment goods leave the dock.

Transport is the seam where commerce, warehouse, procurement and production hand goods to a carrier - and where the truth usually scatters. The blueprint starts from a plain observation: those upstream systems should not all become transport systems. Logistics needs one controlled record of movement. These are the gaps that record is designed to close.
  • Every upstream system grows its own shadow copy of shipment status
  • Bookings, tracking and proof of delivery stay locked in carrier portals
  • Exceptions and freight overcharges reach the team as surprises
Packed boxes stacked in a warehouse before dispatchDock
Goods staged for dispatch. Illustrative photo.

The designed approach

One movement record, from plan to proof of delivery.

The blueprint gives TMS one coherent record for outbound, inbound, reverse, carrier, 3PL and owned-fleet movement. It is designed to know what was planned, who accepted it, where it is, why it is late, whether it was delivered, and what the freight cost. None of this is built yet - it is the intended shape.
  • Designed to plan, tender and book carriers from one order
  • Designed to normalize every tracking event into one timeline
  • Designed to reconcile quoted, booked and invoiced freight for finance
Stacked shipping containers at a freight portIn transit
Shipping containers at a port. Illustrative photo.

Where it would sit

Where TMS would sit.

This is a hypothetical placement, not a benchmark - TMS is a blueprint, so it is compared on design intent, not shipped behaviour. The neighbours are real and keep their real strengths.

Splenta TMS (designed)Standalone TMS suitesSpreadsheets + carrier portals
What it isA designed transportation system of record inside the Splenta familyEstablished, standalone transport suites and 3PL platformsThe status quo - movement status kept by hand across tools and portals
One movement recordDesigned as the single record neighbours hand movement to - plan to PODOwn a strong transport record, integrated case by caseNo single record - truth scatters across systems
Family-native integrationDesigned to share ICE identity and an MCP surface with RMS, WMS, SCM, FMS and EAMIntegrate through custom connectors, system by systemManual re-keying between systems and carrier portals
Agent-ready by designDesigned for Arin to read facts and prepare approval-gated actions over MCPAutomation and APIs vary by vendorNo agent surface
MaturityBlueprint - documents only, not built, no customersShipping products, proven at scaleUniversally available, and universally painful

TMS is pre-code and pre-revenue. Standalone TMS suites keep real breadth and proven scale; spreadsheets and carrier portals are everywhere because they are easy to start with. TMS is designed to trade none of that away except by being family-native and agent-ready by design - a design that does not exist as software yet, which we say plainly.

The designed architecture

The designed architecture, before a line of code.

The story above is the plain version. For evaluators, here is how the blueprint is meant to hold together - the designed transport lifecycle, the proposed agent surface, and the family boundary. All of it is designed, not implemented: there is no service behind any of these panels yet.

The designed transport lifecycle

One coherent record is designed to carry a movement from plan to proof of delivery. Each transition would have a control - no booking without carrier acceptance, no delivered without proof of delivery - and corrections would be append-only, never a silent edit.

draftplannedtenderingbookedready_for_pickuppicked_upin_transitout_for_deliverydeliveredclosed

Reference flow - outbound parcel (the first proof path, designed)

  1. 1RMS captures the customer shipping option and delivery promise at checkout.
  2. 2WMS picks and packs the order, then emits package-ready evidence.
  3. 3TMS creates the shipment plan from WMS package evidence and the RMS promise.
  4. 4TMS selects or confirms carrier and service using contract and serviceability rules.
  5. 5TMS books the carrier and stores the booking response, label, manifest and tracking id.
  6. 6TMS consumes pickup, in-transit, out-for-delivery, delay and POD events.
  7. 7TMS classifies exceptions and recommends the safest approved next action.
  8. 8RMS receives a customer-visible status projection; FMS receives freight cost evidence.

The proposed Arin-over-MCP surface

The blueprint reuses the family pattern already designed for Arin driving SCM: the agent would read facts, classify and prepare an approval-bound action - never book a carrier or close an exception directly. TMS would validate policy and human approval, then execute. This surface is designed, not implemented.

arin -> tms :: designed mcp tool callscope: tms:exception:write
POST /mcp/tools/call
{
"tool": "delivery.exception.resolve",
"args": {"shipment": "SHP-4821", "action": "reschedule" },
"reason": "carrier missed pickup window",
"idempotency_key": "a1f9..."
}
// TMS would check scope, policy and approval state, then:
proposal: awaiting_approval → approved → executed with audit

designed MCP surface - read resources

tms.transport-orderstms.shipment-detailtms.tracking-timelinetms.delivery-exceptionstms.carrier-performancetms.freight-cost-evidencetms.return-pickupstms.route-plan

action tools (approval-gated)

shipment.planshipment.tendershipment.bookshipment.cancelshipment.retenderpickup.scheduleroute.assigndelivery.exception.resolveclaim.preparefreight.dispute.prepare

Every mutating tool would declare a required tms:* scope and an idempotency key. Booking, cancellation, retender, claim and freight-dispute actions would need an approval state and a reason. Proposals would stay proposals until TMS validates policy and a human approves.

The family boundary

TMS is designed to own transport truth and nothing else - not orders, stock, procurement, accounting or fleet-maintenance truth. It would talk to its neighbours only through REST, MCP and events. Every exchange below is part of the blueprint: designed, not built.

ModuleWhat it ownsDesigned exchange with TMS
ICEIdentity and OAuth 2.1 token issuance for the whole family.TMS would validate ICE tokens and own tms:* resource authorization.
RMSCustomer order, checkout, shipping option, delivery promise, payment.TMS would receive order-ready and return requests, and project customer-safe status back.
WMSPhysical stock, package readiness, warehouse dispatch and receiving.Package-ready evidence would drive TMS booking; TMS returns labels and manifests.
SCMSupplier commitments, purchase orders, ASNs and vendor terms.TMS would own inbound movement evidence for supplier and vendor-return shipments.
FMSFreight accruals, invoice approval, payment, accounting and close.TMS would hand over quoted vs booked vs invoiced freight evidence for audit.
EAMFleet assets, maintenance, meter readings and downtime.TMS would read vehicle availability and pass usage evidence for owned-fleet routes.
ArinThe agent layer - explains, classifies, recommends, prepares actions.Arin would consume TMS facts over MCP and prepare approval-bound actions only.
TMSTransport truth: plans, bookings, tracking, POD, exceptions, claims, freight evidence.The transportation system of record the neighbours hand movement to. This page's subject.

Blueprint stage - shaping the design

Help shape the transport system of record.

TMS is a design-stage blueprint, not a product you can buy or run today. If your team lives in the gap between the warehouse and the carrier, we would like to hear how you move goods and where the truth breaks down. That input shapes what gets built first.