Lesson 2 of 6 · 0%Make inputs, outputs, and failure modes explicitNext
Course map

Skills, Tools, MCP and Browser Automation

0 of 6 complete0 of 6

Lesson 2.2 · 45 minutes

Make inputs, outputs, and failure modes explicit

Define a capability contract that is bounded, typed, testable, and honest about unavailable evidence.

Skip course map
Current lessonMake inputs, outputs, and failure modes explicit0% complete · 0/6 lessons

Skills, Tools, MCP and Browser Automation

0% complete · Current: Make inputs, outputs, and failure modes explicit

Draft lesson: awaiting independent technical and publication review; do not use it as production configuration guidance.

Editorial review pendingon version support under review

Action boundary

Before you act

Expected result
A reviewer can validate requests without running the capability and can tell every failure from a successful empty result.
Failure mode
Free-form input, ambiguous output, or silent fallback makes a side effect or unsupported claim appear successful.
Rollback
Disable the capability and return a typed validation error until the contract and fixtures are corrected.

The contract is the safety feature

A description such as “research the web” is not a contract. It gives no limit on sources, cost, time, output, or authority. Build a contract that can fail before it invokes a tool.

Example request

{"query":"OpenClaw 2026.7.4 release notes","sources":["https://github.com/openclaw/openclaw/releases"],"maxFindings":3,"mode":"dry-run"}

Rules: query has a character limit; sources is an allowlist, not arbitrary URL discovery; maxFindings has a small maximum; and mode defaults to dry-run. Do not accept credentials, local paths, or instructions that alter the capability’s policy.

Example result

{"status":"ok","findings":[{"claim":"Release note found","url":"https://github.com/openclaw/openclaw/releases","retrievedAt":"2026-07-30T00:00:00Z"}],"sideEffects":[],"runId":"fixture-001"}

An empty result is not an error if the source was reached and no matching evidence exists. A malformed request is invalid_request; a timeout or unreachable allowlisted source is source_unavailable; an attempted write is side_effect_blocked. Never disguise one as another.

Lab — write the negative cases first

Create four fixture files for your capstone: valid request, overlong query, source outside the allowlist, and a request that asks to send/publish/delete. For each, write the expected status and assert that sideEffects is empty. The last three must complete without network or browser activity.

Checkpoint

A source returns HTTP 403. Which result is truthful?
A. ok with an empty list
B. source_unavailable plus the source URL and retry guidance
C. Retry against an arbitrary mirror
D. Ask the model to infer the missing content

Answer: B. The learner needs a distinguishable, reproducible failure. A status code does not license a substitute source or invented evidence.

Learner artifact

Draw a contract-flow diagram with four gates: input validation → allowlist/policy → invocation → evidence result. Put the three failure statuses beside the gate that produces them; make the blocked-side-effect path terminate before invocation.

Lesson checkpoint

Ready to move on?

Mark this lesson complete when you can apply its outcome without relying on the examples above.