Intrinsic Core Concepts

Intrinsic Core concepts and architecture

Overview

Intrinsic Core is an on-premise industrial robotics operating platform. Intrinsic Core executes completely on-premise on an industrial PC (IPC) without external cloud services, telemetry relays, or internet connectivity.

Zero-cloud execution model

When developing or executing code on Intrinsic Core, adhere to the zero-cloud paradigm:

• On-premise execution: Authentication, configuration, and execution are completely self-contained within the local workcell.
• Direct local CLI addressing: Target the local cluster gateway directly via --address=localhost:17080 (or --server=localhost:17080 for inctl process).
• Direct gRPC ingress: All platform services are exposed through a local Istio/Envoy gateway listening on port 17080.
• Paired negative guardrails (sparse safety limits):
  1. Do not run inctl solution list or inctl solution get with --address=localhost:17080 (cloud-only commands); run inctl service state list --address=localhost:17080 and inctl asset instance list --address=localhost:17080 to inspect local solutions instead.
  2. Do not handcraft skill boilerplate without CLI tooling; scaffold skills using inctl skill create <skill_id> --proto_package=<pkg> instead.
  3. Do not omit --instance_name=icon when running inctl icon subcommands over port 17080; always provide --instance_name=icon --address=localhost:17080 to route through the Istio ingress gateway.
  4. Do not run unfiltered find . or grep -rn . in the workspace or from root / (hangs on Bazel symlink trees, device streams, and pseudo-filesystems); always exclude hidden directories, .cache, and bazel-*, and ALWAYS run grep or find commands with a maximum 60-second timeout (e.g. timeout 60s grep ...).
• CLI help syntax: Run inctl help or inctl <subcommand> --help to display Cobra commands. Running inctl --help invokes the Go flag parser and displays only logging flags.

Core platform primitives

Intrinsic Core applications are composed of five core primitives:

1. Assets

An Asset is a versioned, immutable package distributed as a bundle tarball (.bundle.tar) containing container images, descriptors, and manifests. Examples include hardware module definitions, gripper interfaces, CAD scene meshes, and skill libraries. Install bundles locally via:

inctl asset install <bundle_path> --address=localhost:17080

[!NOTE] If inctl asset install fails with failed to dial "/run/containerd/containerd.sock": connect: connection refused or connection refused on localhost:17127, stop after at most 2 attempts. The failure is on the backend server side (the containerd socket and its mount belong inside k3s on the cluster host, NOT in the local client environment, e.g. Bubblewrap sandbox). Do NOT attempt to debug local /run sockets, search for sockets with find /run, or attempt to proxy /run/containerd/containerd.sock. Fall back to local hermetic Bazel verification (bazel build //..., bazel test //...).

2. Services

A Service is a long-running microservice daemon providing capabilities across the cluster over gRPC or HTTP. Services represent hardware interfaces (ur_module, gazebo_simulator), motion planners, and vision pipelines. Services declare lifecycle hooks (SIGTERM handling) and expose health endpoints.

3. Skills

A Skill is a discrete robotic task or capability encapsulated as an action or condition node within a Behavior Tree (BT). Examples include Cartesian linear motion, gripper actuation, or scene graph frame spawning. Skills declare equipment leases (required_equipment) and execute within an ExecuteContext.

4. Solutions

A Solution is the top-level deployable robotic application binding Services, the World model (ObjectWorld), and an Executive Behavior Tree to accomplish a workcell objective. Start or stop local solutions via inctl solution start and inctl solution stop with --address=localhost:17080.

5. ICON

ICON (intrinsic control core) is the real-time execution engine running a high-frequency control loop (1 kHz). It interfaces directly with motor servo drives (via EtherCAT) or hardware modules (via shared memory/IPC) to compute inverse kinematics, enforce dynamic limits, and stream joint trajectory setpoints safely.

Input-aware decision tree for platform inspection

Select diagnostic and inspection commands based on current runtime objective:

Goal: Inspect workcell state
├── Inspect active service states?
│   └── Run: inctl service state list --address=localhost:17080
│       └── Output: Active services (calibration_service, gazebo_simulator, icon, ur_module) and state (Enabled, Faulted)
├── Inspect configured asset instances?
│   └── Run: inctl asset instance list --address=localhost:17080
│       └── Output: Maps instance names to asset IDs (e.g. icon -> ai.intrinsic.generic_realtime_control_service)
├── Inspect installed catalog assets?
│   └── Run: inctl asset list --asset_types=service --address=localhost:17080
│       └── Output: Lists installed service packages, including uninstantiated assets
├── Inspect or control real-time ICON engine?
│   └── Run: inctl icon status --instance_name=icon --address=localhost:17080
│       └── Output: Real-time loop status, active parts, and controller state
└── Inspect or stage behavior tree process?
    └── Run: inctl process get --server=localhost:17080
        └── Output: Currently staged BehaviorTree proto definition (note --server flag)