safetytypesapi

Type Systems for Autonomous Systems: Typing Safety-Critical APIs for Driverless Trucks

UUnknown

2026-02-25

12 min read

Combine TypeScript advanced types with runtime codecs (zod/io-ts) to make safety-critical telematics and tendering APIs auditable and reliable for autonomous trucking.

Hook: Why type safety matters when a wrong API can cost millions — and lives

Autonomous trucking is no longer a lab experiment. By late 2025 major TMS vendors and OEMs pushed integrations that let fleets tender, dispatch, and track driverless trucks in production workflows. The Aurora–McLeod integration is a practical example: a TMS user can now tender a load and have an autonomous truck accept, execute, and report real-time telemetry back into operations. That’s powerful — and terrifying if your API surface is loose.

For teams building safety-critical telematics, tendering, and dispatch APIs, the real challenge is not just “does this compile?” It’s: how do we guarantee that the messages flowing between a TMS and an autonomous vehicle are exactly what we expect, every time, even in the face of schema evolution, intermittent networks, and adversarial inputs? In 2026 the answer is a hybrid approach: combine TypeScript’s advanced static types (generics, conditional types, mapped types) with deterministic runtime validation, codec-based decoding, and contract-driven integration testing.

The core problem: static types alone aren’t enough

TypeScript interfaces and types give you strong compile-time guarantees for your codebase and developer experience. But those guarantees stop at the boundary between processes, runtimes, and networks. An incoming JSON payload from a telematics device, a courier TMS, or another microservice can’t be type-checked by tsc. Without runtime validation, malformed or malicious data can produce catastrophic behavior in safety-critical systems.

Pattern to avoid: define an interface in TypeScript, use it everywhere in code, but never validate input. That trades correctness for developer convenience.

Two practical patterns for safety-critical APIs

In production-grade autonomous trucking systems you’ll use one of these two patterns — or a careful combination — to balance developer ergonomics, performance, and auditability.

Schema-first (recommended): define runtime schemas with a codec library such as zod or io-ts, derive TypeScript types from those schemas, and use the codecs to validate/parse every external boundary. This is the most robust approach for safety systems because the codec is the canonical single source of truth.
Interface-first with generated validators: write idiomatic TypeScript interfaces and automatically generate runtime validators/codecs from those types using tooling (e.g., ts-to-zod / typebox workflows, or OpenAPI generation). This keeps the developer ergonomics of interfaces while producing runtime artifacts.

Why codec-based validation matters in autonomous trucking

Safety-critical data (vehicle state, braking events, geofencing) must be exact and auditable.
APIs evolve: versioning and compatibility rules must be enforced deterministically.
Regulatory audits (ISO 26262-like traceability, UNECE provisions) require reproducible validation logs.
Performance matters: high-rate telemetry streams require careful validation strategies (sampling, lightweight checks, binary codecs) rather than naive deep parsing.

Concrete example: Typing a tender + dispatch + telemetry flow

Below is an actionable design for three API surfaces that typically appear in an Aurora–McLeod style integration:

Tender API — creates a shipment and requests autonomous capacity.
Dispatch API — confirms the assignment and issues driving instructions.
Telemetry API — high-frequency vehicle state and event streams.

1) Schema-first with Zod: canonical runtime schema + derived types

Start by expressing messages as zod schemas. Derive types using z.infer to get precise, composable TypeScript types. Zod (and io-ts) provide deterministic decode/parsing semantics and rich error messages for audits.

// zod-based schema-first example (TypeScript)
import { z } from 'zod'

// Basic branded ID pattern for nominal typing
const TruckId = z.string().min(1).brand<'TruckId'>()
const LoadId = z.string().min(1).brand<'LoadId'>()

// Tender payload
const TenderSchema = z.object({
  loadId: LoadId,
  origin: z.object({ lat: z.number(), lon: z.number(), address: z.string() }),
  destination: z.object({ lat: z.number(), lon: z.number(), address: z.string() }),
  earliestPickup: z.string().refine(s => !Number.isNaN(Date.parse(s)), { message: 'invalid date' }),
  latestDelivery: z.string().refine(s => !Number.isNaN(Date.parse(s))),
  constraints: z.object({ maxPayloadKg: z.number().optional(), hazardous: z.boolean().default(false) }).partial(),
  metadata: z.record(z.string()).optional(),
})

// Dispatch acceptance with versioned commands
const DispatchCommandSchema = z.discriminatedUnion('type', [
  z.object({ type: z.literal('START'), truckId: TruckId, timestamp: z.string() }),
  z.object({ type: z.literal('PAUSE'), truckId: TruckId, reason: z.string().optional() }),
  z.object({ type: z.literal('RESUME'), truckId: TruckId }),
])

// Telemetry envelope — optimized for streaming
const TelemetrySchema = z.object({
  truckId: TruckId,
  seq: z.number().int().nonnegative(),
  ts: z.string(),
  payload: z.object({
    position: z.object({ lat: z.number(), lon: z.number(), altM: z.number().optional() }),
    speedKph: z.number().nonnegative(),
    headingDeg: z.number().min(0).max(360),
    vehicleState: z.object({ braking: z.boolean(), steeringAngleDeg: z.number().optional() }),
    sensors: z.record(z.union([z.string(), z.number(), z.boolean()])),
  }),
  signature: z.string().optional(), // for tamper-evident logs
})

// Derived types
type Tender = z.infer
type DispatchCommand = z.infer
type Telemetry = z.infer

This pattern ensures the runtime validator (the zod schema) is the canonical contract. You decode/parses inputs at the edge, and then downstream code operates on typed data with high confidence.

2) Interface-first with generated validators

Some teams prefer writing plain interfaces because they’re idiomatic and concise. Use a generator to produce runtime validators and/or OpenAPI from these types. This keeps the interfaces as the developer contract while ensuring runtime checks exist.

// Interface-first example (hand-written) - then generate zod/io-ts via tooling
interface TenderV1 {
  loadId: string
  origin: { lat: number; lon: number; address: string }
  destination: { lat: number; lon: number; address: string }
  earliestPickup: string
  latestDelivery: string
  constraints?: { maxPayloadKg?: number; hazardous?: boolean }
  metadata?: Record
}

// A generated validator would be used like:
// const parsed = TenderV1Validator.parse(incoming)
// if it throws, reject and log the validation failure for the audit trail

Tooling options in 2026 include generators that produce zod schemas or io-ts codecs directly from TypeScript declarations, and OpenAPI generation that can feed contract tests for TMS integrations. The important part is: do not stop at types — generate the validator and call it at the boundary.

Advanced TypeScript: generics, conditional types, and mapped types for safety

Use TypeScript’s advanced types to encode invariants at compile time and reduce runtime checks where possible.

Generic envelopes and versioning

Define a generic message envelope to avoid repetitive fields and to mark message provenance and version.

type Envelope = {
  version: V
  messageId: string
  source: 'TMS' | 'Vehicle' | 'Broker'
  payload: T
}

// Use mapped types to create typed handlers for versions
type HandlerMap> = {
  [K in keyof T]: (payload: T[K]) => Promise | void
}

Example usage: create a HandlerMap where keys are message types and values are typed handlers. This prevents accidentally handling a telemetry message with a tender handler.

Conditional types for extracting payload types

Conditional types let you extract payload types from envelopes to write generic processing pipelines.

type PayloadOf = E extends Envelope ? P : never

// typed pipeline function
async function process(env: E) {
  type P = PayloadOf
  const payload: P = (env as any).payload
  // TS knows nothing about payload at runtime; combine with runtime validation
}

Mapped types for sensor maps and strong names

Telemetry often has many sensor keys. Use mapped types to transform raw sensor lists into stronger, documented shapes.

type SensorKeys = 'gps' | 'lidar' | 'radar' | 'camera_front' | 'camera_rear'

type SensorStateMap = { [K in SensorKeys]: { healthy: boolean; lastSeenMs: number } }

// A helper to convert a partial sensor report into a full state map
type WithDefaults = { [K in keyof T]-?: T[K] }

These compile-time guarantees reduce the surface area where runtime surprises can occur and make unit tests much more precise.

Bridging static types and runtime checks — practical patterns

Below are recommended patterns you can apply immediately to an autonomous trucking codebase.

1. Single source of truth: codec-schemas

Put your schemas in a dedicated package (e.g., @company/contracts). Export both the runtime codec and the derived TypeScript type. Use that package in the TMS, vehicle edge agents, simulators, and test suites.

2. Decode at the edges, not everywhere

Validate inputs at the network boundary (API gateway, edge agent), then convert to domain types. For telemetry streams, use lightweight sanity checks at ingestion (seq monotonicity, checksum) and full validation in downstream processing.

3. Defensive decoders with versions and feature gates

Each message should include a version. Build decoders that accept older versions with explicit migrations. Prefer strict parsing and explicit upgrades over permissive parsing that hides incompatibilities.

4. Tamper-evident validation logs

For safety audits, log the raw payload, decode result, and validation errors with deterministic timestamps and cryptographic signatures when possible. This allows forensic replay if something goes wrong.

5. Performance: partition validation workload

For streams with tens of thousands of telemetry messages per second, validate only critical fields inline (seq, truckId, timestamp), and push full validation to a parallel worker or batch job. Use binary encodings (protobuf, Cap’n Proto) with generated validators for high throughput.

Example: safeDecode utility and audit wrapper

import { ZodSchema } from 'zod'

async function safeDecode(schema: ZodSchema, input: unknown, ctx = {}) {
  const start = Date.now()
  const result = await schema.safeParseAsync(input)
  const elapsed = Date.now() - start
  if (!result.success) {
    // Log enough context for forensics, keep PII redaction in mind
    auditLog({ status: 'validation_failed', elapsedMs: elapsed, errors: result.error.format(), ctx })
    throw new Error('Invalid payload')
  }
  auditLog({ status: 'validation_ok', elapsedMs: elapsed, ctx })
  return result.data
}

function auditLog(entry: any) {
  // integrate with your observability stack and write an append-only audit trail
  console.debug('AUDIT', JSON.stringify(entry))
}

Contract testing and CI: make the contract executable

A strong contract is verifiable. Use these practices:

Run schema round-trip tests: codec.encode -> codec.decode should be identity for canonical objects.
Generate API clients (OpenAPI or Zod-to-OpenAPI) and run cross-repo contract tests between TMS and autonomous fleet services.
Use fuzzing and property-based tests to discover edge cases in telemetry (nulls, extreme numbers, boundary lat/lon values).
Integrate contract checks into CI pipelines so a change to a contract package fails dependent repos until consumers adapt.

Regulatory & security considerations in 2026

By early 2026 governments and safety bodies have increased focus on explainability, auditability, and tamper-resistance for automated vehicles. Two practical implications for APIs:

Signed telemetry and non-repudiation: add optional signatures and hashed checkpoints to telemetry envelopes so auditors can verify a vehicle’s reported state at any time.
Immutable contracts and changelogs: maintain a changelog and semantic-versioned schema registry (e.g., a protected Git repo or schema registry service) so you can prove which contract version was live when an event occurred.

When to use io-ts vs zod vs TypeBox (2026 perspectives)

All three are capable. Here’s a pragmatic split based on common trade-offs in 2026:

Zod — ergonomics, synchronous and async parsing, great developer DX, broad ecosystem, and easier inference. Good default for web services and many telemetry use-cases.
io-ts — functional decoding with fp-ts integration; excellent if your stack uses functional programming patterns and you want a fine-grained error model.
TypeBox / JSON Schema — if you need strict JSON Schema compatibility (OpenAPI), binary encodings, or very high-performance schema validation that can be compiled to fast validators.

Real-world trade-offs and patterns observed in 2025–2026 integrations

From integrations delivered in late 2025 and early 2026 — including the TMS/autonomy links similar to Aurora–McLeod — teams converged on these practices:

Make the runtime schema the canonical contract, not TypeScript types alone.
Use versioned envelopes and explicit migrations; never rely on implicit forward/backward compatibility.
Split validation into fast sanity checks and full decoding to protect real-time components from latency spikes.
Log validation failures to an append-only audit store to satisfy safety and legal requirements.

Actionable checklist — implement this in the next sprint

Audit your boundary points and catalog all incoming message types (telemetry, tender, dispatch).
Create a single contracts package and standardize on a codec (zod/io-ts/TypeBox).
Implement decoder + audit wrapper at your API gateway and edge agents using safeDecode pattern.
Define versioning rules and implement automated migration tests for each schema change.
Run contract tests between TMS, brokers, and vehicle simulators in CI; fail the pipeline on contract mismatch.
Instrument validation latency and error rates; consider batched validation for high-throughput telemetry.

Future predictions (2026+): what’s next for type safety in autonomous systems

As autonomous trucking scales, I expect:

More standardized schema registries for safety-critical vehicle APIs, with signed schema artifacts for audits.
Wider adoption of binary-first contracts (protobuf/Cap’n Proto) with autogenerated, validated TypeScript runtimes to reduce payloads and parsing overhead.
Tooling that can generate formal verification artifacts from schemas for high-assurance checks in regulatory submissions.
Edge-native validators that run inside vehicle hardware with attested code to ensure validators themselves haven’t been tampered with.

Final thoughts

The Aurora–McLeod style integrations are a real-world call to arms for engineers: our APIs are not just moving data, they enable physical actions. In 2026 the right pattern is codec-first contracts + advanced TypeScript types for internal correctness. That combination gives you developer ergonomics, runtime safety, and auditability — the three pillars you need to operate autonomous fleets responsibly.

Call to action

Ready to harden your telematics and tendering APIs? Start by extracting your contract schemas into a single package this week. If you want an example repository with zod schemas, codecs, CI contract tests, and simulator integrations modeled after TMS/autonomy links, clone our starter kit and run the included contract tests. Protect your fleet and your company: make validation the first line of defense.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.