Part III — The Substrate
Not Rest Inc. · Constitution · v1.1 · Part 3 of 4
Part III
THE SUBSTRATE
Sections 38–57: the infrastructure that makes the principles executable.
§38
THE INFRASTRUCTURE OF THE OPERATING SYSTEM FOR ACTION
The vision only becomes real if NOTREST builds the substrate that allows capabilities to become legible, composable, governable, and verifiable.
The infrastructure goal is not to create thousands of agents first.
It is to build the system in which any qualified capability — AI, human, company, API, machine, institution, or capital source — can enter the graph, accept responsibility, receive bounded authority, act, prove what happened, and improve the system through memory.
The infrastructure should be built around one principle:
Build the substrate before building the ecosystem.
The first technical objective is not:
How many agents can NOTREST run?
It is:
Can NOTREST reliably turn an intention into a composed, authorized, verified sequence of real actions?
§39
THE ACTION KERNEL
At the center of NOTREST should be a small, durable kernel.
The kernel is the minimum infrastructure required to turn intention into action.
Its first-class kernel objects should include:
Identity Capability Agent Mission Task Resource Permission Contract Action Claim Evidence Verification Event Reputation Organization Capital
Everything more complex should be built by composing these primitives.
The kernel should remain small enough to understand and stable enough that industries, products, agents, and organizations can evolve around it without repeatedly rewriting the foundation.
§40
IDENTITY
Every persistent participant needs identity.
This includes:
- AI agents;
- humans;
- teams;
- companies;
- APIs;
- robots;
- laboratories;
- manufacturers;
- institutions;
- capital pools;
- hybrid organizations.
An identity should know:
ID Owner / governing entity Version Capabilities Permissions Jurisdiction Credentials Certifications History Reputation Economic account Parent Children Dependencies
Identity is the basis of:
- attribution;
- reputation;
- authorization;
- contracts;
- payment;
- audit;
- accountability.
NOTREST should never allow important actions to become detached from accountable identity.
§41
THE CAPABILITY REGISTRY
The most important database in NOTREST should not be a directory of agents.
It should be a graph of:
What can the world do?
A capability should be machine-readable.
Example:
capability: id: regulatory.device.classification provider: agent_1842 inputs: - product_description - intended_use - jurisdiction outputs: - classification - regulatory_path - evidence_requirements cost: estimate: 120_USD latency: estimate_minutes: 8 authority_required: external_submission: human_approval verification: - independent_regulatory_check
Capabilities should be:
- discoverable;
- composable;
- versioned;
- priced where appropriate;
- constrained;
- permission-aware;
- reputation-bearing;
- verifiable.
The capability graph is more fundamental than the agent graph.
Agents are providers.
Capabilities are the economic primitive.
§42
MISSION SPECIFICATION
NOTREST needs a structured representation of intent.
The system cannot depend only on conversational prompts.
A mission should make explicit:
- desired outcome;
- constraints;
- budget;
- timeline;
- success criteria;
- non-goals;
- jurisdiction;
- risk tolerance;
- evidence requirements;
- human authority requirements.
Example:
mission:
objective:
detect_kidney_disease_earlier_at_home
constraints:
jurisdiction: US
budget: 2000000_USD
deadline: 18_months
success:
- functioning_prototype
- clinical_evidence
- viable_regulatory_pathway
non_goals:
- hospital_only_device
risk_tolerance:
medium
The mission specification is the source code of the Action Compiler.
§43
THE DECOMPOSITION ENGINE
Given a mission, NOTREST should determine:
What has to be true? What work must happen? What capabilities are required? What dependencies exist? What can happen in parallel? What requires humans? What requires capital? What requires external authorization? What evidence proves completion?
The result is not simply a task list.
It is a dependency graph.
Example:
MISSION │ ├── Clinical Feasibility ├── Sensor Feasibility │ └── Prototype ├── Regulatory Classification ├── IP Review ├── Manufacturing Feasibility └── Commercial Validation
Every node may recursively decompose.
This is where fractality becomes executable infrastructure.
§44
THE COMPOSITION AND ROUTING ENGINE
Once the required capabilities are known, NOTREST must decide who or what should provide them.
The routing engine should eventually consider:
capability fit quality price availability latency jurisdiction reputation risk certification historical performance human review dependency compatibility mission constraints
The system should not optimize for the cheapest provider by default.
It should optimize for the mission objective.
This makes NOTREST analogous to a scheduler.
Kubernetes schedules compute.
NOTREST should schedule economic capability.
§45
THE AGENT RUNTIME
NOTREST needs a common runtime contract.
Every agent should be able to:
receive task inspect authority inspect mission context request resources call other capabilities execute produce claims attach evidence declare uncertainty report result fail escalate delegate
The runtime should not depend on one model provider.
Behind the same agent interface may be:
- a frontier model;
- a smaller local model;
- deterministic code;
- an API;
- a workflow;
- a human;
- a company;
- a robot;
- a hybrid system.
The infrastructure should care about:
capability, authority, evidence, and outcome
not the implementation underneath.
§46
THE AUTHORITY SYSTEM
Authority must be infrastructure, not an afterthought.
Every consequential action should answer:
WHO can do WHAT to WHICH RESOURCE under WHICH CONDITIONS for HOW MUCH until WHEN with WHICH APPROVALS
Example:
agent: id: procurement_agent permissions: read_supplier_data: true spending: autonomous_limit: 2500_USD approval_required: above: 2500_USD forbidden: - sign_long_term_contract - share_customer_PII
Authority should support:
- capability-scoped permissions;
- resource-scoped permissions;
- budget limits;
- temporal limits;
- jurisdiction limits;
- approval chains;
- revocation;
- escalation;
- delegation;
- emergency stop.
NOTREST should build bounded authority before broad autonomy.
§47
THE VERIFICATION ENGINE
Verification may become one of NOTREST's deepest differentiators.
Most agent systems optimize for producing plausible outputs.
NOTREST should optimize for verified state change.
The basic structure is:
CLAIM + EVIDENCE + VERIFICATION
Example:
claim: supplier_contract_signed: true evidence: - signed_contract.pdf - counterparty_confirmation verification: status: verified verifier: contract_verifier_02
The verifier may be:
- another agent;
- a human;
- a cryptographic check;
- a third-party system;
- an API response;
- a physical sensor;
- a signed document;
- multiple independent sources.
Agents should earn reputation for verified outcomes, not fluent language.
§48
THE EVENT LEDGER
NOTREST needs durable memory of what happened.
Every meaningful change should produce an event.
Examples:
Mission created Capability requested Provider selected Authority granted Task accepted Budget reserved Action started Result produced Evidence attached Verification passed Verification failed Human approval granted Contract signed Mission changed Agent replaced Mission terminated
The event system should be append-oriented and auditable.
From it, NOTREST should be able to reconstruct:
Why did this happen?
The event ledger becomes the raw material for:
- audit;
- debugging;
- causality;
- learning;
- reputation;
- governance;
- financial accounting;
- mission replay;
- re-composition.
§49
THE ECONOMIC LAYER
The economic layer should be designed early but activated progressively.
Eventually NOTREST needs native support for:
budget pricing quotes commitments contracts payments escrow cost allocation revenue capital ownership resource allocation
A provider should be able to make an offer:
offer: capability: PCB_design price: 4300_USD delivery: 7_days confidence: 0.97
The mission can:
- accept;
- reject;
- negotiate;
- seek alternatives;
- require human approval;
- split the work.
This is the transition from agent orchestration to economic coordination.
§50
THE FOUR PLANES
NOTREST infrastructure should separate four conceptual planes.
INTELLIGENCE PLANE models reasoning planning prediction CONTROL PLANE identity permissions policy orchestration routing governance ECONOMIC PLANE budget pricing contracts payments capital REALITY PLANE humans APIs companies machines documents sensors physical world evidence verification
Most AI companies compete primarily in the Intelligence Plane.
NOTREST's durable advantage should increasingly come from the other three.
Models may commoditize.
The following are much harder to commoditize:
- trusted identity;
- capability history;
- permission structure;
- economic coordination;
- verified outcomes;
- event memory;
- reputation;
- cross-industry composition.
§51
THE NOTREST ACTION OBJECT
If the entire infrastructure had to reduce to one technical object, it should look something like:
action: intent: requested_by: required_capability: assigned_to: inputs: authority: resources: budget: expected_output: success_condition: falsifier: evidence_required: result: verification: learned:
Missions are graphs of actions.
Agents are providers of capabilities.
Organizations are graphs of agents, humans, machines, companies, resources, and contracts.
NOTREST is the system that composes them.
§52
BUILD PHASE I — ACTION KERNEL
The first infrastructure milestone should contain only the kernel objects required for reliable action.
Build:
Identity Capability Registry Mission Task Graph Agent Runtime Permissions Event Ledger Verification
Do not begin with:
- thousands of agents;
- marketplaces;
- tokens;
- autonomous capital markets;
- giant industry ontologies;
- beautiful agent avatars.
The Phase I test is brutal:
Can one mission reliably decompose into multiple capabilities, assign them to agents, execute under bounded authority, verify the result, and preserve the complete history?
If yes, NOTREST has a kernel.
If no, everything else is decoration.
§53
BUILD PHASE II — FRACTAL ORGANIZATION
Once the kernel is reliable, add recursion.
Build:
agent contains agents mission contains missions capability contains capabilities agents delegate agents negotiate dependencies teams dynamically assemble human approvals reputation lineage
The system should support organizations such as:
Manufacturing Agent
↓
Electronics Agent
↓
PCB Agent
↓
Supplier Agent
without hardcoding the organization itself.
The structure should emerge from the required capabilities.
§54
BUILD PHASE III — ECONOMIC NETWORK
Once reliable composition exists, add economic coordination.
Build:
pricing budgets quoting contracts payments capital resource allocation provider competition economic reputation
Now agents are not simply collaborating.
They are forming and executing economic relationships.
This is where NOTREST begins to become a genuine composable economic system.
§55
BUILD PHASE IV — OPEN CAPABILITY PROTOCOL
The system becomes larger than NOTREST only when third parties can enter it.
Allow external parties to register:
their agents their APIs their people their companies their machines their capital their specialist capabilities
through a common protocol.
The protocol should define:
- identity;
- capability declaration;
- task acceptance;
- authority;
- evidence;
- verification;
- economic terms;
- events;
- reputation;
- dispute / failure behavior.
At this stage, NOTREST no longer needs to build every capability itself.
It becomes the substrate through which the economy can become composable.
§56
WHAT NOT TO BUILD FIRST
NOTREST should resist infrastructure theater.
Do not make the first roadmap revolve around:
- thousands of prebuilt agents;
- an agent marketplace;
- blockchain;
- tokens;
- DAO governance;
- complex capital markets;
- autonomous company formation;
- hundreds of integrations;
- giant dashboards;
- avatars;
- generic “AI employee” catalogs.
Those may become useful later.
They are not the foundation.
The foundation is:
Capability Graph + Action Kernel + Authority System + Verification Ledger.
§57
THE FIRST INFRASTRUCTURE PROOF
The first convincing NOTREST demonstration should not be:
“Look how many agents we have.”
It should be:
Give NOTREST a meaningful objective. Watch it determine the required capabilities, assemble a temporary organization, assign authority, execute the work, produce evidence, verify the outcome, learn, and recompose when reality changes.
The proof should show the full loop:
INTENT ↓ DECOMPOSE ↓ DISCOVER ↓ COMPOSE ↓ AUTHORIZE ↓ ACT ↓ VERIFY ↓ LEARN ↓ RECOMPOSE
That is the infrastructure proof of the Operating System for Action.