Compatibility: Pactmark 0.1.x. The mutable readiness record in the repository carries exact digests and timestamps for every row below.

​
Status by target

Figure 1. Status words are chosen precisely. “Build-compatible” means a build succeeded in a named environment. It is not a statement about your deployment.

​
Choosing a profile before choosing a platform

The platform question matters less than the durability question:

Development profile

Memory store, deterministic clock and ids, no background wake-ups. Ephemeral, tenant-scoped and honest about it. Readiness reports not ready for production.

Durable profile

PostgreSQL stores, hostname-verified TLS, least-privilege role, fenced leases, protected context storage, backups, and a separately operated worker process.
A long function timeout, a held HTTP response, or an in-memory continuation are not a durable profile. They are a long request that happens to survive for a while.

​
The decision tree

1

Do runs finish inside one request, always?

If genuinely yes — short, read-only, no external effects — a serverless route with the memory profile can be reasonable for a pilot. Readiness will still say not-ready, and that is accurate.
2

Do runs wait for humans or external systems?

Then you need durable storage and a worker. waiting_for_approval can last days; nothing about a request lifecycle accommodates that.
3

Do runs cause external effects?

Then you need the effect ledger backed by Postgres, plus a reconciliation path and someone on-call to resolve parked effects.
4

Do you need portability across runtimes?

Keep the kernel portable: no Node built-ins, no environment reads, no provider SDKs in shared code. The portable-agent example shows one implementation behind three entrypoints.

​
Targets in this section

Node and container

The most complete target: HTTP bridge, graceful shutdown, and the durable worker beside it.

Vercel

Thin Web-standard route adapter, with local contract evidence and no live deployment claim.

Cloudflare

Experimental portable subset. Staging-verified, memory-backed, explicitly non-production.

​
Capabilities are declared, and unsupported means refused

Every runtime advertises a RuntimeCapabilities record:
An agent can declare requiredRuntimeCapabilities. If the runtime cannot provide one, KAF_RUNTIME_CAPABILITY_MISSING is raised before the run starts rather than halfway through.
This is why “it deployed successfully” and “it will work” are different statements. A Worker that starts happily will still refuse an agent that needs background wake-ups, because it cannot provide them.

​
Health and readiness are different questions

Readiness fails closed. A memory-backed runtime asked for a production profile returns not-ready — including in the Cloudflare staging fixture, which returned 503 for exactly that reason.

Production readiness checklist

Owners and evidence for identity, data, durability, recovery and operations.