A Presolve capability contract has a stable semantic identity, a version, baseline operations, mandatory guarantees, and optional feature vocabulary. Providers advertise the exact version and features they really support; applications declare what they require or prefer.
Required is a constraint. Preferred is a ranking signal.
[[capabilities]]
interface = "presolve:objects/store"
version = "^0.1"
required_features = ["range-read"]
preferred_features = ["user-metadata"]The environment advertises concrete supply such as presolve:objects/store@0.1.0.
If a provider lacks range-read, it is not compatible for this application.
user-metadata may make one otherwise-compatible provider preferable without making the environment invalid.
The deployment plan exposes the selected provider ID, version, and requested features actually satisfied.
The current capability surface.
| Capability | Baseline operations | Current providers | Evidence |
|---|---|---|---|
presolve:kv/store@0.1.0 | get · set · delete | memory · Redis · Cloudflare Workers KV | same-release proof |
presolve:objects/store@0.1.0 | get · put · head · list · delete | memory · S3-compatible | same-release proof |
presolve:sql/database@0.1.0 | execute · query · begin · commit · rollback | SQLite · PostgreSQL | same-release proof |
presolve:queue/work-queue@0.1.0 | send · receive · ack · retry | in-memory leased queue | capability proof |
presolve:kv/store@0.1.0
The smallest built-in contract establishes exact-key state semantics without prescribing whether the implementation is an in-process map, Redis, or a managed cloud KV service.
Mandatory guarantees
There are currently no optional KV features in the 0.1 contract. The flagship proof exercises memory, Redis, and Cloudflare resolution with the same application release.
presolve:objects/store@0.1.0
Object storage introduces opaque byte bodies, metadata, prefix listing, streaming reads, and provider limits that are materially different from KV.
Mandatory guarantees
Optional features
presolve:sql/database@0.1.0
Presolve standardizes parameter binding, a portable scalar/result model, and transaction ownership. It deliberately does not claim that arbitrary SQL source is dialect-portable.
Baseline guarantees
Optional features
[[capabilities]]
interface = "presolve:sql/database"
version = "^0.1"
required_features = ["dialect-postgresql"]
preferred_features = ["returning"]The SQLite/PostgreSQL proof uses a deliberately shared SQL subset and the same bound $1, $2, … parameter form. Presolve does not rewrite SQL.
presolve:queue/work-queue@0.1.0
The baseline models pull-style work distribution: send opaque bytes, receive a finite leased delivery, explicitly acknowledge success, or request retry. Duplicate delivery is legal baseline behavior.
Mandatory guarantees
Optional features
WIT is one binding target, not the semantic contract.
Capability semantics remain independent of ABI, protocol, deployment platform, or implementation language. A future non-Wasm workload can still request the same semantic capability.
Canonical contract definitions on GitHub ↗Boolean features will not be enough forever.
Real providers have exposed semantic dimensions that are values rather than yes/no features: key-size limits, SQL limits, queue message-size limits, retention ranges, lease-duration ranges, and similar constraints. Presolve has not added a typed semantic-property system yet; provider evidence will determine what that model needs.
See the proof evidenceHow real providers have already changed and sharpened the abstractions.