PDX ReviewDesk

Humans and agents review a regulated dossier in one tab. WebMCP tools call ProDocuX checks and PDX digest-bound approvals, while source PDFs never change.

Comment

Inspiration

A product specification, an approved formula, and a certificate of analysis can disagree, and they often do. The specification still names formula revision 2 while the master formula is already revision 3. The certificate reports a pH the specification does not allow. A human reviewer can see that if the three PDFs are on one desk. An agent usually cannot: it scrapes a UI, invents a side channel, or silently edits the wrong bytes.

WebMCP is the missing control surface. The page should be the MCP server. The agent should call the same actions the reviewer sees, on the same documents, with the same results. Checks should not live in the frontend. Approvals should bind to digests, not to a screenshot of a button.

That is the inspiration for PDX ReviewDesk: one tab where humans and agents share a regulated dossier, while published ProDocuX and PDX Artifact Engine do the work the page must not invent.

What it does

As a MVP showcase, ReviewDesk is a WebMCP workspace for dossier review. The live demo is Harbor Calm Serum: the product specification is the subject; the formula and certificate are references.

The page walks Documents → Findings → Corrections → Close.

  1. Start the demo. ProDocuX verifies a typed evidence bundle and flags the planted disagreements (formula revision, pH range). PDX opens a digest-bound checkpoint.
  2. The agent focuses a finding and opens the governing source PDF in the same tab.
  3. A correction rewrites normalized evidence only. Source PDF bytes and digests never change. Commit re-runs ProDocuX and replaces the PDX checkpoint.
  4. An observed fact (the pH) can be confirmed without rewriting the certificate. Human-only approval stays on the UI. There is no WebMCP tool that approves the checkpoint.

Registered tools include start_demo_audit, get_workspace_state, select_finding, open_source_document, propose_correction, commit_correction, and confirm_observed_fact. execute() hits the same FastAPI routes the page uses, so the workspace updates in place.

No login. Judges can open https://pdx-reviewdesk.onrender.com/ in ChatGPT’s in-app browser or in Chrome 149+ with WebMCP testing enabled.

How we built it

The UI is Vite and React. On every run-state change it aborts the previous registration and calls document.modelContext.registerTool for the tools that are currently enabled. Each tool’s execute() function is a real workspace mutation, not a prompt that describes the UI.

The API is FastAPI. It consumes published PyPI packages:

  • prodocux==0.3.0rc4 for verify_evidence_bundle
  • pdx-artifact-engine==0.3.0a4 for checkpoint open/replace and the approval ledger

GET /health publishes those installed versions. CI asserts they load from site-packages.

Authorization does not trust JSON actor or channel. The page session cookie plus a capability header decide whether a call is treated as UI or WebMCP. Human-only approval at the current demo is a channel boundary, not cryptographic proof that a person pressed the button.

The hosted app is one Python process that serves /v1, /health, and the built SPA on Render.

Challenges we ran into

Keeping WebMCP honest was harder than registering tools. If execute() does not change the page, the agent is just narrating. If the API trusts a body field named actor, the agent can pretend to be the human. We had to make the session cookie and capability header the only authorization, and keep approval off the tool catalog.

Render’s Free plan does not attach a disk, so runs are ephemeral and the service spins down when idle. That is acceptable for judging. It is not how a durable review desk would store an approval ledger.

Accomplishments that we're proud of

  • A WebMCP tool call updates the same documents, findings, and checkpoint the human is looking at.
  • Verification and digest-bound checkpoints come from published products, not from a page-local reimplementation.
  • Source PDFs are immutable. Corrections cannot launder a new file in as the original.
  • The tool surface cannot approve. The human gate is visible and boring, which is what we wanted.
  • The live URL, public Apache-2.0 repository, and /health pins are all checkable without a login.

What we learned

WebMCP is not a second kernel. It is how an agent holds the same desk as the human. The valuable tools are state-dependent: you cannot commit a correction that does not exist, and you should not be able to approve through the agent channel.

On the other hand, the security claim is important. A channel boundary is not a hardware attestation. It has to be emphasized before talking about “human in the loop.”

What's next for PDX ReviewDesk

Review is the first slice, not the final product. The desk should become a place where humans and agents co-author the packet, not only argue about PDFs that already exist.

Next, an agent will fill important documents from files the human names or from search results it is allowed to use. The human stays on the same page, watches the draft appear, corrects it, and accepts it. When the packet is agreed, ReviewDesk exports the specified formats - the durable path for verification and digest-bound artifacts is already the published ProDocuX and PDX Artifact Engine stack.

The review tools stay. They become the acceptance pass over a jointly written dossier, instead of the whole story.

Built With

Share this project:

Updates

Submission history