Core concepts

Customer

The top-level tenant. Everything you create is scoped to one customer_id. A user can belong to multiple customers (employee + contractor, for example); each session picks one. The ACL on every resource keys off this id.

Site

A named place on Earth — usually a polygon with a center point. Sites carry the human-readable name, address, owner metadata, and a stable id. Captures and snapshots roll up to a site.

Capture

A single boots-on-the-ground recording session: WaveForm Field opens its camera + LiDAR stream and saves a bundle of frames, pose, IMU, and depth. Captures are immutable once uploaded.

Snapshot

The output of reconstructing one or more captures: a georeferenced 3D scene of the site at a point in time. The platform timeline is a sequence of snapshots; change-detection diffs consecutive snapshots.

Nav-area

A bounding box (or polygon) used by the nav-pack registry to scope robot consumption. Nav-areas are usually one-to-one with sites, but you can split a large site into multiple nav-areas (depots have a north and south lot, for example).

Nav-pack

The unit of distribution for robot navigation. A pack is keyed on (area_id, profile_key) and contains one or more versions. Each version carries signed layers — map, lanelet, semantic, etc.

Robot profile

The shape of pack a class of robot expects. Profile keys are strings like autoware_outdoor_v1. A profile pins the required + optional layer kinds, the minimum autonomy tier, the allowed CRS list, and whether signatures are mandatory.

Layer

A typed asset inside a pack version. manifest is the canonical JSON description of the pack; map is the navigable surface; lanelet is the road graph; semantic is the labeled point cloud. Each layer has a role (required or optional) and an optional byte_uri for downloading the raw bytes from KMS-encrypted S3.

Autonomy tier

A coarse risk classification on what a pack is good for:

• visual_only — render-only; humans drive.
• l2_assist — adaptive cruise + lane-keeping; humans monitor.
• l4_autonomy — robot drives the route end-to-end.

The autonomy gate on the server refuses to serve a pack at a tier higher than its version was approved for — even if the robot asks for it.

Signature

A cryptographic proof that a pack version came from the customer who claims to own it. The platform supports Ed25519, ECDSA-P256, and RSA-PSS-SHA256. Signatures are verified at publish time (sync) and re-verified periodically (async via SQS Lambda).

Grant

Cross-customer share. By default a pack is visible only to the customer that owns it; grants let you give another customer read-manifest or read-bytes access for a window of time.

Autonomy gate

The §5 server-side check that decides whether a robot can have a pack: must match tier, signature must be valid, version must be active (not blocked), ACL must allow. The gate is the same on every read endpoint.