OpenWorkProof Update: What We’ve Shipped—and What You Can Verify Today

OpenWorkProof Core 1.4.0 and a community DeepSeek Harness plugin have been released, enabling verification of agent work orders and evidence outside the originating system. The update includes a packaged Harness integration with two operating modes, audit and enforce, and emphasizes that verification does not equal acceptance. Developers can run provided examples to inspect human agency profiles and verify evidence bundles.

My last update here was on August 25. Since then, OpenWorkProof Core 1.4.0 and our first DeepSeek Harness plugin have shipped. I owe readers a concrete account of what is available and how to check it. If you are new to the project, OpenWorkProof connects an agent's work order, delegated authority, execution evidence, verification, and final acceptance. The aim is to let someone outside the originating system inspect the evidence behind a delivery. For this update, I'll start with the packages, then give you two small checks you can run yourself. As of September 9, 2026: | Component | Published version | Where to inspect it | |---|---|---| | OpenWorkProof Core | 1.4.0 , released August 30 | PyPI https://pypi.org/project/openworkproof/1.4.0/ · GitHub release https://github.com/dengyier/OpenWorkProof/releases/tag/v1.4.0 | | Community DeepSeek Harness plugin | 0.1.0 | npm https://www.npmjs.com/package/@openworkproof/dsh-plugin/v/0.1.0 · Source https://github.com/dengyier/openworkproof-dsh-plugin | The main addition since the 1.3.0 update is a packaged Harness integration. Human Agency profiles and offline evidence verification were already part of the project; the examples below show how to inspect those capabilities with the released Core package. A documentation correction: some Core documentation still describes the plugin as unpublished. The npm release is now available at the link above. Consider a coding task where an agent may read a repository, apply a bounded patch, and run agreed tests. The patch, test result, and final delivery need to refer to the same authorized work. The plugin brings that workflow into DeepSeek Harness with two operating modes: owp apply patch and owp run tests , with authorization checks before execution. The installed plugin starts disabled. After explicit configuration, Audit is the default operating mode; Enforce requires an explicit choice. The tested host version is DeepSeek Harness 0.1.1-rc.2 . The integration also provides commands to inspect evidence, request verification of the correlated patch receipt, and export a package for offline review. The designated Acceptor signs acceptance separately, with their private key outside Harness. The important distinction remains: VERIFIED ≠ ACCEPTED A technical verification result does not give the agent authority to accept its own delivery. This is a community integration with a specific trust boundary: it depends on the Harness host, plugin, and bridge. It is not an operating-system sandbox. A compromised host or execution outside the observed pipeline needs separate controls and evidence. See the integration documentation https://github.com/dengyier/openworkproof-dsh-plugin readme for setup and limitations. Use Python 3.12 and Git for these examples. The commands below are for a POSIX shell. Pin both the source examples and installed package to the release: git clone --depth 1 --branch v1.4.0 \ https://github.com/dengyier/OpenWorkProof.git cd OpenWorkProof python3.12 -m venv .venv source .venv/bin/activate python -m pip install "openworkproof==1.4.0" python examples/human agency profile v01.py Relevant output: profile verified : True resolved status : active owp.repo read : delegated - allowed owp.apply patch : reserved - AGENCY HUMAN DECISION REQUIRED The example creates temporary keys in memory, signs a work order and a human agency profile, verifies the profile, and distinguishes a delegated read from a patch decision reserved for a human. It is a small protocol demonstration. It uses a fixed demonstration time and a local classification helper; it does not dispatch a real patch or establish that every route through a runtime is protected. That stronger claim needs integration testing. From the same checkout and environment: python tests/evidence-bundles/verify evidence bundle.py \ tests/evidence-bundles/rich-4196-integrity-v05-delivery-package.json This uses a project-owned reproduction based on Rich 4196. It is an existing Verification Integrity v0.5 fixture, included here so readers can check it with Core 1.4.0. The fixture version and package version identify different things. After installation and download, this verification does not require the original live ledger or a model API. It checks the supplied package under the fixture's verification rules. It does not rerun Rich's test suite or establish that the upstream project adopted OpenWorkProof. Now change one byte in an embedded file, leaving its declared digest unchanged. This writes a separate copy: python python - <<'PY' import base64 import json from pathlib import Path source = Path "tests/evidence-bundles/" "rich-4196-integrity-v05-delivery-package.json" bundle = json.loads source.read text item = bundle "files" 0 payload = bytearray base64.b64decode item "payload b64" payload 0 ^= 1 item "payload b64" = base64.b64encode payload .decode "ascii" Path "tampered-bundle.json" .write text json.dumps bundle PY python tests/evidence-bundles/verify evidence bundle.py \ tampered-bundle.json The original should pass. The damaged copy should fail with v0.5 envelope file hash mismatch and exit code 1 . For this article, we reran both examples on September 9 in a fresh Python 3.12 environment with Core 1.4.0 and the release-tagged example files. The profile demonstration passed. The original bundle returned VERIFIED and READY FOR ACCEPTANCE , with exit code 0 ; the damaged copy failed with the error and exit code above. That is a deliberately narrow negative check: it demonstrates rejection of an altered payload with a stale digest. It does not establish resistance to every forgery or prove that the original business judgment was correct. Further checks need to challenge signatures, authority, causal bindings, and the verifier's assumptions. The next useful step is reproduction by people who did not build the integration. The released packages are available; production adoption and external acceptance need their own evidence. If you build an agent runtime, an MCP tool server, or a permission-checking component, I'd like to test one bounded execution path together: There may be useful integration points between an execution-time guard and OpenWorkProof's work contracts and evidence. I'd rather establish those through a working example than assume compatibility from our descriptions. For a joint test, I'd like us to publish the method and reproducible results, credit each contributor and project, and link the relevant code. Both successful defenses and failures are worth documenting. Vulnerability details should be coordinated privately before publication. Start with OpenWorkProof https://github.com/dengyier/OpenWorkProof or the Harness plugin https://github.com/dengyier/openworkproof-dsh-plugin . If an example fails, an issue with the version, command, and sanitized output would help. For exploitable vulnerabilities, use private security reporting https://github.com/dengyier/OpenWorkProof/security/advisories/new . Which tool execution path would you bring to a test like this?