Glossary
Definitions of the terminology used throughout the Cheetah docs.
The canonical vocabulary for these docs. When a page and the glossary disagree, the glossary wins — and the page has a bug worth reporting.
Core Concepts#
Defect#
A defect is a specific, localized nonconformity found on a part during a program run — a surface flaw, an out-of-tolerance feature, a missing or damaged component. Where a quality check answers "did this measurement pass?", a defect records what is wrong and where. Defects are part of the program run's artifacts and inform the quality report.
Frame#
A frame is an individual capture within a session — an RGB, depth, infrared, or point-cloud capture, stored with the robot's exact pose at capture time. Frames are the finest-grained entity in the data model and the raw input analysis consumes; their files are retrievable over the open REST API.
Operator#
The operator is the person running inspections at the cell: loading the part, starting the program run, and acting on the QC outcome. Cheetah is designed so a single operator can run the full scan → analyze → report pipeline without metrology training. Not to be confused with the Operator application — the on-cell UI the operator uses.
Program#
A program is the complete, executable definition of an inspection: the motion sequence the hardware follows, the scans captured along the way, and the quality checks evaluated against the captured data. Programs are authored in Program Builder, and every program run records the program it executed — so any result can be traced back to the definition that produced it.
Program run#
A program run is a program executed once against a single part. It is created, begins executing, and ends in exactly one of three ways: completed (a QC outcome was produced), failed (a step errored before producing one), or cancelled (an operator stopped it). Every program run has a stable run_id, and everything the inspection produced — the quality report, its quality checks, any defects — hangs off that identity. The full life of a program run is covered in Program Lifecycle Events.
Always spelled out in full: these docs never call a program run a "run" or an "execution."
QC outcome#
The QC outcome is the overall result of a program run: pass or fail. It is computed by aggregating every quality check after the program's last step finishes, shown to the operator at the cell, and delivered to your systems as the passed field of the ProgramCompleted event. A program run that fails or is cancelled ends without a QC outcome — and the reverse holds too: a part that fails inspection still completes its program run and gets a QC outcome of fail.
Quality check#
A quality check is a single named measurement evaluated against a limit — for example flatness measured at 0.04 mm against a 0.10 mm threshold. Each check records its measured value, the threshold it was compared against, the signed delta between them, and a pass/fail status. The quality report aggregates every check in the program run into the overall QC outcome; the per-check data is delivered in the qc_checks array of the ProgramCompleted event.
Quality report#
The quality report is the primary artifact of a completed program run: the overall QC outcome together with every quality check that was evaluated to reach it. It is the complete digital record of the inspection outcome — what the operator sees on the cell, what is pushed to your systems when the program run completes, and what you can fetch later by run_id through the open REST API.
Revision#
A revision is the auto-incrementing counter of inspections of a single part. The first program run against a serial number starts the count; each time the same part is inspected again, the new program run is automatically assigned the next revision. Distinct revisions are distinct inspections of the same physical part — a new revision often means the part was reworked to address a defect and re-inspected. The revision is carried in every lifecycle event payload as revision.
Serial number#
The serial number identifies the individual physical part — the unit on the table, not its design. (The design or type is a part number; many units share a part number, while each unit has its own serial number.) Every lifecycle event carries serial_number (null if none was captured), and repeated inspections of the same serial number are counted by revision.
Session#
A session groups the frames captured by one scan step of a program run — each capture step creates one. A session carries its own status (active, completed, failed) and is where per-step analysis aggregates. Sessions are not in event payloads; fetch them by run_id through the open REST API.
Hardware#
3D scanner#
The 3D scanner is the sensor that captures the part's geometry — industrial laser profilers that produce the frames Cheetah's analysis consumes. Scanner selection depends on the application, and depending on the configuration the scanner is carried by a cobot, traversed on a gantry, or built into a Rack-Mounted Hardware Scanner's enclosure.
Cobot#
A cobot (collaborative robot) is a robot arm designed to operate alongside people. In Cheetah's Cobot Scanner configuration, the cobot carries the 3D scanner through the program's motion sequence over the part. Gantry and Rack-Mounted configurations position the scanner without a cobot — see the Hardware Platform.
Inspection cell#
The inspection cell is the deployable unit on your factory floor: a hardware scanner configuration plus the onboard compute that runs the Cheetah software stack. One cell runs one program run at a time, end to end — no metrology lab required.
Software Integration#
Open REST API#
Cheetah's open REST API, served by cheetah-service. Where lifecycle events push to you as they happen, the open REST API is the pull side: query programs, program runs, and inspection results on your own schedule — reconciliation after downtime, backfill, historical reporting. Start with the quickstart and the API reference.
Two official client libraries wrap the open REST API, versioned alongside cheetah-service:
Program Lifecycle Events#
The four events Cheetah emits as a program run moves through its life: ProgramStarted, then exactly one of ProgramCompleted, ProgramFailed, or ProgramCancelled. Each event is about exactly one program run and is pushed to your systems as it happens — this is the real-time half of an integration. See Program Lifecycle Events for what they mean and the event reference for exact payloads.
Support#
Tailscale#
The secure remote-access layer used for Cheetah support. Tailscale is a WireGuard-based mesh VPN; with it enabled, Cheetah support engineers can reach a deployed cell for diagnostics and updates without any inbound ports opened on your factory network. Traffic is end-to-end encrypted and access is scoped to the cell. See Support for how to engage support.