OM1 Robotics AI Runtime

This is a robot runtime that drives real hardware (Unitree Go2/G1, LimX, etc.) and calls cloud LLM/ASR/TTS services. The docs show a game controller takes precedence over AI physical actions (unitree_go2_quadruped_configurations.md), which is the only visible human-override mechanism; there is no confirmation, approval, or least-privilege design for LLM-generated actions. The MCP example executes `npx -y` over stdio and carries a GitHub PAT, a broad permission surface. On data flow, docs admit data goes to at least three cloud LLMs but do not disclose which sensor data goes where. Sensitive-data handling is only a one-line 'Face Detection and Anonymization' claim with no implementation evidence. Dependency security is limited to pinned versions in go.mod with no audit/vulnerability-scanning evidence. Rollback is entirely absent (no action undo, no safe-stop). Source attribution has MIT and a copyright line, but publisher identity is unverified. Deductions: least_privilege 1 for arbitrary MCP command execution and unsandboxed hardware actions; user_confirmation 1 for controller-only override; data_flow_transparency 1 for only generic multi-LLM mention; sensitive_data_handling 1 for a single anonymization claim; dependency_security 1 for pinning without audit; external_effects 1 for high-impact physical actions with thin safeguards; rollback 0 for no evidence; source_attribution 2 for clear LICENSE and copyright.

Config docs are consistent on single/multi-mode, version checking (v1.1.0, major/minor mismatch behavior), and connector resolution (name+connector), and they corroborate go.mod and the CI build flow, so self-consistency is 2. Dependency availability is 2: go.mod pins versions, CI caches zenoh-c and bundles libzenohc, and prebuilt binaries plus INSTALL.txt are provided. Failure messages are 1: there is a troubleshooting doc and version-mismatch logging, but the troubleshooting table is very generic ('check settings', 'restart') and the simulator troubleshooting doc still references Python 3.10/uv, inconsistent with the Go runtime.

Audience and scenarios cover developers, robot hardware integration, simulators (Gazebo/Isaac Sim), and cloud simulation, scoring 2. Capability boundaries are explicit: OM1 assumes a high-level hardware SDK, requires you to build your own HAL, the Python runtime is deprecated, and some Go capabilities are still in development, scoring 2. Trigger precision is 1: mode switching relies on keyword matching (trigger_keywords) with cooldowns, a coarse mechanism with no evidence of false-trigger safeguards. Environment fit is 2: recommended platforms are listed, 'should run' elsewhere is noted, and macOS/Linux install differences are documented.

Information architecture is 2: docs/SUMMARY.md, GitBook config, and a topic-organized tree. Install notes are 3: system deps, prebuilt binaries, source build, API key, Grafana, and troubleshooting are all detailed. Naming stability is 1: there is a Python-to-Go migration, a deprecated Python branch, and config version v1.1.0 coupled to runtime version, so naming and structure are still evolving. Examples and FAQ are 2: config examples, a developer cookbook, and simulator guides exist, but there is no consolidated FAQ. Known limitations are 1: only scattered mentions (Python deprecated, some capabilities in development, platforms 'should' work) with no systematic limitations list. License is 3: full MIT text. Versioning/changelog is 1: config version checking and CI-generated release notes exist, but there is no in-repo CHANGELOG. Maintenance responsibility is 1: CONTRIBUTING is referenced and CI exists, but publisher identity is unverified and there is no explicit maintainer/SLA statement.

Output usability is 2: runnable configs, prebuilt binaries, verification steps, and a monitoring stack make ordinary use feasible. Marginal value is 2: as a modular robot HAL/runtime integrating multiple LLMs, middleware, and simulators it adds genuine value. Cost-benefit is 1: it requires an OpenMind API key with OMCU billing, depends on cloud LLMs, and has a high hardware/simulation barrier with a limited free tier.

Claim traceability is 1: README makes many capability claims (full autonomy, SLAM, auto charging, face anonymization) that point to external docs and the BrainPack repo, with no corresponding implementation evidence in this repository. Cross-source corroboration is 1: README, config docs, go.mod, and CI corroborate each other on build and configuration, but the core autonomy claims cannot be cross-verified from the given files. Fact/inference separation is 1: docs generally distinguish 'supported/in development/should run', but some capability statements are absolute and unqualified.