Numinance documentation
Documentation for the open Numinance protocol and the governed autonomous-engineering model around it, with the shipped surface separated from the designed one.
Give it context.
Let it engineer.
Numinance is a governed engineering runtime. A customer-defined policy, not the model, decides how far each piece of work may go. The intelligence is private. The contract is open, and this site documents it.
What do you want to accomplish?
Start from the outcome. Every path below ends on something you can run from the public numinance-spec repository today, except the last, which describes a design.
Typed services, capability ports, governance annotations and configuration kinds as protobuf and JSON Schema.
Run numi init, read every file it writes, and validate it with the open build.
Build the sample knowledge provider, see why it refuses to run by hand, and read how a host launches it.
Check an evidence/v1 export offline under keys you pin yourself.
Data plane, control plane, trust kernel, plugin host and the separation of duties.
How a customer-controlled runtime is designed to be deployed. Not installable today.
Three objects, not one
The word "Numinance" names three different things. Most confusion about what you can install comes from mixing them up.
| Object | What it is | License and availability |
|---|---|---|
The numi CLI | A command line you can build from source. Open build: version, init, validate, validate --files, evidence verify. | Open source (Apache-2.0), in the public repository. |
The numinance-spec repository | The contract: protobuf services, ports, governance annotations, kinds and schemas, SDKs, sample and official plugins, conformance kits, the evidence/v1 specification and verifier. | Open source (Apache-2.0). Pre-alpha. |
| The Numinance runtime (the engine) | The proprietary system that runs the understand, plan, act, verify, evidence loop under your policy. | Private. Not generally available. Not installable. |
Installing numi does not install an autonomous engineer. It installs the tool that scaffolds and validates the configuration the engine reads, and the verifier that checks what the engine exports. Read Open versus proprietary for the full boundary.
The brain is private. The contract is open.
Current availability
| Capability | State | Public surface | How to try | Next milestone |
|---|---|---|---|---|
| numi version Open CLI | Available in public spec | Open build of numi | go run ./cli/numi version | Tagged releases |
| numi init Open CLI | Available in public spec | Scaffolds .numinance/ for a Python repository | go run ./cli/numi init --ci github-actions <repo> | More languages and SCM providers |
| numi validate --files Open CLI | Available in public spec | Strict schema + loader check of kind documents | go run ./cli/numi validate --files schemas/examples | None: profile resolution lives in the engine build |
| numi validate (repository) Open CLI | Available in public spec | Schema pass, then exit 7: profile resolution needs the engine build | go run ./cli/numi validate <repo> | Full resolution ships only in the private engine build |
| numi run / connect / plan / approve / doctor Open CLI | Under development | Designed command surface of the unified CLI | Not in the open build | Engine build; interface subject to change |
| numi evidence export Open CLI | Under development | Engine-side export of an evidence bundle | Unknown subcommand in the open build (exit 2) | Engine build |
This is the open command line. The full matrix, with SDKs, evidence, integrations, runtime and distribution, is on Status. The short version:
- You can run today: build
numifrom source, scaffold.numinance/for a Python repository, schema-validate configuration, and verify anevidence/v1export offline. - Pre-alpha: protobuf contracts, the Go SDK, generated Python and TypeScript stubs, the official providers.
- Under development, not installable: the autonomous engine and managed or sovereign deployment.
- Planned: GitHub Releases binaries and Homebrew. No install command exists for either.
- Coming soon: Rust SDK, Java SDK, air-gapped deployment. No dates, package names or versions are promised.
What the design promises
These statements describe the architecture the contract encodes. Each links to the page that explains the mechanism and what it does and does not guarantee.
- Give it context. Let it engineer. The runtime resolves repository, ticket and knowledge context before it plans. See Context first.
- Your policy decides. Not the model. Policy is evaluated outside the model before every privileged action, and grants are capability-based. See Governed execution.
- Your infrastructure. Not our playground. The data plane is designed to run in the customer environment. See Deployment modes.
- Don't trust the agent. Check the evidence. Append-only evidence is written by the runner identity and checked offline under keys the verifier pins. See Evidence and trust.
Full autonomy here means configurable, governed, qualified and human-accepted, bounded by floors, policy, grants and a customer-local circuit breaker. It is never unrestricted, and an agent cannot widen its own grants or promote its own autonomy. See Autonomy levels.
Status legend
Every capability page carries one of six statuses. They are rendered from one table, so the wording never drifts.
| Status | What it promises | What it does not |
|---|---|---|
| Available in public spec | Source, schema, CLI function or verifier exists in the public tree. | Stability. It can still be pre-alpha. |
| Pre-alpha | Code exists; APIs and packaging may change before a tagged release. | A published package or a support commitment. |
| Under development | Part of the designed architecture. | That it is distributed, runnable or scheduled. |
| Planned distribution | An install channel is intended. | A published artifact. No install command is given. |
| Coming soon | It is on the roadmap. | A date, package name, version or command. |
| Illustrative | An example or simulation. | That it came from a real run. |