THE OPEN BOUNDARY
The intelligence is private. The contract is open.
numinance-spec is the Apache-2.0 integration and verification layer around Numinance. This page is the overview. Details live in the protocol docs.
Pre-alpha · Specification published separately
Private Engine
Proprietary- Autonomous engineering intelligence
- Orchestration runtime
- Understand, plan, act, verify, evidence loop
Not part of numinance-spec. Internals are not published.
Open Protocol
Apache-2.0 · numinance-spec- Inspect the contracts
- Generate clients and build compatible adapters
- Validate configuration and verify evidence
No dependency on the proprietary engine’s internals.
Protobuf
Typed ports and governance annotations
SDKs
Go, Python and TypeScript
Schemas
JSON Schemas for configuration kinds
Conformance
Suites for independent implementers
Adapters
Integration adapters
Verifier
Offline evidence verification
CLI
The numi command line
RFCs
Public design record
Protocol packages
contract source: numinance-spec/proto/
numinance.annotations.v1
Governance annotations
- RiskClass
- ExecMode
numinance.types.v1
Shared types
- PrincipalKind
- ResidencyClass
- TrustClass
- AutonomyLevel
- ChangeState
- Digest
- Reference
numinance.plugin.v1
Plugin boundary
- PluginService
- HostService
- Envelope
- ActionContext
- ActionResult
- Diagnostic
- Manifest and capability descriptions
numinance.kinds.v1
Configuration envelope
- apiVersion
- kind
- metadata
- spec
- extensions
Members are listed by name. Enum values, fields and message shapes are defined in the proto sources.
SDKs
Intended location
numinance-spec/sdk/go/
Generated contract bindings and plugin entry points for Go. The Go tree also hosts the offline evidence verifier.
SDK details are published with the specification.
01 · Why a boundary
Two things, kept apart
The engine is the part that reasons about code and decides what to do. It is proprietary and stays private. Everything it needs in order to be governed, extended and checked is expressed as a contract that is open.
The line is deliberate. You should not need the engine’s source to know what it is allowed to do, what it hands to a plugin, or what it recorded.
02 · What you can do
Work against the contract
- Read the protobuf definitions and generate clients.
- Build adapters and plugins against typed, governed interfaces.
- Validate configuration against published schemas.
- Run conformance suites against your own implementation.
- Verify evidence offline.
03 · Stability
Governance, versioning and RFCs
Contracts are versioned in their package names. Changes to them go through a public RFC process, and the project documents how it is governed.
See governance, versioning and the RFCs.
04 · Honest status
What this page does not claim
Numinance is pre-alpha. The listings above name contract packages and categories of material. They are not a promise that any adapter or SDK is ready. Providers and SDKs are described from the public tree (numinance-spec); the repository is public on GitHub.
Start with the SDK guide or the protocol reference.