The workbench is intentionally narrow. It does not pretend there is already a hosted multi-tenant product UI. It gives a serious user one browser entrypoint for the deterministic local Verify API, the current synthetic ExampleCo corridors, and the machine-readable verifier contract.
ui/verify/index.htmlThe workbench lives in the private source tree and is also copied into the public verifier bundle. The same file should work from a local checkout or from a copied release bundle served over a local HTTP server.
GET /contract and POST /verifyThe workbench does not invent a second verdict path. It calls the same local API contract as the CLI and uses the same deterministic runtime artifacts, typed boundary tags, and outcome policies.
cd projects/dev/opencompliance
python3 scripts/serve_verify_api.py --port 8788
# second terminal, same directory
python3 -m http.server 8000
# then open
http://127.0.0.1:8000/ui/verify/The workbench can preload the checked-in public ExampleCo corridors from fixtures/public/*, including minimal, failed, stale, medium, issued, cyber-baseline, and ai-governance.
The same UI can send a fixture_path request to the local API, which is useful when testing copied bundles or local synthetic variations without editing the browser payload directly.
This is a browser workbench for the deterministic local runtime. It is not a claim that hosted auth, tenant isolation, operator ingress controls, or live organization evidence flows are finished product surfaces.
The current versioned public bundle now includes both docs/ and ui/, so the workbench and its linked documentation remain usable when the bundle is copied out of the private monorepo and served locally.
The workbench is useful because it makes the existing deterministic surface inspectable. It would become misleading if it implied a production customer workspace before signer-bound ingress, live connectors, and external release attestation exist.