Specified
Interfaces, permission model, evidence requirements, failure modes and the conformance checks a release must pass.
Knowledge & context · Prototype
Capabilities with boundaries attached.
Each capability in GraphNative IO is specified as a contract: scope, permission, evidence and failure behaviour.
01
The five contracts
Numbered for reference; the order is not a priority.
- 01. Graph persistence and versioning
-
Implemented through one permission model that applies to the human interface and the machine interface alike.
Operators can inspect the capability before it runs and review its record afterwards.
Surfaces REST · MCP · CLI
- 02. Structured context APIs
-
Implemented through one permission model that applies to the human interface and the machine interface alike.
Scope is attached to the capability, not to the caller, so delegation does not widen it silently.
Surfaces REST · MCP · CLI
- 03. Provenance and access control
-
Implemented through one permission model that applies to the human interface and the machine interface alike.
Scope is attached to the capability, not to the caller, so delegation does not widen it silently.
Surfaces REST · MCP · CLI
- 04. Data ingestion and graph updates
-
Defined as a scoped contract: the product states what it may touch, what it may change and what it must record.
Operators can inspect the capability before it runs and review its record afterwards.
Surfaces REST · MCP · CLI
- 05. Machine-readable MCP and SDK surfaces
-
Implemented through one permission model that applies to the human interface and the machine interface alike.
Scope is attached to the capability, not to the caller, so delegation does not widen it silently.
Surfaces REST · MCP · CLI
02
What is specified, and what is not
A capability in a specification is not a shipped feature.
Not claimed
Running deployments, measured performance, third-party certifications or integration approvals.