Skip to content

Engineering Runtime documentation

From first install to
governed execution.

The operational reference for installing, configuring, authenticating, and running Engineering Runtime. Follow commands you can copy, expected output you can compare, and recovery steps for when policy correctly refuses the work.

Start with AI Install Runtime Browse the CLI reference
  • InstallmacOS · Linux · Windows
  • Configurepolicy · auth · providers
  • Executecommands · capabilities
  • Operateaudit · recovery · upgrades
$ runtime files write ./notes.txt hello
Command:         files write
Transport:       file
Runtime Context: context_free
Identity:        none (no_auth, subject resolved)
Status:          success
Message:         wrote 5 bytes to notes.txt
$ runtime command run kubectl get pods
compiled safety profile (compiled-safety-profile/v3) denied: unbound-context-target: command kubectl needs a resolved target and none is bound. Name it on the command, or point your native tool at the right place — Runtime reads where you are pointed and will not guess
$ runtime audit tail --lines 2
[2026-09-04T14:47:26+10:00] success consumer=human context=context_free transport=file command=files write 12ms wrote 5 bytes to notes.txt
[2026-09-04T14:47:34+10:00] denied consumer=human context=kubernetes (selector_bound) transport=- command=command.kubectl 39ms compiled safety profile (compiled-safety-profile/v3) denied: unbound-context-target: command kubectl needs a resolved target and none is bound. Name it on the command, or point your native tool at the right place — Runtime reads where you are pointed and will not guess

Why was kubectl denied? It is an allowed binary, but this example has no bound Kubernetes target. The compiled safety profile stops it before execution; the allow-list does not bypass context, safety, or authentication checks. A real call also needs Kubernetes authentication enabled and valid.

What these docs contain

Use this site to move from a clean machine to repeatable engineering work. Each path tells you what to run, what to set, what to expect back, and how to recover.

01Install and set upInstall Runtime and prepare a working capability source. 02Configure governanceUnderstand configuration, policy, environment variables, and where work runs. 03Authenticate platformsUse existing GitHub and platform CLI credentials through Runtime. 04Create and run capabilitiesAuthor, validate, plan, execute, and share reusable engineering work. 05Use providers and toolsRun curated GitHub and File operations or approved native binaries. 06Find every commandRead the complete Runtime command and argument reference. 07Troubleshoot and recoverDiagnose configuration, authentication, policy, and capability failures. 08Upgrade with confidenceReview release impact, migration guidance, and post-upgrade checks.
Use the right source of truth

Learn here. Execute against the contract your Runtime carries.

Point your assistant at this site and supervise. The prompts name a URL and a goal, never a vendor.

01 · This site Find the workflow

Use these pages for goals, prerequisites, expected results, recovery, and upgrade guidance.

02 · Installed Runtime Confirm exact behaviour

Use RUNTIME-AGENT.md, manifest.json, specs, and command sheets for your installed version.

External tools remain authoritative for execution context; provider platforms remain authoritative for credentials.

Explore the product vision

Three ways to use it

  • Local (human)

    Install the binary, then run provider operations and capabilities from your terminal. The Runtime Home is created on the first command.

  • CI/CD

    Per-job Home, setup-runtime action, secrets, and capability execute in GitHub Actions (or any pipeline).

  • AI agent

    Runtime Agent contract — your assistant may only call runtime. Tools with hook systems enforce it mechanically; others follow it as prose.

Full map: Ways to use.

The execution lifecycle

Every operation — a provider call, a raw binary, a single step inside a capability — passes through the same six stages, in this order:

Bootstrap → Context → Policy → Authentication → Execution → Audit
Stage What happens Where it is configured
Bootstrap Prepares the Runtime Home from assets embedded in the binary RUNTIME_HOME
Context Observes where the operation runs — from the tool that runs it, or from explicit arguments. Runtime owns no context document Where operations run
Policy Allows or denies the operation before anything executes policy-config.yaml
Authentication Validates an existing platform credential config.yaml
Execution A Runtime Engine performs the work —
Audit Success, failure and denial are recorded <home>/logs/audit.log

Policy runs before authentication on purpose: a denied operation never spends a credential round trip against the platform.

Pick the right execution surface

Both routes use the same Runtime lifecycle. Choose based on whether the operation already has a curated Runtime interface.

Curated operation Use a Runtime Provider

Choose this when Runtime exposes a named operation. State the outcome; the provider selects its supported transport.

Available now: GitHub · files Browse provider operations Existing engineering tool Use the Command Engine

Choose this when your team already uses an approved native binary. Runtime applies its allow-list and subcommand policy.

The tool must already be installed on your PATH Open command run

Build repeatable work with capabilities

Reusable workflows

A capability is a Markdown file with an embedded runtime block. It sequences operations into work that a human, a pipeline, or an AI can run through the same contract.

Create a capability Understand capabilities