LooPROOF

Inspiration

Enterprise buyers rarely encounter one product surface. They compare a marketing page, pricing matrix, docs, trust center, contract language, and actual product behavior. Those surfaces drift. A browser agent can describe each page, but it still has to guess which statement wins.

LooPROOF turns that hidden governance problem into a WebMCP-native collaboration surface. The website exposes not only controls, but the product claims, evidence provenance, authority boundary, and claim ceiling an agent needs to reason safely.

What it does

This challenge build includes a synthetic enterprise SaaS evidence graph with customer-facing claims and authoritative runtime, contract, and repository evidence. LooPROOF deterministically classifies each claim as BLOCK, REVIEW, ALIGNED, or NOT_EVALUATED.

A human and an agent can work through the same visible state to:

• inspect the product-truth summary;
• find claims blocking an enterprise sales gate;
• trace every source, locator, value, provenance class, and authority level for a claim;
• focus the dashboard on the same claim the agent is investigating;
• stage canonical copy changes in a local-only sandbox;
• re-run the deterministic gate and reach STAGED_CONSISTENT_NON_ISSUING.

LooPROOF deliberately refuses to call a sandbox change “fixed.” Production verification remains a separate authority.

Why WebMCP is essential

Without WebMCP, an agent must infer the purpose of rows, badges, filters, and buttons from the visual interface. More importantly, it cannot reliably infer LooPROOF's domain contract: runtime evidence outranks marketing copy; model-proposed evidence cannot bind a verdict; a missing evidence edge is NOT_EVALUATED; and a sandbox patch has a strict claim ceiling.

LooPROOF registers 7 imperative WebMCP tools on document.modelContext. Closed schemas give the agent stable claim IDs, explicit inputs, side-effect annotations, and compact structured outputs. Tool execution updates the same state the human sees, creating a shared workspace rather than hidden backend automation.

How we built it

The app is dependency-free JavaScript, HTML, and CSS. A deterministic TruthEngine evaluates a bundled evidence graph and overlays sandbox patches in memory. The WebMCP adapter registers tools with document.modelContext.registerTool(), uses AbortSignal for lifecycle cleanup, declares read-only and side-effect annotations, and normalizes outputs to compact MCP text content.

Node's built-in test runner verifies verdict binding, provenance boundaries, sandbox isolation, reset behavior, and tool-contract limits. GitHub Actions runs the complete verification suite.

What is new for this challenge

LooPROOF existed as a broader verification-engine concept before the submission period. During the challenge period, it was meaningfully extended through a new standalone public implementation containing:

• the complete imperative WebMCP tool surface;
• a shared human-agent state model;
• a provenance-preserving product-claim evidence graph;
• the local resolution sandbox;
• the deterministic re-verification path;
• a new responsive interface, test suite, security boundary, and challenge documentation.

The repository contains synthetic evidence and does not copy or expose the private production implementation.

Challenges

The central challenge was not exposing more tools. It was preventing agent convenience from weakening evidence semantics. The implementation had to make the useful path easy while refusing unsupported claims. We therefore separated evidence alignment, staged consistency, and production verification into distinct states.

Accomplishments

• 7 working imperative WebMCP tools.
• A coherent human-agent product experience rather than a wrapper around a chat box.
• Shared visible state between tool calls and the dashboard.
• Deterministic verdicts with provenance and authority ordering.
• A local sandbox that performs zero network, repository, or deployment writes.
• Explicit refusal to overclaim success.
• Dependency-free tests and CI validation.

What we learned

WebMCP is most powerful when a website exposes its domain semantics, not merely its controls. Tool schemas can encode the decisions an interface is designed to support, while the visible page preserves human oversight. The difficult design work is defining claim boundaries and side effects precisely enough that an agent can help without becoming a new source of product drift.

What's next

The production direction is to connect the same WebMCP surface to versioned proof packets generated from real product surfaces, repository policy, and observed runtime flows, while keeping final verification capability-separated.

Built With

• css
• github-actions
• html
• javascript
• node.js
• webmcp