Tinverse Linux Guix

A declarative Linux system for robotics products.

Tinverse Linux Guix defines the operating system as code: board policy, kernel, drivers, packages, services, security settings, and application payloads remain explicit inputs to the image. Controlled channels identify the package graph used for each build.

Controlled customization

Fit Linux to the product, then retain exactly what changed.

Tinverse can tailor the board support, vendor runtime, standard or real-time kernel, packages, services, networking, security policy, and application integration for the robot. The automated request interface exposes a bounded set of supported profiles; broader changes are controlled engineering inputs. Tinverse validates every accepted combination before a build. The exact customization request is saved, hashed, and named in the signed release bundle alongside the image it produced.

Hardware and kernel

Choose a supported board, vendor payload, device support, and standard or real-time kernel policy.

Product runtime

Include only the applications, libraries, users, services, and network behavior the product needs.

Release policy

Separate development access from production policy and select the required software-inventory and vulnerability evidence.

System composition

Describe the whole operating environment.

Hardware

Select the board and kernel policy.

Board profiles, device tree, firmware, drivers, power configuration, and standard or real-time kernel choices stay visible.

System

Compose packages and services declaratively.

Users, services, networking, security policy, libraries, and applications are part of the system definition rather than post-installation steps.

Inputs

Identify every source used by the build.

Tinverse channels, customer inputs, and licensed vendor payloads remain separate and traceable through image construction.

Build entry point

The image builder selects the standard or real-time variant explicitly. The resulting release record identifies the board, system definition, package graph, and vendor inputs used by the image.

tools/env/build_guix_jetson_image.sh \
  --variant rt \
  --image-type efi-raw

Controlled channels

Channel definitions pin the package sources and system modules used to compose the image.

Standard and real-time variants

Kernel and runtime policy are selected as image variants and verified on the target hardware for each release.

Release evidence

Image hashes, manifests, signatures, software inventories, vulnerability dispositions, and verification results identify the delivered system.

FDA submission support

Evidence for the Linux platform in your device.

For a production release, Tinverse supplies the platform records an integrating medical-device team needs to identify, assess, and verify the Linux software used in its product. Release assembly rejects incomplete software evidence, skipped vulnerability review, missing target results, or an absent known-anomalies review. The evidence is tied to the exact released image rather than a generic distro description.

Identity

Show exactly what was delivered.

Retained customization request, source revision, Guix channels, system definition, vendor versions, image hash, and signed release manifest.

Software

Account for the platform contents.

Complete runtime closure, package and license inventories, CycloneDX and SPDX SBOMs, and manifests for licensed vendor inputs.

Assurance

Support risk and verification review.

CVE review, reviewed vulnerability disposition, OpenVEX, lifecycle and traceability records, known platform anomalies, build records, and release-specific target verification results.

These records support the Linux platform portion of a submission. The finished-device manufacturer remains responsible for device classification, hazards, system validation, clinical claims, and the final FDA submission.

Target programs

Built for selected Jetson robotics platforms.

Current system definitions and image tooling cover Jetson AGX Orin and Jetson AGX Thor program paths. Every customer image still requires board-specific build, boot, driver, and timing verification.

Contact engineering@tinverse.com.