Compatibility: Pactmark 0.1.x. Version 0.1.1 is public on npm. All 19 registry-served tarballs were independently matched to the frozen candidate manifest.

​
Dependencies

The lockfile is authority

The pinned pnpm lockfile is the exact resolved dependency record. Package manifests declare supported ranges; the lockfile decides what is actually installed.

Lifecycle scripts denied by default

Reviewed exceptions are versioned and explicit. A lifecycle canary asserts the deny is real.

Offline advisory and licence gates

Run locally, without a network dependency in the critical path.

Dependency boundaries enforced

The kernel cannot import a provider SDK, database client or platform runtime — checked in CI.
Runtime dependencies are deliberately few, replaceable, permissively licensed and isolated to the package that needs them:

​
Building a candidate

1

One canonical packer

It stages allowlisted files, materialises exact internal versions and disables lifecycle scripts. There is exactly one way to produce a candidate.
2

Two byte-identical tarballs

The pack runs twice and the archives must match byte for byte. Non-determinism is a build failure, not a curiosity.
3

Independent consumers eat the packed bytes

NodeNext, Bundler, Yarn, Bun and a loopback-registry fixture install the tarballs rather than workspace links.
4

Release dry run produces the evidence set

Checksums, a CycloneDX SBOM, manifests and attestation inputs — without signing or publishing.
Workspace links alone cannot prove package metadata, exports, type declarations or initializer developer experience. “It works in the monorepo” and “it works when installed” are different claims, and only the second one matters to a user.

​
Publication

The protected release.yml candidate job is:
  • manual, and main-only;
  • bound to the reviewer-gated release environment;
  • re-runs deterministic and live freshness gates;
  • freezes exact tarball, SBOM and manifest checksum subjects;
  • uploads a candidate only after GitHub build-provenance and SBOM attestations succeed.
Its npm write is source-bound, reviewer-gated, token-free trusted publishing. There is no long-lived release token to steal.
The workflow cannot deploy, cannot create a tag, and cannot create a GitHub Release. Publication authority is narrow on purpose — see threat model rows TM-15 and TM-16.

​
Release history, stated precisely

​
Uncertain writes during a release

A registry timeout is the same class of problem as an uncertain external effect, and it is handled the same way:
1

Inspect anonymous exact-version state first

Before any further operation.
2

If absent, a maintainer may authorise a new attempt

Explicitly, not automatically.
3

If present, bytes and public visibility must match the frozen manifest exactly

A mismatch stops publication and triggers incident review.
The guarded publisher never performs an automatic retry or dist-tag repair, and externally exposed failed version bytes are never reused.

​
Verifying what you installed

Compare against the published manifest and attestations. If installation returns not found, verify your registry configuration and network access — do not switch to an unverified lookalike package. The @pactmark scope and create-pactmark are the only published names.

​
What this does not establish

Verified registry bytes and per-package provenance establish that the code you installed is the code that was built. They do not establish that the code is secure, that a deployment built on it is secure, or any of the production claims listed on what Pactmark does not prove.

Threat model

Rows TM-15 and TM-16, with owners and residual risk.

Security model

The runtime controls that sit behind the release path.