Industry · Logistics

Logistics on the Software Lifecycle Cloud

Logistics products on KERNSTACK give every shipment one timeline and every exception an owner: carrier scans and status callbacks are stored raw, normalised into canonical states per shipment, reconciled against orders by workers, and surfaced — to dispatchers as an exception queue, to customers as a tracking page reading the very same rows. The fog between “the carrier says” and “our system says” is where this architecture earns its keep.

Functions (WASM)Container WorkersNoSQL TablesEdge Gateway
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Regulatory & Sovereignty Context in Logistics

Logistics runs on evidence with deadlines: proof of delivery, claims windows with carriers, customs documentation, and data about recipients that obeys European residency and retention duties. On KERNSTACK the raw carrier events are kept beside their normalised states, so a disputed delivery replays from what the carrier actually sent; exception handling is timestamped work with owners; and recipient data follows the project’s declared retention in one European zone — demonstrable to enterprise customers who audit their carriers’ subcontractors, software included.

Normalise at the border, agree everywhere else

Every carrier speaks a dialect; the mistake is letting dialects leak into the business. Ingestion stores each carrier’s events verbatim, and per-carrier normaliser workers translate them into the project’s canonical states (created, in transit, out for delivery, delivered, exception). Dispatch, customer tracking, and billing then argue from one timeline — and when a carrier renames a status, the fix lands in its normaliser and history re-derives from the raw events.

Exceptions are the work queue

A shipment that stops scanning, hits customs, or bounces back is a flagged row with a reason and an owner, produced by reconciliation workers comparing timelines against expectations. The queue ages visibly; proof-of-delivery and claims evidence assemble from the same records when the carrier dispute arrives weeks later.

  • Raw carrier events retained: any mapping fix replays history correctly
  • “Expected scan missing” is itself a detectable, flaggable state — silence becomes a signal
  • Customers and dispatch read one timeline, so support never translates between two truths

Domain Entities & Workflows Modeled in stack.json

Teams building for Logistics on the Software Lifecycle Cloud model their core domain entities directly in Serverless Tables, index them in Full-Text and Vector Search, and coordinate multi-actor approvals with Workflows:

  • Core Data Entities: shipments · scan events · carrier accounts · exceptions · proofs of delivery
  • Typical Automated Workflows: exception review · carrier replay · proof of delivery · customs document intake · claims evidence export
FAQ

Frequently asked questions

Any with webhooks or a tracking API: webhook carriers store raw events through the gateway route, API-only carriers get a polling worker. Each carrier’s dialect gets one normaliser in your project, reviewed like the rest of your code.

Whatever your reconciliation rules declare: no scan inside the expected window, contradictory states, return-to-sender, customs hold. A flag is a row with a reason and an owner — cleared by a recorded action, never by someone remembering to check a portal.

Yes, and the answer is short: one project, one European zone, raw and normalised events retained together. That is a materially easier audit conversation than a chain of carrier portals, aggregators, and spreadsheets.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Logistics · Specialized ArchitectureShipment tracking for LogisticsShipment tracking for logistics teams: scans from every carrier normalised per shipment, exceptions flagged, one timeline for everyone.Logistics · Specialized ArchitectureWebhook ingestion for LogisticsWebhook ingestion for logistics: carrier and partner callbacks stored raw, processed idempotently, dead letters visible and replayable.Use Case · LogisticsShipment trackingCarrier events enter as webhooks stored raw (the ingestion pattern) or by a polling worker where no webhook exists; a normaliser maps each carrier’s statuses into the project’s canonical states and appends to the shipment’s timeline. Exception rules — no scan for 48 hours, returned to sender, customs hold — are evaluated by the reconciler and written as flagged rows with an owner, converting silent drift into a work queue.Use Case · IntegrationWebhook ingestionThe receiving function does three things only: verify the signature, persist the payload under the provider’s event id, respond. Processing workers claim unprocessed rows, do the real work, and mark outcomes — processed, failed with the error, or dead-lettered after the attempt budget. Because the raw body is stored, reprocessing after a bug fix replays the true payload, not a reconstruction.Role · AgenciesKERNSTACK for AgenciesStudios delivering client projects repeatedly — without adopting each client’s cloud account, or leaving credentials in a password manager as the handoff.Role · CTOsKERNSTACK for CTOsEngineering leaders accountable for residency, review discipline, security posture, and a cloud bill that can be explained to a board.Role · FoundersKERNSTACK for FoundersFounders shipping the first production system without a platform hire — where the stack must be operable by the people who also sell and support it.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →