Why documentation is the product¶

Engineering Runtime is the trusted execution platform that enables AI assistants to perform enterprise engineering operations through documented, deterministic capabilities.

That sentence carries a commitment: here, documentation is architecture — designed alongside the runtime, not written up afterwards. This page explains why we work that way, and what it asks of us.

The competitive advantage is not the CLI¶

A CLI on its own is not what makes this useful — plenty of good ones already exist, and a binary that wraps gh and kubectl is straightforward to build.

What matters is the combination:

Component	Contributes
Runtime	Deterministic execution — the same operation behaves the same way for a human, a pipeline, or an assistant
Documentation	Structured operational knowledge an assistant can read and act on
AI	Understands the goal, reads the documentation, drives the runtime
Enterprise Control Plane	Governance — policy, audit, fleet

Remove any one and the story collapses. A runtime nobody can drive is a CLI. AI without a governed execution layer is an assistant typing kubectl into production. Documentation without determinism describes something that behaves differently every time.

The GitHub Actions analogy¶

Ten years ago, using CI meant learning a syntax. Engineers studied workflow YAML, triggers, matrices, expressions, secrets, and the marketplace.

Today most engineers ask an assistant for a workflow and get one that runs. Nothing about YAML got easier — a large, public, well-structured body of documentation and examples came into existence, and the assistants learned from it.

That is the outcome we are building toward, deliberately rather than by accident. It is why the documentation is treated as part of the product architecture: if the corpus is not good enough for an assistant to act on, the product is not finished, however good the binary is.

The inversion¶

The primary consumer of operational documentation is no longer a human. It is an AI assistant acting on a human's behalf.

Before:  Engineer → reads docs → copies commands → fixes errors → eventually works

Now:     Engineer → states a goal
                  → assistant reads the documentation
                  → runtime executes, governed and audited

Humans still read the conceptual pages — this site, for why the thing is shaped as it is. But the how-to pages on docs.engineeringruntime.com are written as execution contracts: goal, prerequisites, commands, expected output, failures, next step. That structure exists because an assistant cannot act on prose with commands buried in it.

AI assistants are the interface, not the competitor¶

Any AI assistant        ← the interface: understands intent, reasons
        ↓
Engineering Runtime     ← trusted execution + governance
        ↓
Enterprise systems      ← GitHub today; more as they ship

We are not competing with AI assistants, and we are not betting on one. Any capable assistant can read public documentation and drive a CLI — that is the entire premise, and it is why nothing in our documentation names a single vendor as the way in.

What AI alone cannot give an enterprise¶

The objection every enterprise raises is not "can AI do this?" It is:

"We want our engineers to use AI." → "How do we know what the AI did?"

A general-purpose assistant with shell access cannot answer that. Engineering Runtime can:

Requirement	How
Auditable	Every execution appends a structured record — success, failure and denial
Policy-enforced	Every operation is evaluated before execution; allow/deny is never optional
Deterministic	The same capability produces the same behaviour, whoever invoked it
Centralised authentication	Platform-native credentials, never re-issued or stored by us
Versioned capabilities	Workflows are files — reviewable, diffable, version-controlled

That is the commercial argument, and it is why governance is a component rather than a feature.

The principles this commits us to¶

These are checkable, which is the point of stating them publicly:

Could an AI agent successfully use this feature by reading only the public documentation? If not, the documentation is improved until it can.
Can a first-time user accomplish this by asking an AI assistant, without reading the documentation themselves?
A feature is not complete until its documentation is complete.

The third is the expensive one. It means a provider that ships without a published page is not shipped.

Where this is true today, and where it is direction¶

Being specific matters more than sounding ambitious, so:

Claim	Status
An assistant can install the runtime unauthenticated	True today. The release artifacts are public; one command installs and verifies. The source repository stays private — a public artifact is not open source
Operations execute under policy, with a full audit record	True today
Capabilities are authored in Markdown and validated against the installed binary	True today
Runtime Providers	Two ship: `files` and `github`. Other CLIs — `terraform`, `kubectl`, the cloud tools — are reachable through the Command Engine, which is governed pass-through, not a provider surface
Jira, GCP, AWS, Azure as native providers	Direction, not built
Approval workflows and an AI-governance surface	Direction, not built — see the Control Plane roadmap

Aspiration is legitimate on a page about vision. Present tense is not, and we would rather be believed later than impressive now.