Compatibility: Pactmark 0.1.x. Version 0.1.1 is public on npm with per-package provenance and independently verified registry bytes. Public release and registry ownership are verified; none of the production or security claims below follow from that.
Every green test on this project applies to its exact fixture and environment. This page collects, in one place, what a green test does not mean.

​
Framework-level limits

No global exactly-once effects

Pactmark uses at-least-once execution with controlled effects. Uncertainty is a recorded state, not a solved problem.

No complete security claim

The design reduces specific risks with specific controls. It does not establish that a system built on it is secure.

No sandbox isolation

The reference container fixture is explicitly unsafe for production arbitrary-code isolation.

No certification or compliance

Nothing here maps to a regulatory conclusion. Evidence is one input to your control framework.

No production availability

There is no SLA, no hosted service, and no uptime claim.

No provider correctness

Model, database and platform providers are outside the boundary. Their behaviour is your risk.

No artifact truth

Verification checks named properties of exact bytes. It does not make the content correct.

No protection from over-broad grants

An allowed model action can still be undesirable inside a host grant that was too generous.

​
Platform-level status

Figure 1. Read the third column, not the second. “Locally build-compatible” is a statement about a build, not about an operator’s deployed topology.

​
The specific ones people miss

store-memory is deterministic and tenant-scoped, and it is ephemeral. Readiness honestly reports not-ready for a durable production profile. Nothing you do to it will change that.
The nextjs-vercel fixture builds routes and exercises streamed events, accessibility and security contracts. No live Pactmark Vercel deployment has been verified. A long function timeout is not a durability guarantee, and background work inferred from an open response is not a background worker.
The staging Worker returned health 200, completed one deterministic SSE fixture, and honestly returned readiness 503 because its memory-backed runtime is neither durable nor production-isolated. That result is anonymous, ephemeral and explicitly non-production.
Without a production SandboxAdapter, untrusted stdio MCP servers and arbitrary code remain unsupported. Discovery never grants authority in any case.

​
Surface-level limits in 0.1.x

The public authoring facade is narrower than the runtime surface. Two runnable examples in the repository exist specifically to demonstrate the boundary honestly rather than simulate success:
Examples that fail closed are more useful than examples that mock success. If you are evaluating Pactmark, run those two first — they tell you where the edges are faster than any prose.

​
What is established

To be fair in both directions, the following are backed by executable evidence in the repository:
  • Deterministic runs over memory and PostgreSQL 17 profiles, including migrations, concurrency, TLS, crash and resume tests.
  • Default-deny policy, grant binding, cross-tenant negative tests and command replay behaviour.
  • Credential-boundary and redaction canaries across events, telemetry, evidence and HTTP surfaces.
  • Content addressing, verifier binding and evidence reference validation.
  • Supply chain: pinned lockfile, lifecycle scripts denied by default, one canonical packer requiring two byte-identical tarballs, independent NodeNext/Bundler/Yarn/Bun/loopback-registry consumers, and independent verification of all 19 registry-served tarballs for v0.1.1.

​
How to use this page

1

Before adopting

Check that nothing you need is on the “does not prove” list. If it is, that is a gap you own.
2

Before writing marketing copy

Evidence language is bounded on purpose. Threat model row TM-18 names misrepresentation of evidence as a high risk with a named owner.
3

Before a production gate

Pair this page with the readiness checklist and the responsibility matrix.

Threat model

Eighteen high and critical rows, each with controls, evidence, an owner and a residual-risk statement.