03 · Verify
Prove the wiring
before production.
Doctor inspects the config. Demo and synthetic runs exercise redispatch, crash, contention, and outage. Reports stay labeled so a number is never a manufactured before.
How to check
Read-only first.
Then a hostile retry.
doctorInspect mycelium.yaml without executing tools. Missing IDs and unwired guards show up in the report.
verifyExercise synthetic redispatch, crash, contention, and outage against the configured backend. Never hits application tools, LLMs, or real providers.
providers verifyRun the adapter conformance kit. It fails on unsafe uncertainty handling or observed writes and emits a signed report bound to the tested source.
demoCompare an unguarded path with a ledgered one. See hard-block, return, repair, reconcile, and operator release.
demo --redisTwo OS processes against a real Redis ledger. One claimer wins; the other polls or returns the stored result.
Commands
Start with Doctor.
Verification is not a dashboard. It is a command that tells you whether the boundary is actually attached to the tool.
terminal
mycelium doctor --config mycelium.yaml
mycelium verify --config mycelium.yaml
export MYCELIUM_ADAPTER_REPORT_SIGNING_KEY='from-your-secret-manager'
mycelium providers verify gmail --key-id provider-ci --output adapter-report.json
mycelium providers verify-report adapter-report.json
mycelium demo
mycelium demo --redis
mycelium run --config mycelium.yaml -- python -m my_agentEvidence labels
Never invent
a historical before.
- Observed in production: a live lane, like the outbound email report on the homepage.
- Synthetic verification: demo, crash, contention, or outage fixtures.
- Adapter verified: the signed report passed the required synthetic cases and still matches the installed adapter source.
- Operator asserted: a human confirmed the outcome.
- Not verifiable: residual risk stays visible.
Protect one tool