Guides
Task-oriented walkthroughs for configuring Numinance, from onboarding a repository to a governed release, with each guide marked as runnable today or designed.
numi CLI or whether it is a designed walkthrough of the proprietary engine.Guides marked "Runnable today" use only the open numi CLI, the numinance-spec repository and its SDKs. Guides marked "Designed walkthrough" describe the Numinance engine, which is proprietary and not generally available. Installing numi does not install an autonomous engineer.
How to read the executability labels
| Label | Meaning | What you need |
|---|---|---|
| Runnable today | Every command in the guide exists in the open build and was run to produce the output shown. | A clone of the spec repository and the Go toolchain. See Install. |
| Partly runnable | The configuration and checks are real and runnable; the live behaviour they configure belongs to the engine. | Same as above. The guide marks where it stops. |
| Designed walkthrough | A storyboard of the engine, tied to real configuration documents. There is no runnable engine command. | Nothing to run. Read it to learn what you would configure and what you would approve. |
The open build validates documents (numi validate --files), generates a starting configuration (numi init) and verifies evidence offline (numi evidence verify). Running a change, exporting evidence, tripping the breaker and approving a gate are engine features. See Status for the full matrix.
The journey
Run numi init on a Python repository, validate the output, and protect .numinance/policy. Runnable today.
Decide defaults, rules and floors with the ladder; validate the org example. Runnable today (configuration).
Bind the GitHub and CI providers in the profile. Partly runnable: bindings validate, live runs are the engine.
Declare a KnowledgeConnection for read-only context. Partly runnable: the document validates, resolution is the engine.
Implement a provider against the plugin contract and run its conformance kit. Runnable today.
Check an evidence export offline under pinned keys. Runnable today against the conformance vectors.
Where an agent harness plugs in and what it is never given. Designed walkthrough of the engine side.
Qualification thresholds are configurable; promotion is proposed by evidence and accepted by a human. Designed walkthrough.
A low-risk change type from triage to a pull request. Designed walkthrough.
Independent checks, bounded repair and escalation for a bug fix. Designed walkthrough.
Canary, rollback, breaker positions and human-only break-glass. Designed walkthrough.
Suggested order
Get a configuration on disk
Start with Onboard a repository. It is the only guide that produces files you keep: five documents under .numinance/policy/ that name your toolchain, playbook, stage registry and autonomy level.
Decide how far the agent may go
Choose an autonomy level turns the ladder into a policy. The shipped starting point is the pull-request level. Raising it is a policy change that a human reviews, not something an agent can ask for.
Wire in your systems and your own capabilities
Connect source control and CI, Connect knowledge and Build a custom plugin cover the provider side of the contract.
Read the storyboards, then check the evidence
The three change-type guides show what the engine is designed to do with that configuration. Verify a run shows how you check the outcome without trusting the engine that produced it.
One pass through the rules
Every guide inherits the same invariants: policy is evaluated outside the model before every privileged action, the author and reviewer agents cannot approve their own work, only the release pipeline deploys, and evidence is written by the runner. "Your policy decides. Not the model."