Proof-Carrying Workflows: knowing what was checked, and what needs checking again.

A finished task still leaves questions.

This started with work on our plugin family. After an audit, translation review or release check, we needed to know which version had been checked, what the agent was allowed to change and where the results were recorded. A confident summary could leave those questions unanswered.

We wanted a record that another person or an automated check could verify, including whether later changes had made an earlier result out of date.

Keep the agreement, the change and the evidence together.

Each task starts with an agreed scope and a record of the code before the work. The submitted result identifies what changed and supplies evidence for the checks performed. A small verification core compares those records. It can reject changes outside the agreed scope or evidence that belongs to a different version.

Results also declare which files or shared components they depend on. If a verified change touches one of those dependencies, the result becomes stale and needs checking again. PCW applies this approach to audits, documentation, localisation and releases.

pcw profile validate --profile <file>
pcw run start    --profile <file> --workflow <id> --target <git-worktree> --authority <file> --store <outside-target-path>
pcw run begin    --store <path> --run <id> --implementer <declared-id>
pcw run submit   --store <path> --run <id> --implementer <same-id> --result <artifact-file>
pcw run validate --store <path> --run <id> --validator <different-id> --decision valid|invalid --report <artifact-file>
pcw run verify   --store <path> --run <id>

Run records sit outside the project being checked. The command-line tool also requires different declared identifiers for the implementer and validator. The team adopting the system remains responsible for verifying who those people or agents are.

Evidence supports a decision. Someone still owns it.

PCW verifies submitted work. It can refuse to certify a result, but it does not intercept every file edit or tool action. A team that needs to prevent unauthorised operations must provide those controls separately.

Passing a technical check does not approve a release or close an audit. Those decisions stay with the people and workflow responsible for them. Developers, agents and CI can use the same records without being given that authority.

The mechanism works in a pilot. Adoption comes next.

In a technical pilot, the real Redirect Manager checks ran in containers managed by PCW. The system retained the successful result. A later change to the shared base plugin, made in a disposable copy, correctly marked the dependent result as stale.

PCW includes Git state capture, evidence collection, stored run verification, a Craft plugin profile and an initial agent integration. The plugin family is the planned first adopter; its everyday workflows have not switched to PCW yet.

We are testing PCW locally and preparing it for public release. The next step is to complete the plugin migration and verify those workflows before the standalone release. Licensing, distribution and broader agent support are still being worked through.

One approach that can travel between projects.

The verification core is independent of an AI vendor or a particular repository. Project profiles describe the files, checks and workflow rules for each adopter. Craft plugins are the first profile; other project types are planned.

The design keeps the recorded facts, technical verification and approval decisions separate. That makes it easier for a reviewer to understand what a result establishes and what still needs their judgement.