The Tracking Portal

What this chapter covers

The tracking portal at track.korido.net is Korido's public face — the view a shipper or consignee opens from a link to follow one delivery. This chapter describes who it serves, what a customer sees (live progress, an arrival estimate, a journey timeline), the strict privacy filtering that shows only that one mission and only customer-safe facts, and how a link is gated, scoped, and eventually expires.

Who it is for

The portal is for customers — the shipper, broker, or recipient of a haul — who have no Korido account and never needed one. They arrive from a link an owner shared, typically over WhatsApp. The owner or dispatcher creates, shares, and revokes those links from the fleet app; the customer only views and, when finished, disconnects.

The portal sits at a high-trust boundary. A dispatcher's console is dense with internal mission state, driver identity, device health, Route Guard internals, and tenant records. A customer should see none of that — only the delivery facts that help them orient on the Douala-N'Djamena corridor. Getting that boundary right is the portal's defining job.

Getting in: the phone gate

A tracking link is a per-mission URL carrying an opaque, unguessable token. When the owner creates it, they enter the recipient's phone number; Korido stores only the gate proof it needs, never the phone number itself. Mission, client, and convoy-context links hash the last four digits because the customer already knows which run they received. Ad-hoc links hash the normalized full phone number, because there is no mission context on the link to help the customer recognize it. To open the view, the customer confirms the form that link expects.

That gate is not a password — its job is to reduce accidental forwarding and confirm the viewer probably holds the phone the link was meant for. The real controls sit behind it: the token is unguessable, attempts are rate-limited, and once the gate passes, a signed cookie tied to that specific link keeps the customer in without re-entering the digits. A missing, revoked, or expired link is indistinguishable from a wrong-number attempt before the gate passes, so the portal never leaks whether a link exists.

What the customer sees

Past the gate, the portal opens as a full shipment view — map-first, with just enough context to recognize the load: the vehicle plate or reference, the cargo when available, origin and destination, the truck's current place, and how fresh that position is.

Live progress. The map shows the truck's current public position and its recent trail, projected along the route. It refreshes on a roughly 30-second poll. Position freshness is told honestly, never faked: a fresh fix shows a small heartbeat with how long ago it was seen; a truck with no fix yet shows "awaiting first signal"; and a stale position — one past its device-specific staleness window, up to about 70 minutes — is shown with weak-coverage language that reassures the customer that corridor silence is normal while stating plainly when the truck was last seen.

The arrival estimate. The portal shows the best available arrival estimate: the live predicted ETA when Korido has one, falling back to the owner's promised date, and finally to just the destination direction when neither exists. Low or uncertain confidence is shown as such rather than dressed up as a precise time. No negative incident signal ever reaches the customer — no breach states, no anomaly counts — so corridor trouble stays on the operator's side of the boundary. The one anomaly-derived signal a customer ever sees is a positive one: when a corridor anomaly that was disrupting the route has recently cleared, the peek card carries a quiet "Itinéraire en rétablissement" note — a reassurance that the road is recovering, shown only while arrival still matters and dropped once the delivery is done. The estimator behind these numbers lives in Part 5 — Missions.

The timeline. A waypoint-based journey timeline shows the stops that matter — titles, arrival and departure times, dwell where known, and compact per-leg distance and duration — so the customer can read the trip as a story.

The delivery status a customer sees is a curated public phase, not Korido's internal mission state:

The six public phases — Programmé, En transit, Arrivé, En pause, Livré, Annulé — map many internal states down to language a customer understands. A pause is only ever shown when an operator has confirmed a customer-safe reason (mechanical, border, administrative, driver rest, cargo check); a pause the engine merely suspects is simply shown as "En transit". The customer never sees raw mission status.

The privacy filter

The portal's central rule is simple: raw internal data does not cross the public boundary. The customer receives an explicitly allowlisted set of facts, and a new data field is private by default until it is deliberately added to that public contract, translated, and privacy-reviewed.

Boundary

The portal exposes a public DTO, not the fleet app's mission object. New fields stay private until they are deliberately added to the allowlist, translated, and reviewed against the customer boundary.

The portal deliberately hides operational detail. Route Guard remains the product name for corridor monitoring inside Korido, but the public view exposes none of its internals — no breach states, no active anomaly counts, no raw alert objects. Border and checkpoint waypoints appear as ordinary timeline stops. Every live payload is keyed by mission, because a customer tracks a shipment — and because one truck can appear in more than one linked shipment. The privacy contract itself is grounded in Part 8 — The platform.

Link gating, scope, and expiry

A link's whole lifecycle belongs to the owner, giving them full control over distribution and revocation:

• Scope. A link can cover one mission or several, and one customer can receive a single link for a convoy of trucks — but a customer only ever sees the missions on their own link, never the wider fleet.
• Expiry. When creating a link the owner picks its lifetime — 7, 14, or 20 days, defaulting to 20 — and the portal caps any link at a hard maximum of 20 days. Once expired, the view closes.
• Revocation. An owner can revoke a link at any time; the next attempt to load it fails cleanly. The owner also sees each link's access count.

Sharing is entirely an owner action. There is no customer-side "share" or "contact the carrier" control — distribution and revocation stay with the operator who owns the shipment.

The boundaries of this surface

• One mission, customer-safe only. The portal shows only the linked mission(s) and only the allowlisted, customer-facing facts. Internal identifiers, raw status, device health, and Route Guard internals never appear.
• Pull-only, today. The customer refreshes a live view; the portal does not push milestone messages. Proactive delivery updates are a future direction.
• No accounts, no portfolio. Access is per-link and anonymous behind the phone gate. There is no customer login or multi-shipment portfolio.
• Korido-branded. The public view carries Korido's own "Livraison" chrome; a linked client name may appear as context, but the portal is not a white-label carrier site and offers no tap-to-call.

Known limitations

• Staleness is judged per device, not on one universal clock. The threshold past which the portal stops calling a position "live" is the same window the owner's offline alert uses: the device's own expected silence — a per-device override, else its model's reporting cadence, else the tenant default — plus a grace beat. In practice that lands roughly between 40 and 70 minutes, depending on how talkative the tracker is: a chatty unit is called stale sooner than a sleepy one that only heartbeats hourly. This is deliberate — it keeps the customer's "live" indicator honest against the exact boundary the operator is alerted on — but it does mean two trucks can cross into "stale" at different ages.

How it connects

• The fleet app — where an owner creates, shares, and revokes the links this portal serves.
• Clients — where a client's tracking links are administered, grouped by the customer they were shared with.
• Part 5 — Missions — the mission lifecycle and ETA the public phases and estimate are derived from.
• The WhatsApp channel — how tracking links reach customers.
• Part 8 — The platform — the tenancy and security model behind the public boundary.