The ziola command — the front door to Ziola's WebMCP interoperability stack.
npx @zioladev/cli demoThat's it. No account, no API key, no network, no setup — a zero-config reference demonstration that runs a
real multi-provider trajectory through the published Ziola runtime, produces genuine
provider-conformance-report/2 evidence, and qualifies it through the published Ziola qualification
engine — then shows you the whole story.
Qualification currently operates against Ziola's reference evidence format (provider-conformance-report/2). A generalizable ingestion layer that normalizes evidence from arbitrary WebMCP implementations is in active development.
A thin client + local runner over the published Ziola packages. It invokes the engines; it never reimplements them. Local commands are free and offline; hosted commands talk to qualify.ziola.dev.
TRY ziola demo [--details]
USE LOCALLY ziola qualify <evidence.json> --profile <id> [--details]
USE HOSTED ziola submit <evidence.json> --profile <id> [--details]
INSPECT HOSTED ziola qualification <id> [--details | --events]
Zero-config, no key, no network. Runs a reference multi-provider trajectory (cafe → gallery) through
@zioladev/interop-runtime, qualifies the resulting evidence through @zioladev/interop-conformance, and
renders providers · per-leg execution · terminal objective · qualification · fault attribution:
Ziola reference demo
Trajectory
cafe → gallery
Providers
cafe, gallery
Execution
1. order_latte
✓ executed
Provider: PASS
2. check_design_drift
✓ executed
Provider: PASS
Terminal objective
✓ attained
Qualification
Profile: trajectory/multi-provider-reference@1
Result: QUALIFIED
Fault attribution
none
This demo uses Ziola's published runtime and qualification engine
against deterministic reference providers. It is a reference
demonstration, not evidence of universal compatibility.
Add --details for the full rigor view — the same evidence, with every profile requirement's verdict and
the evidence lineage, so the "why" is visible without producing an evidence file of your own:
… (trajectory / execution / qualification as above) …
Requirements
Provider count HELD
Terminal requirements HELD
Ordered trajectory HELD
Provider conformance HELD
Carried-state provenance HELD
Provider-owned failures NONE
Evidence
Reports: 1
Bundle hash: 01d8d7d7
Profile: @1
Evidence lineage
reference-runtime/1
report: ad6f2ce8
The demo generates genuine evidence on every run, so the bundle and report hashes differ run to run — the qualification is computed live, never canned.
Local, free, offline. Qualifies an existing evidence bundle with the published
@zioladev/interop-conformance — no key, no server. It shows not just the outcome but the reasoned
per-requirement result and attribution, so you can see whose layer caused a failure without charging the
provider for someone else's:
Ziola Qualification
Profile: trajectory/multi-provider-native@1
Result: NOT QUALIFIED
Requirements
held providerGrade [native-browser-lane]
failed terminalAttained [native-browser-lane]
held trajectoryConformance [native-browser-lane]
Attribution
model_tool_selection
Provider nonconformance: false
Hosted. Submits to qualify.ziola.dev, polls the asynchronous service to a terminal state, and renders
the durable result. Requires ZIOLA_API_KEY. (This is the hosted path — it never silently falls back to
local qualification.)
Retrieve a durable hosted qualification, or its ordered VI-D operational trail (how the distributed
service produced the result — a separate truth from what the result is). Requires ZIOLA_API_KEY.
qualify, submit, and qualification accept --details for the reasoned view between the concise
default and raw --json: the outcome, then why — per-requirement verdicts (with friendly labels),
the requirements that were actually disqualifying (attribution), the evidence manifest, and the evidence
lineage (which runtime lane each report came from). It reads the bound result; it never recomputes it.
All commands accept --json and emit the engine/server response verbatim — no decorative prose, no
CLI-specific report schema.
Provider Declaration @zioladev/provider-tools
Provider Conformance @zioladev/provider-conformance
Interoperability Runtime @zioladev/interop-runtime
Interoperability Qualification @zioladev/interop-conformance
Execution Control @zioladev/execution-control
| code | meaning |
|---|---|
0 | qualified |
1 | not_qualified |
2 | insufficient_evidence |
3 | service / network / authentication / CLI error |
Retrieval commands return 0 on success, 3 on error. Stable and deterministic — a CI job can gate a
release on ziola qualify (local) or ziola submit (hosted).
One command that proves the live distributed service end to end, for when a plain demo isn't enough:
export ZIOLA_API_KEY=… # your service credential
npm run gate
It generates fresh evidence each run (a novel bundle hash, so it never lands idempotently on an old record), then proves five things in order and prints a pass/fail transcript:
1 Submit fresh evidence ✓ 202 accepted
2 Qualify to terminal ✓ completed · QUALIFIED
3 Durable retrieval by id ✓ <uuid>
4 Idempotent re-submit ✓ same id returned
5 Operational trail ✓ accepted → claimed → completed
It reuses the CLI's own HTTP client — the exact path ziola takes — so a green gate is a statement about
the shipped client, not a bespoke script. Exit 0 if every check holds, 1 otherwise (e.g. an empty
operational trail fails the gate rather than passing quietly).
| variable | purpose |
|---|---|
ZIOLA_API_KEY | required for submit / qualification. No interactive login, no token file, no persistence. |
ZIOLA_BASE_URL | optional — override the service URL (default https://qualify.ziola.dev). |
demo and qualify need neither. If a hosted command is missing the key it fails before any request,
and the key is never printed. A 429 surfaces the server's Retry-After honestly.
- Invokes, never reimplements. Depends on the published
@zioladev/interop-runtimeand@zioladev/interop-conformanceand calls them as-is — it reproduces no runtime or qualification logic. demois reference-only. Deterministic reference providers on the in-process reference lane: no real models, browsers, WebMCP runtime, network, or credentials. Labeled a reference demonstration, never a claim of universal compatibility.- Three states preserved.
qualified/not_qualified/insufficient_evidencestay distinct. - Domain vs operational truth stay separate. The qualification resource and the operational history are different resources and different output.
- Hosted result is authoritative.
submitnever reinterprets an outcome and never silently qualifies locally when the service is unavailable — it fails. - No proprietary logic. Knows nothing of how execution-control decisions are derived; imports nothing proprietary.
demo · local qualify · hosted submit · hosted qualification(+--events), against an
already-produced evidence bundle. Not included: evidence generation beyond the reference demo, provider
discovery, live WebMCP/--native execution, model adapters, accounts, billing, interactive login,
dashboards, a GitHub Action, custom profiles, streaming, or webhooks — each earned by real need.
Apache-2.0. Clean-room — imports nothing from any proprietary source; a test asserts it. See NOTICE.