The useful question is not whether an adapter can be written. It is whether one provider-neutral semantic contract survives materially different implementations while the exact application release remains unchanged.
What has actually been exercised.
| Capability | Providers / environments | Evidence type | Identity |
|---|---|---|---|
kv/store | memory · Redis · Cloudflare KV | 3 plans; memory + Redis execution; optional live Cloudflare execution | unchanged |
objects/store | memory · S3-compatible HTTP service | 2 plans; 2 executions | unchanged |
sql/database | SQLite · PostgreSQL | shared conformance suite; 2 plans; 2 executions | unchanged |
queue/work-queue | in-memory leased queue | conformance + detached-release runtime proof | unchanged |
The same invariant is tested repeatedly.
No environment participates in application packaging.
Canonical Presolve release digest + SHA-256 of the exact encoded archive bytes.
The same archive reconstructs its requirements and is compared with one or more environment definitions.
Operational settings and credentials enter only here.
No provider-specific rebuild replaces the detached release.
Both the logical release digest and raw archive SHA must be unchanged.
Memory → Redis → Cloudflare.
memory-kvin-process provider · resolved + executedexecutedredis-kvRESP/TCP external process · resolved + executedexecutedcloudflare-kvWorkers KV · always planned; live execution with credentialsoptional livebash ./demo/portability/run.sh
release digest: sha256:fa8cb59cf09dd5ed507d865fd4b739f6229e1422367bfe1f9afdfba6adc57c5e
archive sha256: 45e6f9dca20dce54337f34f403e772e510a1f6b6a333a44112d82c09af014344
portability-local memory-kv value:demo-…-local
portability-redis redis-kv value:demo-…-redis
portability-cloudflare cloudflare-kv plan-only by default
release digest unchanged: yes
archive sha256 unchanged: yesThis is the flagship proof because it spans in-process, networked, and managed-cloud provider shapes while preserving the same application requirement.
Exact KV proof source on GitHub ↗Memory → S3-compatible.
bash ./scripts/check-object-portability.sh
release digest: sha256:3d67508d77df06a9e9228d9128a579e64b0cc2bdce244f73e2aa148d76819670
archive sha256: e97f42ffed06356c0f2716d0bfc0233afc81ee7ae3af96a849ed6864404f912f
objects-local memory-objects objects:objects-2441-local
objects-s3 s3-objects objects:objects-2441-s3
PASS — one .presolved object release, two plans,
two provider realizations, zero application rebuilds.What this provider taught us
- S3 delete-existence must be synthesized with
HEAD → DELETEand is not atomic against external mutation. - S3-compatible keys have a 1,024-byte provider limit the current capability IR cannot negotiate numerically.
- The first signed PUT implementation buffers before mutation; multipart/large-object semantics should not be implied by the baseline.
SQLite → PostgreSQL.
SQL adds an extra gate: both providers must pass the same semantic conformance suite before the application portability proof runs.
sqlite-sqltype/transaction conformance + detached release executionpasspostgres-sqllive container conformance + same detached release executionpassbash ./scripts/check-sql-portability.sh
release digest: sha256:28067c62c3fcb5ab5129d39dc9fc6a9c1c87ad0d48aa9845c762cf7c08cd85fb
archive sha256: bf290904b11662ecfff2866fa446eff5eb9b0d33d41c709108368a4bad1bba95
SQL provider conformance passed: sqlite
SQL provider conformance passed: postgres
sql-sqlite sqlite-sql sql:sql-2392
sql-postgres postgres-sql sql:sql-2392
PASS — one .presolved SQL release, two conforming engines,
two plans, zero application rebuilds.A failure improved the model
The first PostgreSQL conformance attempt exposed a fixture bias hidden by SQLite's dynamic typing: text and bytes had been tested through one column. The fixture was corrected to separate typed text/byte columns. PostgreSQL also forced zero-row column metadata to come from prepared-statement metadata rather than the first returned row.
Leased delivery through the full runtime path.
The queue proof currently establishes the capability/runtime boundary with one concrete provider. It does not yet claim provider substitution.
bash ./scripts/check-queue-portability.sh
release digest: sha256:7f848c878310c14995b7963e8e2f27ddd5173e1379de13e6627e5b532a235511
archive sha256: 4a20e2f0e353ea53371c3bd19bb1ddbf105bb665deae31e788a02db7d767dd9c
environment: queue-memory
provider: memory-queue
output: queue:queue-2142
release digest unchanged: yes
archive sha256 unchanged: yesThe reusable harness verifies active-lease hiding, abandoned-delivery redelivery, explicit retry, stale delivery-generation rejection, and opaque byte preservation without accidentally requiring FIFO or exactly-once semantics.
Two independent checks prevent a moving target.
canonical manifest → release digest.presolved bytes → archive SHA-256A proof fails if either identity changes after planning or execution. This prevents a provider-specific rebuild, regenerated manifest, or silently mutated archive from being presented as portability.
The useful question is where the model breaks.
- Does an environment-specific assumption leak into the application release?
- Are the capability semantics strong enough to make substitution meaningful?
- Does the deployment plan expose enough of the decision to audit it?
- Can another provider satisfy the contract without changing application code or release identity?
- Which provider limits require typed semantic properties rather than boolean feature names?
- Which real workload would force Presolve to acknowledge a missing abstraction?