The durable object
A capability contract says what must remain true even when the code, model, process and machine underneath it change.
{
"capability_id": "repository.context.read/v1",
"owner": "machine://...",
"input_schema": "...",
"output_schema": "...",
"authority": {
"scope": ["declared-root"],
"expires_at": "...",
"revocable": true
},
"idempotency": "operation_id",
"postconditions": ["artifact-hash", "bounded-disclosure"],
"evidence": ["trace", "source-version", "result-hash"],
"recovery": ["rebind", "stale-generation-reject"]
}
Selection beneath the contract
When an invocation arrives, the system should not default to generation. It asks in order: is there an existing implementation, a better donor, a safe composition, a model-mediated lane, or a genuine need for new synthesis?
Which implementation currently deserves to occupy this capability slot—and what evidence would justify replacing it?
Failure is part of the type
Timeout, denied authority, stale generation, disconnected peer, partial effect, unknown outcome and failed postcondition must be represented explicitly. They are not strings buried in logs.
A capability that cannot distinguish “command sent” from “effect observed” is not reliable enough to become an organ in an epistemic physiology.