Build once
application.presolved- application requirements
- workload artifact identity
- canonical release digest
- no selected provider/environment
One release.
Different environments.
Presolve builds the application before deployment selection. The public proofs then evaluate and execute those exact release bytes through materially different providers and fail if the application identity changes.
The invariant
Deployment selection must not mutate the application.
Every same-release proof records both the canonical Presolve release digest and the raw .presolved archive SHA-256 before environment selection, then verifies both after planning and execution.
P
Presolvesame release bytesDecide later
presolve.env.toml- execution support
- provider supply
- semantic features
- stable provider IDs
Coverage
The proof suite is no longer just KV.
Each slice isolates a different kind of deployment decision and provider-semantic pressure.
Memory, Redis, and Cloudflare Workers KV planning; memory and Redis execution by default; optional live Cloudflare execution.
Memory and S3-compatible storage through put/head/list/streamed-get/delete semantics.
One SQL Component plus one conformance suite executed through SQLite and PostgreSQL.
Leased delivery, retry, redelivery, ack, stale receipt invalidation, and immutable release execution through the runtime path.
Immutable workload identity and execution/materialization paths are tested separately from provider selection.
Presolve reports structured problems when workload, resource, version, or semantic requirements cannot be satisfied.
Run it
Four public commands.
bash ./demo/portability/run.shKV flagship · memory · Redis · Cloudflare planbash ./scripts/check-object-portability.shObjects · memory ↔ S3-compatiblebash ./scripts/check-sql-portability.shSQL · SQLite ↔ PostgreSQL + shared conformancebash ./scripts/check-queue-portability.shQueue · current leased-delivery capability proofThe default KV proof requires no cloud credentials. Live Cloudflare execution is opt-in via
--cloudflare. The queue command currently proves one provider/runtime path; cross-provider queue substitution is the next queue milestone.Flagship KV result
Three plans, two default executions, unchanged identity.
portability-localmemory-kv · in-process · resolved + executedportability-redisredis-kv · RESP/TCP · resolved + executedportability-cloudflarecloudflare-kv · managed service · resolved; optional live executionrelease digest: sha256:fa8cb59cf09dd5ed507d865fd4b739f6229e1422367bfe1f9afdfba6adc57c5e
archive sha256: 45e6f9dca20dce54337f34f403e772e510a1f6b6a333a44112d82c09af014344
release digest unchanged: yes
archive sha256 unchanged: yes
PASS — one .presolved release, three plans,
two provider realizations, zero application rebuilds.Why breadth matters
Real providers expose different abstraction failures.
| Provider family | Difference exposed | What Presolve learned |
|---|---|---|
| Redis / Cloudflare KV | in-process vs TCP vs managed HTTP/eventual operational behavior | capability semantics must stay independent from transport/realization |
| S3-compatible objects | idempotent delete, key-size limits, signed streaming constraints | provider limits and stronger mutation semantics cannot be hidden |
| SQLite / PostgreSQL | dynamic vs strict typing, SQL dialects, zero-row metadata | portable result/transaction semantics are separate from SQL syntax portability |
| Leased work queue | receipts, leases, retries, duplicate delivery | at-least-once settlement semantics must be explicit; triggering is separate topology |
What is proven
Specific claims, not universal portability.
Application release identity is independent from environment selection. Detached releases can reconstruct their requirements. Different provider IDs can satisfy the same semantic requirement. Concrete runtime settings stay outside application identity.
The proofs do not claim every application runs everywhere, all provider semantics are identical, or Presolve is a scheduler/control plane.
Reproduce it, then challenge the boundary.
The most useful feedback is where a real deployment requirement cannot be represented honestly: missing semantic properties, invalid provider equivalence, workload constraints, or runtime details that leak into application identity.