Part 8 — The platform: the guarantees underneath

The earlier parts describe what Korido does. This one describes what it promises while doing it — the guarantees every feature quietly leans on, invisible on every screen. A dispatcher trusts that the fuel gauge belongs to this truck alone; that a position buffered through a dead zone still lands; that yesterday's timeline reads exactly as the truck reported it. These are properties of the platform, and this part is where they are made explicit.

Three chapters cover the three promises in turn: how the data is shaped, who is allowed to see it, and how it survives failure.

• Data architecture — how Korido's data is organized into four planes (the road, the plan, what happened, what was learned), why the observed record is written once and never edited, and how a live screen is composed from durable facts at the moment it is asked for.
• Tenancy and security — how one system carries many fleets with no fleet ever seeing another's trucks: a tenant filter enforced in the query layer and proven by a suite that tries to cross it, plus how people sign in, how support safely stands in an owner's shoes, and how a customer gets a private window without an account.
• Reliability — how Korido stays correct when trucks drive through dead zones and databases stall: at-least-once delivery with patient retries, a dead-letter archive that recovers a long outage, strictly serial per-truck processing, and the scheduled jobs that close whatever real life left hanging open.

The unifying idea is that these guarantees are structural. Tenant scope is a type that makes the tenant explicit before a scoped query can run; isolation is completed by the predicate each query writes and by tests that try to cross it. Immutability is an append-only key; correctness under retry is idempotency built into every write path. The platform keeps its promises because breaking them was made hard to miss — which is exactly why the surfaces above can stay simple.