Formant vs Viam

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Formant
   Formant✓fullprobed9/10

   A direct probe confirms llms.txt is live and returns a 200 with structured docs content at docs.formant.io/llms.txt, directly satisfying the story. Missing for 10: no independent third-party confirmation of agent usage or broader agent-oriented doc structure beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.formant.io/llms.txt # Formant Documentation > The Formant software platform allows companies to ru…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Probe confirms llms.txt is live at https://docs.viam.com/llms.txt (HTTP 200) with a structured summary, and Viam also documents an explicit agent-oriented doc page (use-viam-from-an-agent) describing how an AI agent with a shell or SDK can operate a machine. missing for 10: no independent/community corroboration that agents actually consume llms.txt successfully, and no evidence of broader agent-oriented doc index beyond the single page.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.viam.com/llms.txt # Viam > Viam is a platform for building, operating, and managing robots and oth…”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Viam
   Formant~partialclaimed5/10

   Formant provides a Dockerized agent, Python Cloud SDK, Admin API, and webhooks that enable programmatic, non-UI interaction with telemetry, commands, and data ingestion — all of which could be scripted for automated/headless workflows. However, there is no explicit documentation or example of running Formant in a CI pipeline or fully headless automation context; most emphasis is on operator dashboards, teleoperation, and fleet visualization UI. missing for 10: explicit CI/CD integration examples, documented headless mode or automation pipeline guide, evidence of non-interactive/scripted end-to-end workflows.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”

   proof ↗⚑ flag

   Viam~partialprobed6/10

   Viam has a documented CLI that can call any machine API method with JSON in/out, supports SQL queries for data, and explicitly documents agent/headless usage patterns (shell or SDK operating a machine like a person or program), which supports CI/automation workflows. However, evidence lacks explicit CI/CD pipeline integration examples, headless installation/authentication flows for automation contexts, or exit-code/scripting conventions typical of CI tooling. missing for 10: CI pipeline examples/integration guides, non-interactive auth/service-account setup for headless CLI use, independent confirmation of CI usage in the wild.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Formant—none0/10

   Formant is a robotics fleet management platform with SDKs/APIs and an AI assistant for analytics, but there is no evidence of MCP server support allowing external AI tools to plug into Formant, nor of Formant consuming MCP servers itself.

   ⚑ flag

   Viam—none0/10

   Evidence covers Viam being controlled BY an AI agent (agents operating a Viam machine via SDK/CLI) but there is no mention of Viam itself connecting to or consuming external MCP servers/tools as a client.

   ⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Formant—none0/10

   Formant is a robot fleet management platform, not itself an AI agent, so a fair question exists about whether it exposes an official MCP server for agentic access; no evidence pack item mentions MCP at all, only SDKs, REST/webhooks, and Admin API.

   ⚑ flag

   Viam—none0/10

   Viam is a robotics platform (not itself an agent), so publishing an official MCP server is a fair question, but the evidence only shows agent access via CLI/SDK/shell (viam-docs-12, viam-docs-13, viam-docs-31, viam-docs-32) with no mention of the Model Context Protocol or an MCP server offering anywhere in docs or probes.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.viam.com/llms.txt # Viam > Viam is a platform for building, operating, and managing robots and oth…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Viam
   Formant—none0/10

   Evidence shows Formant offers Python Cloud SDK, Agent SDK, RealtimeSDK/toolkit, and REST/Admin APIs, but no documentation or GitHub repo describes an official command-line interface tool.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam ships an official documented CLI (docs.viam.com/cli/reference) supporting data queries, resource control, fleet/org management, and JSON-in/JSON-out API calls that an AI agent can drive directly, with a dedicated guide on using Viam from an agent via shell/SDK. This is agent-friendly and well-documented but lacks independent hands-on corroboration of the CLI itself. Missing for 10: independent/community verification of CLI usage, more detail on agent-specific CLI workflows beyond the single doc page.

   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Formant✓fullprobed8/10

   Formant documents multiple public APIs/SDKs (Agent SDK, Cloud SDK, Admin API, Realtime SDK/toolkit, ingestion API, webhooks) that let developers ingest telemetry, send commands, teleoperate, and build custom apps, with GitHub toolkit repos for hands-on integration. Missing for 10: a discoverable formal OpenAPI/Swagger spec (probe found only 404s) and independent third-party corroboration of API robustness.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam publishes a dedicated doc page explicitly stating 'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can,' backed by CLI/API references (JSON in/out for any API method), fleet API docs, and multi-language SDKs, directly satisfying the AI-native documented public API story. Missing for 10: standard machine-readable OpenAPI spec discoverable (probe found 404s at all candidate openapi.json paths), independent third-party hands-on verification of agent API usage.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Viam
   Formant—none0/10

   No evidence of scoped or least-privilege API credential issuance for agents; Formant docs describe agent SDK, admin API, and commands but nothing about API key scoping, permission levels, or credential minimization. Missing for 10: any documentation of scoped/least-privilege API keys, role-based credential issuance, or agent-specific token permissions.

   ⚑ flag

   Viam~partialclaimed4/10

   Viam's Fleet API/CLI documentation mentions the ability to 'manage permissions and authorization' at the org/location/machine level (viam-docs-20/34/43), and machine credentials are auto-injected for hosted apps (viam-docs-52), implying some access-control primitives exist. However, there is no explicit documentation of issuing scoped or least-privilege API keys/tokens specifically for AI agents, nor any agent-specific credential-scoping workflow beyond generic 'permissions and authorization' management. Missing for 10: explicit API key/token scoping mechanism, agent-specific credential issuance docs, and any least-privilege role examples tied to agent use.

   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage…”
   • [claimed-docs] “A web app hosted by Viam at `{name}_{namespace}.viamapplications.com`. Auth and machine credentials are injected automatically.”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Viam
   Formant✓fullprobed7/10

   Formant documents multiple official SDKs — the Agent SDK (telemetry, commands, teleop), the Cloud SDK (Python) for data ingestion/query, and a public GitHub 'toolkit' repo exposing RealtimeSDK and APIs for building custom apps — giving AI-native developers concrete, first-party libraries to build against. Missing for 10: independent/hands-on developer corroboration beyond vendor docs, and a working OpenAPI/swagger spec (probe shows all candidate OpenAPI endpoints 404), which weakens confidence in full API-contract completeness.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your device, and more”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [github] “Create realtime visualizations of your robots”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam documents official SDKs in Python, Go, C++, TypeScript, and Flutter for building client applications and control logic, with consistent APIs across components (e.g., GetImage) and explicit support for AI agents using an SDK or shell to operate machines. This is corroborated by the GitHub RDK repo listing multiple SDKs. Missing for 10: independent hands-on developer reviews of SDK ergonomics/quality and more detail on SDK completeness/parity across languages.

   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Formant
   Formant✓fullclaimed7/10

   Formant docs explicitly document webhooks triggered from platform events, allowing an HTTP call to any endpoint based on a Formant event trigger, which directly matches the story's subscribe-to-events-via-webhooks capability. Missing for 10: independent/hands-on corroboration beyond first-party docs, and details on payload schema, retries, or auth for webhook subscriptions.

   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”

   proof ↗⚑ flag

   Viam—none0/10

   The evidence pack mentions fleet monitoring, alerting, and data sync, but nowhere describes a webhook subscription mechanism for events. Webhooks are a plausible feature for an IoT/robotics platform, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Formant
   Formant✓fullclaimed6/10

   Formant's own product pages describe an 'AI assistant' for building dashboards from device data and a plain-language fleet query feature that returns ML-driven task recommendations, directly matching the AI-generated insights/suggestions story. Missing for 10: deeper technical documentation of how the AI assistant/insights engine works and independent or hands-on corroboration beyond marketing copy.

   • [claimed-docs] “Using built-in visualizations, custom SQL queries, or our AI assistant, you can build a rich dashboard for your devices.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Ask your fleet what's happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Ask your fleet what’s happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Assigns the right job to the right robot — regardless of who built it — using operational history and live data, and dispatches help the mom…”
   • [claimed-docs] “Tracks historical performance per robot, per mission — speed, error rates, how a given unit has handled a given job before — alongside curre…”

   proof ↗⚑ flag

   Viam—none0/10

   Viam documents data capture, SQL/MQL querying, and ML model training/deployment for machines, plus agent/CLI access to data, but nothing shows the product itself generating AI insights or suggestions from that data for the user (e.g., automated analytics, anomaly summaries, or recommendations surfaced in the app).

   • [claimed-docs] “Create and annotate datasets, and train ML models in your chosen architecture, all through the cloud. Or bring your own model.”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Viam
   Formant~partialclaimed5/10

   Formant provides trigger-based automation (webhooks fired from events, automated commands, and fleet orchestration that dispatches robots/help based on operational anomalies), which can run without a human polling the system — a basic form of background automation. However, this is rule/event-based orchestration rather than a documented framework for autonomous, AI-driven background agents, and there's no evidence of scheduling, persistent agent loops, or independent corroboration of unattended operation. Missing for 10: explicit AI-agent-style background automation framework, scheduling/looping capability, and third-party validation of autonomous operation.

   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”
   • [claimed-docs] “Assigns the right job to the right robot — regardless of who built it — using operational history and live data, and dispatches help the mom…”
   • [claimed-docs] “Heterogeneous Fleet Orchestration assigns the right job to the right robot — regardless of who built it — using operational history and live…”
   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam supports logic modules that react to sensor data, coordinate components, run continuous processes, and schedule actions autonomously (viam-docs-17, viam-docs-38, viam-docs-46), plus scheduled data sync and cloud automation triggers (viam-docs-7, viam-docs-9). This is genuine background automation for physical/robotic systems, but it's not framed as an AI-agent-orchestrated automation builder — it's code-based module logic requiring developer setup rather than a no-code 'set up automation' AI-native workflow. missing for 10: a dedicated no-code automation/trigger builder UI, evidence of AI-native natural-language automation setup, and independent verification that these automations run reliably unattended in production long-term.

   • [claimed-docs] “Use a logic module when you need your machine to: React to sensor data... Coordinate multiple components... Run continuous processes... Sche…”
   • [claimed-docs] “React to sensor data: trigger an alert or an actuator when a reading crosses a threshold. Coordinate multiple components: read from a camera…”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”
   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Formant
   Formant~partialclaimed5/10

   Formant documents a built-in AI assistant for building analytics dashboards and a natural-language interface to query fleet status and get ML-driven task recommendations, but delegation is explicitly gated by human approval ('people approving what happens next') rather than autonomous task execution. Missing for 10: detailed docs on assistant capabilities/API, evidence of the assistant autonomously executing delegated tasks, and independent/hands-on confirmation of this feature working.

   • [claimed-docs] “Using built-in visualizations, custom SQL queries, or our AI assistant, you can build a rich dashboard for your devices.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Ask your fleet what's happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Ask your fleet what’s happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”

   proof ↗⚑ flag

   Viam—none0/10

   Evidence only shows that external AI agents can control Viam machines via the SDK/CLI/shell (viam-docs-12, viam-docs-31, viam-docs-32) — this is the reverse direction (an agent driving Viam), not a built-in assistant inside the Viam product that a user can delegate tasks to. No evidence of an in-app AI assistant/copilot for configuring machines, writing modules, or querying data.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Viam
   Formant~partialclaimed5/10

   Formant's marketing pages mention asking the fleet 'what's happening in plain language' and getting ML-driven task recommendations, plus an 'AI assistant' for building dashboards, indicating some natural-language interaction capability. However, this is only surfaced in marketing copy, not backed by technical documentation, examples, or independent verification, and the bulk of the 'commands' documentation describes predefined/scripted actions rather than open natural-language control. Missing for 10: technical docs on the NL interface, example commands/queries, independent hands-on verification, and clarity on scope of natural-language coverage versus predefined commands.

   • [claimed-docs] “Ask your fleet what's happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Ask your fleet what’s happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Using built-in visualizations, custom SQL queries, or our AI assistant, you can build a rich dashboard for your devices.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam has a dedicated 'use Viam from an agent' doc explicitly describing AI agents operating machines via shell/SDK/CLI with JSON in/out (viam-docs-12, viam-docs-13, viam-docs-30, viam-docs-31), which is strong evidence of agentic operability, but this is API/CLI-driven control rather than a built-in natural-language command interface—an agent must translate NL to API calls itself. Missing for 10: explicit natural-language parsing/command interface within Viam itself, and independent/hands-on confirmation of an AI agent successfully operating a machine via plain-language instructions.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Formant—none0/10

   Evidence shows documentation and SDK references but no interactive API reference with runnable examples; a probe explicitly found no OpenAPI/swagger spec (404s across candidate paths), and no mention of a try-it-now console or code sandbox.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam—none0/10

   No evidence of an interactive, runnable API reference (like a Swagger/OpenAPI explorer or executable code sandbox); a direct probe for OpenAPI/Swagger endpoints returned 404s, and docs only show static CLI/SDK reference pages and a llms.txt file, not a runnable API explorer.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Formant—none0/10

   Formant references an Admin API, Cloud SDK, and query API, but a direct probe for OpenAPI/Swagger specs at common paths returned 404 for all candidates, and no evidence pack item links to a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”

   proof ↗⚑ flag

   Viam—none0/10

   Viam's APIs are built on gRPC/protobuf (viam-comm-3) and documented via CLI/SDK references, but a direct probe for OpenAPI/swagger endpoints returned 404 on all candidate paths, and no evidence pack item mentions a downloadable OpenAPI spec or equivalent machine-readable API description.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Viam
   Formant—none0/10

   No evidence of a sandbox/staging environment, test devices, or any mechanism to isolate testing from production robot fleets and data; Formant's docs focus on production device management, telemetry, teleoperation, and analytics with no mention of sandboxing.

   ⚑ flag

   Viam~partialclaimed4/10

   Viam offers 'test panels' and browser-based controls to 'debug without deploying code' and mentions 'canary testing and rollbacks for safe versioning', which suggest some isolated testing capability, but there is no explicit sandbox environment or data isolation from production described. missing for 10: dedicated sandbox/staging environment concept, explicit guarantee that test data doesn't touch production datasets, and any first-party or community confirmation of production/sandbox separation.

   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Formant—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; probes for an OpenAPI spec all returned 404, and none of the docs mention version numbers or deprecation timelines.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam—none0/10

   The evidence pack shows SDK/CLI/API surface documentation but no mention of API versioning scheme (e.g., v1/v2 endpoints) or any documented deprecation policy for APIs; references to 'versioning' only concern ML model deployment, not API contracts.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Viam
   Formant~partialclaimed5/10

   Formant offers fleet-wide monitoring, orchestration that assigns jobs across many robots, and a single view to manage multiple fleets simultaneously, plus a programmatic Admin API/Agent SDK that could be scripted to issue commands to many devices at once. However, there is no explicit documentation of a dedicated bulk-operation API or UI (e.g., select-many-and-apply-action) for arbitrary bulk actions across devices. Missing for 10: explicit bulk-command/bulk-update API or UI documentation, evidence of batch processing limits/throughput, and independent confirmation of bulk workflows in practice.

   • [claimed-docs] “Tracks historical performance per robot, per mission — speed, error rates, how a given unit has handled a given job before — alongside curre…”
   • [claimed-docs] “Assigns the right job to the right robot — regardless of who built it — using operational history and live data, and dispatches help the mom…”
   • [claimed-docs] “One view across every vendor's fleet — AMRs, quadrupeds, humanoids, arms — without a separate dashboard, update cycle, or incident format pe…”
   • [claimed-docs] “Manage multiple fleets simultaneously from a single operator view”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam's CLI supports bulk data operations — exporting, querying, deleting, and tagging 'all data that matches a given filter' — and Fleet Management APIs let users manage many machines/organizations at once (OTA updates, permissions, fragments) rather than one-by-one. This covers bulk operations on data records and fleet-wide updates, but the evidence doesn't show a general-purpose batch API for bulk manipulating arbitrary resources (e.g., configuring many components/machines in one call) or independent confirmation of these bulk features working at scale. Missing for 10: independent/hands-on verification of bulk operations, explicit batch API for machine/component configuration beyond data tagging, and scale/performance evidence for large fleets.

   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data that matches a given filter”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage…”
   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Formant~partialclaimed6/10

   Formant docs describe event-triggered webhooks ("make an API call to any endpoint over HTTP based on a trigger from a Formant event") and automated incident-response/alerting for anomalies, which directly support rule-based automatic actions on events. However, there's no detailed documentation of a full rules/condition-builder UI, complex logic composition, or independent corroboration of this feature working at scale. Missing for 10: detailed rule-definition interface/logic docs, independent/hands-on validation, examples of multi-condition or chained automations.

   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”
   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam supports event-driven automation via logic modules that react to sensor thresholds and coordinate components (e.g., 'A temperature sensor crosses a threshold, and a notification fires' and 'React to sensor data: trigger an alert or an actuator when a reading crosses a threshold'), which requires writing a custom module rather than a built-in no-code rules engine. missing for 10: a declarative/no-code rules-builder UI, scheduling/cron-style trigger config in the app, and independent/hands-on confirmation that this event-action pattern works reliably in production.

   • [claimed-docs] “Use a logic module when you need your machine to: React to sensor data... Coordinate multiple components... Run continuous processes... Sche…”
   • [claimed-docs] “React to sensor data: trigger an alert or an actuator when a reading crosses a threshold. Coordinate multiple components: read from a camera…”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Viam
   Formant—none0/10

   Formant offers event-triggered webhooks, commands, and fleet orchestration automation, but no evidence describes a scheduler, cron-like recurring job system, or workflow automation that runs on a time-based schedule. Missing for 10: any mention of scheduled/recurring task configuration, cron syntax, or workflow scheduling UI/API.

   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”

   proof ↗⚑ flag

   Viam~partialclaimed3/10

   Viam's docs mention that a 'logic module' can be used to 'Schedule actions' alongside reacting to sensor data, implying developers can build custom scheduled/recurring workflows into a module, but there is no dedicated scheduler, cron-like job system, or workflow orchestration UI documented. missing for 10: a native recurring-job/cron scheduling feature, documentation of periodic execution intervals, and evidence of built-in workflow automation beyond a one-line mention.

   • [claimed-docs] “Use a logic module when you need your machine to: React to sensor data... Coordinate multiple components... Run continuous processes... Sche…”
   • [claimed-docs] “React to sensor data: trigger an alert or an actuator when a reading crosses a threshold. Coordinate multiple components: read from a camera…”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Viam
   Formant—none0/10

   Formant is a robot fleet operations/teleoperation platform; there is no evidence of automation versioning, review workflows, or rollback capability for automations/workflows anywhere in the docs or GitHub toolkit. No mention of version history, change review, or revert functionality for commands, triggers, or workflows.

   ⚑ flag

   Viam~partialclaimed5/10

   Viam documents versioning and rollback for ML models and OTA software/modules (inline modules have Viam-managed 'source code, builds, versioning, and deployment', and canary testing/rollbacks are offered for 'safe versioning'), which extends to automation logic deployed via modules. However there is no explicit evidence of a review/approval workflow for automations, and rollback evidence is framed mainly around ML models and fleet software updates rather than automation logic specifically. Missing for 10: explicit review/approval workflow for automations, direct hands-on evidence of rolling back a logic/automation module (not just ML models or generic OTA software).

   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “Inline modules let you write code directly in the Viam app's browser-based editor. Viam manages source code, builds, versioning, and deploym…”
   • [claimed-docs] “Inline modules let you write code directly in the Viam app’s browser-based editor. Viam manages source code, builds, versioning, and deploym…”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “OTA updates for software and ML models”

   proof ↗⚑ flag

Bring up

1. robotics engineerSwap sensors and actuators behind stable hardware-abstraction interfaces without rewriting application code

   weight 3 · round to Viam
   Formant~partialclaimed3/10

   Formant advertises connecting to 'multiple robot types with minimal lift' with uniform, searchable data ingestion, and unifying different manufacturers' hardware (AMRs, quadrupeds, arms) into one dashboard/data model, which is a coarse form of hardware abstraction at the fleet-telemetry/command level. However, this is about fleet monitoring and teleop integration, not a documented hardware-abstraction API layer that lets a robotics engineer's application code swap out individual sensors/actuators without code changes — there is no driver-interface or HAL SDK evidence for this. Missing for 10: a documented sensor/actuator driver abstraction layer, evidence of swapping specific hardware components without app-code changes, and independent/hands-on confirmation of this working across heterogeneous hardware.

   • [claimed-docs] “Easily connect to multiple robot types with minimal lift. Ensure all data ingested is uniform and searchable.”
   • [claimed-docs] “One view across every vendor's fleet — AMRs, quadrupeds, humanoids, arms — without a separate dashboard, update cycle, or incident format pe…”
   • [claimed-docs] “a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your device, and more”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”

   proof ↗⚑ flag

   Viam✓fullcommunity9/10

   Viam's docs explicitly describe standardized component APIs (e.g., GetImage() for all cameras) so swapping hardware doesn't require code changes, backed by a Registry of drivers for common hardware and a module system for unsupported hardware that then 'behaves like any built-in component.' This is corroborated by community evidence confirming the architecture is real (gRPC-based, open-source RDK) and by explicit doc statements ('If you change a camera or motor in your config, your code keeps working'). Missing for 10: independent hands-on verification from a robotics engineer swapping real hardware in production (only vendor docs and general community architecture confirmation, not a specific swap case study).

   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “If you change a camera or motor in your config, your code keeps working.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself.”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “Once it exists, the hardware behaves like any built-in component. Data capture, test panels, and the SDKs work automatically.”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”

   proof ↗⚑ flag

2. robotics engineerBring up a new robot — drivers, configuration, first motion — in hours rather than weeks

   weight 3 · round to Viam
   Formant~partialclaimed5/10

   Formant provides quick agent installation (Docker/ROS2), an SDK for telemetry/commands, and low-latency teleoperation that can get a robot reporting data and driving within a short setup window, which speaks to fast bring-up of the software/fleet layer. However, it doesn't provide actual robot driver development or low-level hardware integration — it assumes drivers already exist and layers fleet ops on top — and there's no explicit 'hours not weeks' benchmark or case study demonstrating time-to-first-motion. missing for 10: evidence of driver creation/hardware integration tooling, a concrete time-to-bring-up case study or benchmark, first-motion/actuation examples beyond teleop.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “Easily connect to multiple robot types with minimal lift. Ensure all data ingested is uniform and searchable.”
   • [claimed-docs] “Control robot devices from anywhere over a low-latency, peer-to-peer connection, via joystick and buttons.”
   • [claimed-docs] “Formant's teleoperation provides a secure peer-to-peer connection that enables operators to control any aspect of a system.”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Viam's docs describe a first-machine wizard, a hardware Registry that auto-pulls drivers, no-code web test panels to drive motors/arms immediately, and a motion-planning service for first motion — directly matching the 'drivers, config, first motion in hours' story. Community evidence (HN thread) corroborates the architecture (gRPC, open-source RDK, local caching) but raises general skepticism about production fit for industrial use rather than concretely refuting bring-up speed. Missing for 10: independent hands-on timing benchmarks proving 'hours not weeks' and a case where an engineer contradicts the ease-of-bring-up claim.

   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”
   • [claimed-docs] “Click Add machine, enter a name (for example, my-first-machine), and click Add machine again... A wizard dialog will open with the heading I…”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Viam's motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “Critique: 'as someone who has been building robots full time for 7 years, I am struggling to guess which real world application use cases yo…”

   proof ↗⚑ flag

Ecosystem modules

1. developerPull reusable packages or modules from a registry or ecosystem for common hardware and behaviors

   weight 1 · round to Viam
   Formant—none0/10

   Formant provides SDKs, agent installation, and custom module/view building, but there is no evidence of a registry or marketplace of reusable packages for common hardware/behaviors that developers can pull from — modules are custom-built per app rather than shared/discoverable community assets.

   ⚑ flag

   Viam✓fullclaimed8/10

   Viam has a Registry providing pre-built drivers/modules for common hardware (cameras, motors, arms, sensors) that viam-server pulls automatically based on config, plus 'pre-built modules or build your own' for reusable behaviors, and searchable models by manufacturer/type. This is well-documented first-party but lacks independent hands-on corroboration of registry breadth/quality. Missing for 10: independent/community verification of registry module quality and coverage, and any registry browsing UI/API evidence beyond docs claims.

   • [claimed-docs] “Viam's Registry provides drivers for your hardware, so you don't need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Modular Components: Pre-built modules or build your own in any language”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

Sensors

1. robotics engineerIntegrate cameras, lidars, IMUs, and GPS with ready-made drivers and standard message types

   weight 2 · round to Viam
   Formant~partialclaimed3/10

   Formant's docs show a ROS 2 agent install path and a generic Agent/Cloud SDK for ingesting telemetry, plus multi-robot-type connectivity claims, which implies some level of standard-message ingestion (e.g., via ROS topics) but never explicitly names ready-made drivers or standard message types for cameras, lidars, IMUs, or GPS. Missing for 10: explicit driver/adapter documentation per sensor type (camera, lidar, IMU, GPS), confirmation of standard message-type support (e.g., sensor_msgs), and any hands-on evidence of plug-and-play sensor bring-up.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “Easily connect to multiple robot types with minimal lift. Ensure all data ingested is uniform and searchable.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam's Registry provides a searchable catalog of pre-built driver modules for cameras, arms, sensors, and other hardware (explicitly matching by manufacturer/type e.g. webcam, rpi5, xArm6), with standard component APIs like GetImage() ensuring uniform message types across brands, and modules for unsupported hardware can be added easily. Docs and SDK repo corroborate multi-language SDK support and automatic driver initialization from config. Missing for 10: explicit named lidar/IMU/GPS driver examples in the Registry and independent hands-on validation of driver quality/breadth beyond vendor docs.

   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand. Same for motors, sensors, arms, and other components.”
   • [claimed-docs] “Viam's Registry provides drivers for your hardware, so you don't need to implement one yourself.”
   • [claimed-docs] “Viam’s Registry provides drivers for your hardware, so you don’t need to implement one yourself. Specify your hardware model and connection …”
   • [claimed-docs] “Search for the model that matches your hardware. Search by manufacturer or hardware type (for example, `webcam`, `viam:raspberry-pi:rpi5`, `…”
   • [claimed-docs] “When no existing model supports your hardware, you write a driver module to add one. Once it exists, the hardware behaves like any built-in …”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [claimed-docs] “A driver module teaches Viam how to talk to a specific piece of hardware.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

Data

1. developerCapture sensor and telemetry data on-robot and sync it to the cloud with bandwidth-aware policies

   weight 3 · round to Viam
   Formant✓fullclaimed7/10

   Formant's on-robot agent (Docker install, Agent SDK) captures telemetry and sensor data and syncs it to the cloud via the ingestion/query APIs (formant-docs-1, formant-docs-2, formant-docs-3, formant-docs-27), and each data stream can be rate-limited to control bandwidth usage (formant-docs-31), directly supporting bandwidth-aware policies. missing for 10: explicit documentation of offline buffering/store-and-forward behavior during connectivity loss, and independent/hands-on validation of bandwidth policy effectiveness beyond vendor docs.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “Each data stream can be rate-limited, so you don't need to ingest data at high resolution if you don't need it.”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Viam's docs explicitly describe on-device data capture with a built-in data manager that queues locally during outages/low-bandwidth conditions and syncs automatically when connectivity returns, handling storage constraints and restarts (viam-docs-7, viam-docs-28, viam-docs-51). Independent community evidence corroborates offline-first behavior (cached configs, working reboots without internet) (viam-comm-1), and CLI/query tooling for the synced tabular/binary data is documented (viam-docs-11, viam-docs-23, viam-docs-33). missing for 10: granular bandwidth-throttling/scheduling policy configuration details (e.g., rate limits, sync frequency tuning) beyond generic 'low-bandwidth' handling, and independent hands-on benchmarking of sync behavior under constrained bandwidth

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”
   • [claimed-docs] “Data capture means the built-in data manager can capture this type’s output to the Viam cloud.”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”

   proof ↗⚑ flag

2. developerQuery and export collected robot data through an API or SQL for offline analysis

   weight 2 · round drawn
   Formant✓fullprobed8/10

   Formant provides a Cloud SDK/query API for pulling telemetry data for offline analysis (formant-docs-3, formant-docs-27) and Analytics with custom SQL queries for aggregating/analyzing device data over time (formant-docs-7, formant-docs-25, formant-docs-16). Missing for 10: a documented OpenAPI/swagger spec (probe found 404s) and independent third-party corroboration of the export workflow beyond first-party docs.

   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “Using built-in visualizations, custom SQL queries, or our AI assistant, you can build a rich dashboard for your devices.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam's CLI explicitly supports SQL and MQL querying of tabular/binary data with export to a destination path, plus data management APIs and SDKs for programmatic access, directly satisfying the story. missing for 10: independent/hands-on confirmation of SQL export workflow and details on API-based (non-CLI) query mechanics beyond docs.

   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data that matches a given filter”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”

   proof ↗⚑ flag

Data ml

1. developerFeed collected robot data into model training and deploy the improved model back to the fleet

   weight 2 · round to Viam
   Formant~partialclaimed4/10

   Formant provides data export via the Cloud SDK for querying/collecting telemetry (formant-docs-3, formant-docs-27) and a commands mechanism that can trigger scripts or actions on robots (formant-docs-4, formant-docs-9, formant-docs-29), which could theoretically be used to push a retrained model or trigger redeployment. However, there is no explicit documentation of a model-training integration or a dedicated 'deploy model to fleet' feature — the closest is generic 'AI assistant' and 'ML-driven task recommendations' language which is not about custom model training/deployment. Missing for 10: explicit model training pipeline integration, a documented model artifact deployment/update mechanism, and evidence of round-tripping trained models back onto devices.

   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”
   • [claimed-docs] “We can send commands with the click of a button from the Observe view, or during teleoperation.”
   • [claimed-docs] “Ask your fleet what's happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Docs explicitly describe the full loop: capturing data to the cloud, creating/annotating datasets and training ML models (or bringing your own), then pushing trained models to the cloud where machines pull and run inference automatically with versioning/staging/rollback and canary testing, backed by OTA updates for ML models on the fleet. This directly matches the story of feeding data into training and deploying improved models fleet-wide. Missing for 10: independent/hands-on verification of the training-to-deployment loop working in practice and more detail on training architecture options beyond marketing copy.

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [claimed-docs] “Create and annotate datasets, and train ML models in your chosen architecture, all through the cloud. Or bring your own model.”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “OTA updates for software and ML models”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”

   proof ↗⚑ flag

Deploy

1. ops leadDeploy software updates over-the-air to robots with staged rollouts and rollback

   weight 3 · round to Viam
   Formant—none0/10

   Evidence covers agent installation, telemetry ingestion, commands, teleoperation, analytics, and fleet orchestration, but nothing describes OTA software update deployment, staged rollouts, or rollback mechanisms for robot fleets. This is a plausible capability for a robot fleet management platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

   Viam✓fullclaimed7/10

   Viam's marketing/docs explicitly list 'OTA updates for software and ML models' alongside 'Canary testing and rollbacks for safe versioning' as part of Fleet Management, directly matching staged rollout + rollback + OTA requirements, and model versioning/rollback is echoed elsewhere ('Version, stage, and roll back models just like code'). Missing for 10: detailed technical documentation of how staged/canary rollout is configured, and independent/hands-on confirmation that OTA rollback works reliably in practice.

   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “OTA updates for software and ML models”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”

   proof ↗⚑ flag

Fleet

1. ops leadGet alerts on robot faults, battery, and connectivity so issues are caught before customers notice

   weight 2 · round drawn
   Formant~partialclaimed6/10

   Formant supports alerting-related capabilities: 'Set up alerts for anomalies... respond to issues before they become downtime' and webhook triggers from events, plus fleet-wide visibility and analytics dashboards that could surface battery/connectivity/fault data. However, there's no explicit documentation naming battery level, connectivity loss, or fault-code alerting specifically, nor detail on notification channels (email/SMS/Slack) or configurable thresholds. missing for 10: explicit mention of battery/connectivity/fault-specific alert types, notification channel/escalation details, independent/hands-on confirmation of alerting reliability.

   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”
   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam explicitly markets 'Cloud-managed fleet monitoring and alerting' and machine health status APIs (GetMachineStatus reporting unhealthy/configuring resources), plus a generic pattern where 'a temperature sensor crosses a threshold and a notification fires,' which supports fault/threshold-based alerting. However, there's no explicit documentation of dedicated battery-level or connectivity-loss alert configuration, nor any hands-on/community confirmation that these alerts actually fire reliably in practice. Missing for 10: explicit battery/connectivity-specific alert setup docs, and independent evidence that alerting reliably catches issues before customers notice.

   • [claimed-docs] “Cloud-managed fleet monitoring and alerting”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “A camera detects an object, and a motor responds. A temperature sensor crosses a threshold, and a notification fires.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “React to sensor data: trigger an alert or an actuator when a reading crosses a threshold. Coordinate multiple components: read from a camera…”

   proof ↗⚑ flag

2. ops leadPush configuration changes across many robots at once with per-group targeting

   weight 2 · round drawn
   Formant~partialclaimed5/10

   Formant supports device configuration (formant-docs-14/26), custom commands via Admin API (formant-docs-4/9), and multi-device 'coherence group views' (formant-gh-2) plus managing multiple fleets from one view (formant-docs-22), suggesting some grouped/bulk operational capability. However there is no explicit documentation of pushing configuration changes in bulk with per-group targeting as a named feature. Missing for 10: explicit bulk config-push workflow, documented per-group targeting UI/API, and independent confirmation of at-scale config rollout.

   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”
   • [claimed-docs] “configure devices, design custom views and modules, and build a backend for your custom application.”
   • [claimed-docs] “configure devices, design custom views and modules, and build a backend for your custom application”
   • [github] “Modules can now work with multiple devices in coherence group views”
   • [claimed-docs] “Manage multiple fleets simultaneously from a single operator view”

   proof ↗⚑ flag

   Viam~partialclaimed5/10

   Viam's Fleet Management API lets you manage organizations, locations, and machines and 'create and manage fragments' — fragments are Viam's mechanism for defining shared config that can be applied across multiple machines, and locations/organizations provide a grouping structure for targeting. However, no evidence explicitly describes a workflow for pushing a config change to a defined subset/group of robots at once or shows a UI/CLI command for group-scoped rollout beyond generic OTA update mentions. missing for 10: explicit documentation of per-group/segment targeting UI or CLI command, evidence of bulk config push confirmation/rollback across a named group, independent/hands-on confirmation of fragment-based fleet-wide updates.

   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage…”
   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “OTA updates for software and ML models”

   proof ↗⚑ flag

3. ops leadMonitor the health, location, and status of a whole robot fleet from one dashboard

   weight 3 · round to Formant
   Formant✓fullclaimed9/10

   Formant's documentation and marketing explicitly describe fleet-wide visibility ('instant visibility into every robot in your fleet', 'current location and status', unified dashboard across vendors, anomaly alerts), directly matching the ops-lead story of monitoring health, location, and status from one dashboard. Missing for 10: independent/hands-on third-party validation of the dashboard experience beyond vendor docs.

   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”
   • [claimed-docs] “One view across every vendor's fleet — AMRs, quadrupeds, humanoids, arms — without a separate dashboard, update cycle, or incident format pe…”
   • [claimed-docs] “Tracks historical performance per robot, per mission — speed, error rates, how a given unit has handled a given job before — alongside curre…”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Manage multiple fleets simultaneously from a single operator view”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam explicitly offers cloud-managed fleet monitoring/alerting, remote monitoring, access control, and OTA updates, plus a fleet management API to manage organizations, locations, and machines, and configuration to connect and monitor machines 'from anywhere.' This covers health (GetMachineStatus, alerting), status, and centralized dashboard-style fleet management across locations. Missing for 10: explicit mention of a unified 'location' map/view or independent hands-on confirmation of the dashboard UI beyond vendor docs.

   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Viam
   Formant~partialprobed6/10

   Formant exposes broad API/SDK surfaces (Agent SDK, Cloud SDK, Admin API, RealtimeSDK, webhooks, custom commands) covering telemetry, teleop, commands, and data export, and the toolkit lets developers embed/build custom apps mirroring UI functionality. However, some UI-centric features (fleet orchestration dashboards, AI assistant chat, analytics dashboard builder, alerting UI) are not clearly exposed as documented API endpoints, and no public OpenAPI spec was found (probe returned 404s), making full UI-parity via API unverifiable. missing for 10: a published OpenAPI/API reference proving full endpoint parity, API access to fleet-orchestration/AI-assistant/analytics-dashboard features, and independent confirmation of complete UI-to-API parity.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [github] “Embed your own application in Formant”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “A webhook allows you to make an API call to any endpoint over HTTP based on a trigger from a Formant event.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam✓fullprobed8/10

   Viam explicitly documents that AI agents can operate machines identically to UI/human users: 'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can' and 'The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.' Fleet management, data query/export, motion planning, and component control are all exposed via CLI/SDK/API (viam-docs-11, 13, 20, 23, 30-34), mirroring UI capabilities like test panels and driving components (viam-docs-6). Missing for 10: a discoverable OpenAPI spec (probe found 404s across candidate paths) and independent/hands-on confirmation that every UI action (e.g., dataset annotation workflows) has a full API equivalent.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “viam data query tabular sql --org-id=<org-id> --sql=<query> [--destination=<output path>]”
   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.viam.com/openapi.json, https://docs.viam.com/swagger.json, https://docs.viam.com/api/op…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Viam
   Formant~partialclaimed5/10

   Formant provides a documented Python Cloud SDK and query API specifically for exporting telemetry data, and an ingestion API for getting data in, suggesting some data portability. However, there is no explicit documentation of exporting *all* account data, no stated open-format guarantees (e.g., CSV/JSON/Parquet), and no discussion of account closure/data portability policy. Missing for 10: explicit 'export all data' workflow, named open file formats, and confirmation of no vendor lock-in upon leaving.

   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”

   proof ↗⚑ flag

   Viam~partialcommunity6/10

   Viam's CLI documents exporting data in 'a variety of formats' and querying tabular/binary data via SQL or MQL, and the core RDK is confirmed open source (gRPC-based, self-hostable, robots can run offline/on their own server), supporting a genuine 'leave' path. However, the docs don't spell out full-fidelity export of configs/models/permissions or a formal migration guide, and a community comment flags uncertainty about how much of the platform (beyond RDK) is truly open, which tempers confidence without constituting a concrete contradiction. Missing for 10: comprehensive documentation of exporting all data types/configs (not just sensor data) in open formats, and independent verification of successful full platform migration/exit.

   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data that matches a given filter”
   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “User concern: 'I see there is a lot on Github but I'm a bit unsure how much is actually Open Source... I'd be concerned to use one in produc…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Viam
   Formant—none0/10

   Evidence shows only a client-side toolkit/SDK repo (FormantIO/toolkit) for building integrations against Formant's APIs, not the platform's own source code, and no license is mentioned anywhere. Formant is a closed commercial SaaS robotics platform with no indication its core source is open or licensed for reading.

   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [github] “UI custom elements to make your application visually look similar to Formant's ecosystem”
   • [github] “Embed your own application in Formant”

   proof ↗⚑ flag

   Viam~partialcommunity5/10

   A Hacker News community comment states the core RDK is open source on GitHub (github.com/viamrobotics/rdk) while the cloud app itself is closed, which is corroborated by a GitHub reference. However, no first-party documentation confirms an explicit open-source license, and another commenter expresses uncertainty about how much of the codebase is genuinely open, indicating the openness story is only partially substantiated. missing for 10: explicit license file/name in first-party docs, clarity on which components (SDKs, modules, app) are covered vs proprietary, and confirmation the readable source is complete rather than partial.

   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “User concern: 'I see there is a lot on Github but I'm a bit unsure how much is actually Open Source... I'd be concerned to use one in produc…”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Viam
   Formant—none0/10

   Formant is a cloud-hosted SaaS platform; the evidence shows only an on-device agent (Docker-installed) and SDKs that connect to Formant's cloud, with no documentation of a self-hostable core platform/backend. No mention of on-prem or self-hosted deployment options anywhere in the docs or GitHub toolkit.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “configure devices, design custom views and modules, and build a backend for your custom application.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.formant.io/llms.txt # Formant Documentation > The Formant software platform allows companies to ru…”

   proof ↗⚑ flag

   Viam~partialcommunity6/10

   viam-server (the core robot software / RDK) is open source and runs locally on the user's own compute device, and community evidence confirms it can operate fully offline/self-hosted with robots talking to each other without outside communication, but the management 'cloud app' itself remains a proprietary hosted service not shown to be self-hostable, and a community commenter voices uncertainty about how much is genuinely open source. Missing for 10: first-party documentation for self-hosting the full fleet-management/app layer, and resolution of community doubts about open-source scope and production robustness.

   • [community] “The whole system is built on gRPC and everything is open source aside from the cloud app itself; you can run your own server and have multip…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”
   • [community] “User concern: 'I see there is a lot on Github but I'm a bit unsure how much is actually Open Source... I'd be concerned to use one in produc…”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”
   • [claimed-docs] “Click Add machine, enter a name (for example, my-first-machine), and click Add machine again... A wizard dialog will open with the heading I…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Formant—none0/10

   No evidence in the pack mentions data residency, region selection, or geographic storage controls for Formant's cloud platform; all evidence covers robot fleet management, telemetry SDKs, and orchestration features. missing for 10: any mention of data region/residency options, compliance certifications tied to geography, or configurable storage location.

   ⚑ flag

   Viam—none0/10

   No evidence in the pack mentions data region selection, residency controls, or geographic storage location choices for Viam's cloud data management; only self-hosting option (viam-comm-3) is mentioned, which is not region/residency selection.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Viam
   Formant—none0/10

   No evidence pack items address data retention policies, data deletion controls, or privacy/compliance configuration options for AI-native users; the docs focus on telemetry ingestion, teleoperation, fleet orchestration, and SDKs. missing for 10: retention policy documentation, data deletion/export controls, privacy/compliance settings, user-facing controls for data lifecycle.

   ⚑ flag

   Viam~partialclaimed5/10

   The CLI reference documents a data query/delete capability — `delete data, add or remove tags from all data that matches a given filter` — giving users explicit control to remove captured cloud data (viam-docs-23/33/47). However, there's no documentation of configurable retention periods, automated expiration policies, or org-wide deletion/export controls beyond ad-hoc CLI filtering. Missing for 10: documented retention-period settings, data lifecycle/expiration policies, and any independent confirmation that deletion is durable/complete across storage tiers.

   • [claimed-docs] “With it, you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all…”
   • [claimed-docs] “you can export data in a variety of formats, query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data tha…”
   • [claimed-docs] “query tabular or binary data with SQL or MQL, delete data, add or remove tags from all data that matches a given filter”
   • [claimed-docs] “Data Management: Collect, store, and query sensor data and telemetry”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Formant—none0/10

   Formant is a robotics fleet management platform whose core function is telemetry ingestion; no evidence in the pack addresses any opt-out mechanism for telemetry/usage tracking related to the product's own analytics or data collection about users/AI-native usage.

   ⚑ flag

   Viam—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings or privacy controls for Viam's platform or CLI; docs focus on device data capture/cloud sync, not vendor telemetry about usage of the product itself.

   ⚑ flag

Safety

1. ops leadControl with roles and permissions who is allowed to command, configure, or view each robot

   weight 1 · round to Viam
   Formant—none0/10

   The evidence pack covers telemetry, commands, teleoperation, analytics, and fleet orchestration but contains no mention of roles, permissions, access control, or user/team management features that would let an ops lead restrict who can command, configure, or view robots.

   ⚑ flag

   Viam~partialclaimed5/10

   Viam's Fleet Management docs explicitly mention 'access control' and the Fleet API reference states you can 'manage permissions and authorization' for organizations, locations, and machines, supporting role-based access control at a high level. However, the evidence never details specific role types (e.g., viewer vs operator vs admin) or how granularly permissions map to command/configure/view actions per robot. missing for 10: granular role definitions, documentation of specific permission scopes (command vs configure vs view), independent/hands-on confirmation of RBAC enforcement.

   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage…”

   proof ↗⚑ flag

2. robotics engineerImplement emergency-stop and safety-interlock patterns the platform documents and supports

   weight 3 · round drawn
   Formant—none0/10

   The evidence pack covers teleoperation, commands, telemetry, fleet orchestration, and analytics, but contains no mention of emergency-stop or safety-interlock patterns, safety certifications, or documented safety-critical control flows. Since fleet-management/robotics-ops platforms are a fair category for this axis, absence of any e-stop/safety-interlock documentation yields 'none'.

   ⚑ flag

   Viam—none0/10

   The evidence shows general capabilities like motion planning with obstacle avoidance (viam-docs-14/22/39) and logic modules that can react to sensor thresholds (viam-docs-17/38/46), which could theoretically be used to build custom safety logic, but there is no documentation of an emergency-stop primitive, safety-interlock pattern, safety-rated I/O, or any dedicated safety/E-stop API or guide anywhere in the pack.

   ⚑ flag

3. ops leadMy robots keep operating and buffer data locally when cloud connectivity drops, then recover cleanly

   weight 2 · round to Viam
   Formant—none0/10

   The evidence describes the Formant agent, telemetry ingestion, and data rate-limiting, but nothing states that robots continue operating autonomously or buffer data locally during a cloud connectivity outage and then resync on reconnection. This is a reasonable expectation for an edge agent supporting fleet operations, but no documentation or GitHub evidence confirms offline buffering/recovery behavior.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “Each data stream can be rate-limited, so you don't need to ingest data at high resolution if you don't need it.”

   proof ↗⚑ flag

   Viam✓fullcommunity8/10

   Docs explicitly state data queues locally during outages/low-bandwidth and syncs when connectivity returns, with automatic handling of restarts and storage constraints (viam-docs-7), and independent community testimony confirms robots keep operating offline (cached configs, works even through full reboot without internet, TLS cert grace period of 30+ days) (viam-comm-1). This directly matches the ops story of continued operation plus buffered local data and clean recovery. missing for 10: no first-party documentation detailing exact buffer size/retention limits or a hands-on failure/recovery test log beyond the anecdotal HN report.

   • [claimed-docs] “Data queues locally during network outages and in low-bandwidth environments, and syncs when connectivity returns. Viam handles restarts and…”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ flag

Sdk agentic

1. ai-native userHave an AI agent authenticate with scoped credentials and command a real robot end-to-end through the platform's API or SDK

   weight 3 · round to Viam
   Formant~partialprobed5/10

   Formant provides an Agent SDK and Cloud SDK/API that let external programs authenticate, ingest telemetry, and send commands to control real robots (formant-docs-2, formant-docs-4, formant-docs-9, formant-gh-1), which supports end-to-end robot commanding via SDK. However, there is no evidence of scoped/limited-permission credentials or AI-agent-specific auth mechanisms, and the OpenAPI spec probe returned 404s, suggesting the API surface isn't fully documented for programmatic discovery. Missing for 10: explicit scoped-credential/auth-token documentation, AI-agent-specific integration examples, and a public OpenAPI/machine-readable API spec.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”
   • [claimed-docs] “Commands tell our robot to take a predefined action. For example, we can use commands to trigger data ingestion, run a script, or tell our r…”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.formant.io/openapi.json, https://docs.formant.io/swagger.json, https://docs.formant.io/…”

   proof ↗⚑ flag

   Viam✓fullclaimed8/10

   Viam has a dedicated doc page explicitly framing this exact story—'An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can'—and details how an agent lists resources/status, drives motion via the motion service, and calls any API method via CLI or SDK with JSON in/out. Fleet/auth docs show permission and authorization management at org/location/machine granularity, supporting scoped credentials, and the platform provides multi-language SDKs (Python, Go, C++, TypeScript, Flutter) plus a CLI for end-to-end control. Missing for 10: a concrete walkthrough of creating/scoping an API key specifically for an agent, and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out.”
   • [claimed-docs] “With it you can create and manage organizations, locations, and individual machines, manage permissions and authorization, create and manage…”
   • [claimed-docs] “create and manage organizations, locations, and individual machines; manage permissions and authorization; create and manage fragments”
   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”

   proof ↗⚑ flag

2. ai-native userExpress a robot task in natural language and have the platform plan and execute it

   weight 2 · round to Viam
   Formant~partialclaimed4/10

   Formant advertises a natural-language interface where users can 'ask your fleet what's happening in plain language and get governed, ML-driven task recommendations,' but execution explicitly requires human approval ('with people approving what happens next'), not autonomous platform planning/execution as the story describes. This is a marketing-page mention with no technical documentation of the underlying NL-to-plan pipeline or execution semantics. Missing for 10: technical docs on the NL planning engine, evidence of autonomous execution without human gating, and independent/hands-on verification of the feature.

   • [claimed-docs] “Ask your fleet what's happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”
   • [claimed-docs] “Ask your fleet what’s happening in plain language and get governed, ML-driven task recommendations — with people approving what happens next…”

   proof ↗⚑ flag

   Viam~partialclaimed6/10

   Viam explicitly documents that an AI agent with a shell or SDK can operate a machine via the same APIs as a human, including querying resource status and invoking the motion service to plan collision-free paths from a declared goal, obstacles, and constraints (viam-docs-12, viam-docs-31, viam-docs-32). This supports an agent translating intent into planned, executed motion, but there's no evidence of a natural-language interface or LLM-driven task planner built into the platform itself — the agent (e.g., an LLM) must already exist externally and call Viam's APIs/CLI to do the NL-to-plan translation. missing for 10: no first-party natural-language front-end or built-in LLM planner that maps free-text task descriptions to motion/API calls, no end-to-end demo/case study of NL command to execution, no independent corroboration of this agent workflow succeeding in practice.

   • [claimed-docs] “An AI agent with a shell or an SDK can operate a Viam machine the same way a person or a program can.”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Plan motion through the motion service rather than commanding joints or poses directly. `Move` takes a goal pose in any frame, plus obstacle…”
   • [claimed-docs] “Viam's motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [claimed-docs] “The CLI can call any API method a machine serves, with JSON in and JSON out; no code to write.”

   proof ↗⚑ flag

3. ai-native userIntegrate vision-language-action or robotics foundation models into my robot's autonomy stack through supported tooling

   weight 2 · round to Viam
   Formant—none0/10

   Formant's docs describe an Agent SDK/Cloud SDK for telemetry ingestion, commands, and teleoperation, plus AI-assisted dashboards/orchestration, but there is no evidence of tooling specifically for integrating vision-language-action or robotics foundation models into a robot's autonomy stack.

   ⚑ flag

   Viam~partialclaimed4/10

   Viam documents generic ML model training/deployment ('bring your own model', push trained models to cloud for local inference) and a motion-planning service that could host custom control logic, which together could support integrating a VLA or robotics foundation model — but no evidence specifically mentions VLA, foundation models, or dedicated tooling/integrations for such models. Missing for 10: explicit VLA/foundation-model support, documented integration examples, prebuilt model-hub connectors, or partner/third-party corroboration of foundation-model deployment on Viam.

   • [claimed-docs] “Create and annotate datasets, and train ML models in your chosen architecture, all through the cloud. Or bring your own model.”
   • [claimed-docs] “Push trained models to the cloud. Machines pull them automatically and run inference locally. Version, stage, and roll back models just like…”
   • [claimed-docs] “Viam's motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [claimed-docs] “Viam’s motion service plans a collision-free path and executes it, using a frame system you describe and obstacles you declare.”
   • [claimed-docs] “Built-in motion and vision”

   proof ↗⚑ flag

Sdks

1. developerBuild against official, typed SDKs in multiple languages (Python, TypeScript, Go, C++) that cover the platform's full surface

   weight 3 · round to Viam
   Formant~partialclaimed4/10

   Formant offers a Python Cloud SDK, an Agent SDK, and a JS/TS-based RealtimeSDK/toolkit for building custom apps, but there is no evidence of official Go or C++ SDKs, nor any claim that these are strongly typed or cover the platform's 'full surface' (fleet orchestration, analytics, teleop APIs are referenced mostly via REST/Admin API, not dedicated SDKs). missing for 10: Go SDK, C++ SDK, explicit typing guarantees, and full API-surface coverage beyond telemetry/commands/data export.

   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “The primary programmatic way data scientists query for telemetry data is via the Cloud SDK, a lightweight Python module which can interact w…”
   • [claimed-docs] “The primary way of ingesting arbitrary data that is not via the Formant agent is with the Cloud SDK, a lightweight Python module which can i…”
   • [github] “Create your own application that uses Formant's APIs and RealtimeSDK for data”
   • [claimed-docs] “In addition to these commands, you can create custom commands via the Formant Admin API.”

   proof ↗⚑ flag

   Viam✓fullprobed7/10

   Viam's docs explicitly state that developers can write control logic in Python, Go, C++, and TypeScript (plus Flutter), and GitHub confirms multiple official SDKs exist for the RDK, directly matching the story's language list. However, there's no independent verification of full API-surface parity across all SDKs or detailed typed-API documentation per language beyond marketing copy. Missing for 10: independent hands-on corroboration of SDK completeness/parity, and detailed reference docs showing full API coverage per language.

   • [claimed-docs] “Write your control logic in Python or Go, get lower-level control with C++, or build a client application with Typescript or Flutter.”
   • [github] “Multiple SDKs are available for writing client applications that interface with the Viam RDK.”
   • [claimed-docs] “Every camera component in Viam exposes the same GetImage() method regardless of brand... you can swap hardware without rewriting your code.”
   • [probe] “official CLI documented at https://docs.viam.com/cli/reference/”

   proof ↗⚑ flag

Teleop

1. ops leadRoute autonomy failures to a human intervention queue where an operator resolves and hands back control

   weight 1 · round to Formant
   Formant~partialclaimed5/10

   Formant supports alerting on anomalies, dispatching help when 'something looks wrong,' and time-synced 'intervention records,' plus teleoperation for operators to take direct control, suggesting an intervention workflow exists. However there is no explicit documentation of a dedicated human-intervention queue, assignment/resolution workflow, or an automated hand-back-to-autonomy mechanism after operator resolution. Missing for 10: explicit intervention-queue UI/workflow docs, operator resolution/hand-back-to-autonomy mechanics, and independent confirmation of this specific failure-routing flow.

   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”
   • [claimed-docs] “Time-synced video, sensor, and intervention records for your team, and, where you choose, scoped research partnerships.”
   • [claimed-docs] “Assigns the right job to the right robot — regardless of who built it — using operational history and live data, and dispatches help the mom…”
   • [claimed-docs] “Build better human-to-robot ratios by automating incident response and creating workflows for monitoring devices at scale.”
   • [claimed-docs] “Formant's teleoperation provides a secure peer-to-peer connection that enables operators to control any aspect of a system.”
   • [claimed-docs] “Heterogeneous Fleet Orchestration assigns the right job to the right robot — regardless of who built it — using operational history and live…”

   proof ↗⚑ flag

   Viam—none0/10

   Viam documents fleet monitoring, alerting, remote control/teleoperation via web interface, and OTA updates, but nothing describes an automated routing of autonomy failures to a human intervention queue with resolve-and-handback workflow. Missing for 10: any documented intervention-queue mechanism, failure-triggered escalation to a human operator, or handback-to-autonomy control flow.

   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting”

   proof ↗⚑ flag

2. robotics engineerInspect live topics, logs, and state on a deployed robot remotely to debug issues

   weight 2 · round to Formant
   Formant✓fullclaimed8/10

   Formant provides remote observability via the Agent SDK ingesting telemetry, an Observe view for live data, Analytics for historical/aggregated queries with custom SQL, and ROS/Docker agent installation for deployed robots, all matching remote debugging of topics/logs/state. missing for 10: no explicit mention of raw log tailing or independent third-party hands-on validation of the debugging workflow.

   • [claimed-docs] “This guide will teach you how to install the Formant agent to your device via Docker.”
   • [claimed-docs] “The Agent SDK client contains a suite of methods which allow you to ingest telemetry data, receive and respond to commands, teleoperate your…”
   • [claimed-docs] “Get instant visibility into every robot in your fleet. Set up alerts for anomalies, track mission progress, and respond to issues before the…”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”
   • [claimed-docs] “Each data stream can be rate-limited, so you don't need to ingest data at high resolution if you don't need it.”

   proof ↗⚑ flag

   Viam✓fullclaimed7/10

   Viam docs show real-time remote visibility into machine state, sensor data, and camera feeds from the browser (viam-docs-5, viam-docs-6), machine status/resource health via GetMachineStatus (viam-docs-31), and cloud-managed fleet monitoring/alerting (viam-docs-10, viam-docs-26). NAT traversal (viam-docs-4) supports remote access to deployed robots without networking hassle. missing for 10: explicit documentation of a dedicated 'logs' viewer/log streaming feature (only alerting/monitoring and state inspection are directly evidenced, not log tailing specifically), and independent hands-on confirmation of the debugging workflow in production.

   • [claimed-docs] “Write code in your local IDE and execute it against hardware in the field. Stream camera feeds, read sensor data, and visualize machine stat…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Fleet Management: Remote monitoring, access control, and OTA updates”
   • [claimed-docs] “Cloud-managed fleet monitoring and alerting; OTA updates for software and ML models; Canary testing and rollbacks for safe versioning”
   • [claimed-docs] “List the resources (`ResourceNames`) and their state (`GetMachineStatus`). A resource that is still configuring or unhealthy will fail every…”
   • [claimed-docs] “Built-in NAT traversal means you connect to any machine through firewalls and routers. No port forwarding, no networking configuration, no "…”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere. You'll create a machine in the …”

   proof ↗⚑ flag

3. ops leadTeleoperate a remote robot with live video and responsive control over real-world networks

   weight 3 · round to Formant
   Formant✓fullclaimed8/10

   Formant explicitly documents low-latency, peer-to-peer teleoperation with joystick/button control, configurable teleop interfaces, and secure remote control over real-world networks, plus live video/sensor visualization via Analytics and Observe views. Missing for 10: independent/hands-on network-performance validation and detail on video streaming latency/quality under adverse network conditions beyond vendor claims.

   • [claimed-docs] “Reliable, low-latency teleoperation over a peer-to-peer connection keeps your operations moving — via joystick, buttons, or custom controls.”
   • [claimed-docs] “Control robot devices from anywhere over a low-latency, peer-to-peer connection, via joystick and buttons.”
   • [claimed-docs] “Formant's teleoperation provides a secure peer-to-peer connection that enables operators to control any aspect of a system.”
   • [claimed-docs] “Configure teleop interfaces to meet the needs of your specific use case.”
   • [claimed-docs] “We can send commands with the click of a button from the Observe view, or during teleoperation.”
   • [claimed-docs] “Formant Analytics allows you to visualize, aggregate, and analyze data from your device over a time range of your choice. Using built-in vis…”

   proof ↗⚑ flag

   Viam~partialcommunity7/10

   Viam documents live camera streaming, keyboard/teleop controls from a web interface, and NAT traversal for connecting to machines behind firewalls without VPN/port-forwarding, which directly supports remote teleoperation with live video (viam-docs-4, viam-docs-6, viam-docs-42, viam-docs-44). However, there is no evidence quantifying latency/responsiveness over real-world (e.g., cellular, high-latency) networks, and community commentary focuses on offline resilience rather than teleop performance. Missing for 10: independent benchmarks or hands-on reports of control responsiveness/latency over real networks, and explicit teleoperation-specific case studies beyond generic 'drive with keyboard' docs.

   • [claimed-docs] “Built-in NAT traversal means you connect to any machine through firewalls and routers. No port forwarding, no networking configuration, no "…”
   • [claimed-docs] “Drive bases with keyboard controls, move arms to specific positions, or test components directly from Viam's web interface. Debug without de…”
   • [claimed-docs] “Write code in your local IDE and execute it against hardware in the field. Stream camera feeds, read sensor data, and visualize machine stat…”
   • [claimed-docs] “Viam treats your hardware like cloud infrastructure—connect from anywhere, no VPN required.”
   • [claimed-docs] “Connect your first machine to the Viam platform so you can configure, control, and monitor it from anywhere.”
   • [community] “Internet access is optional/intermittent for Viam robots: if connectivity is lost, the robot operates fine until the TLS cert expires (30+ d…”

   proof ↗⚑ flag