Problem
Invariants I2 and I4 say a capability must not create durable storage and that all durable state originates from the runtime. Today nothing structurally prevents it — the invariants rely on review.
Expected outcome
A capability never knows where data lives. It receives a small, fixed surface and nothing else:
create_operation()
attach_content()
query_projection()
instantiate_context()
emit_event()
No SQL. No filesystem. No encryption primitives. No sync. No key material.
Why this is the load-bearing piece
This is what turns I2 and I4 from aspirations into properties that hold by construction:
- A Tier 1 capability is declarative data and has no way to reach a filesystem
- A Tier 2 capability's sandbox prohibits file and network access outright (§5.1)
- The API is the only door
It is also the long-term compatibility boundary. Storage can move from SQLite to something else in 2035 without touching a single capability, because no capability ever named a storage engine.
Scope
- Define the five entry points precisely: signatures, error types, and what each guarantees
query_projection must not leak the projection's storage shape — a capability that learns it is querying SQL will eventually depend on SQLattach_content returns a ContentID; the capability never sees key material or a file pathemit_event is in-process and non-durable — it is explicitly not a persistence path, and that must be stated so nobody uses it as one
The test this enables
Can the capability be implemented entirely by emitting operations and consuming projections?
With this API, "no" is answerable mechanically: it needed something the API does not offer. Then exactly one of two things is true — the runtime is missing something generic that should be added once for everyone, or the feature is bypassing the runtime.
Blocked by
#1194 (Operation Log), #1196 (Capability SDK), #1197 (Context Runtime).
Problem
Invariants I2 and I4 say a capability must not create durable storage and that all durable state originates from the runtime. Today nothing structurally prevents it — the invariants rely on review.
Expected outcome
A capability never knows where data lives. It receives a small, fixed surface and nothing else:
No SQL. No filesystem. No encryption primitives. No sync. No key material.
Why this is the load-bearing piece
This is what turns I2 and I4 from aspirations into properties that hold by construction:
It is also the long-term compatibility boundary. Storage can move from SQLite to something else in 2035 without touching a single capability, because no capability ever named a storage engine.
Scope
query_projectionmust not leak the projection's storage shape — a capability that learns it is querying SQL will eventually depend on SQLattach_contentreturns aContentID; the capability never sees key material or a file pathemit_eventis in-process and non-durable — it is explicitly not a persistence path, and that must be stated so nobody uses it as oneThe test this enables
With this API, "no" is answerable mechanically: it needed something the API does not offer. Then exactly one of two things is true — the runtime is missing something generic that should be added once for everyone, or the feature is bypassing the runtime.
Blocked by
#1194 (Operation Log), #1196 (Capability SDK), #1197 (Context Runtime).