The current Verify contract is explicit.

CLI and local API

cd projects/dev/opencompliance
python3 scripts/verify_fixture.py --fixture-root fixtures/public/issued --check

cd projects/dev/opencompliance
python3 scripts/serve_verify_api.py --port 8788

cd projects/dev/opencompliance
python3 -m http.server 8000

Then open http://127.0.0.1:8000/ui/verify/. The compatibility wrapper still exists for the built-in ExampleCo packs via python3 scripts/verify_example.py --fixture issued --check.

GET /contract and POST /verify

The local HTTP surface exposes GET /healthz, GET /fixtures, GET /contract, and POST /verify. The 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.

fixture_path

{
  "fixtureName": "issued",
  "input": {
    "mode": "fixture_path",
    "fixtureRoot": "/abs/path/to/fixture-shaped-root"
  }
}

inline_bundle

{
  "fixtureName": "issued",
  "input": {
    "mode": "inline_bundle",
    "profile": {"profileId": "exampleco-issued-profile"},
    "evidenceClaims": [],
    "useDefaultOscalSeed": true
  }
}

The inline bundle can also carry explicit OSCAL material under input.oscal with catalog, profile, ssp, and mappingCollection. If input.oscal is omitted, the local API can currently fall back to the checked-in OSCAL seed for the selected fixture when useDefaultOscalSeed is true.