Verifiedon 2026.7.1-2
Action boundary
Before you act
- Expected result
- A complete acceptance pack proves role separation, bounded execution, observable terminal states, review results, human-held publication, and one measured improvement.
- Failure mode
- The capstone is presented as a successful automation demo without source receipts, failure evidence, a review decision, or a human-held publication boundary.
- Rollback
- Hold the draft, disable any scheduled job, preserve redacted artifacts and run history, revoke unnecessary access, and rerun only after the postmortem control change is approved.
Capstone: Release intelligence, with a human at the boundary
Build a sandbox workflow that prepares—but does not publish—a weekly bulletin from an approved list of public primary sources. The workflow may use distinct researcher, verifier, and editor roles. The publication owner must be a human and no automation role may hold a production publishing credential.
Required acceptance pack
- Dependency graph and role/authority matrix.
- Source ledger with at least three primary URLs, retrieval times, and source fingerprints.
- Claim-review record showing at least one accepted and one rejected or held claim.
- Draft bulletin containing only accepted claims and links.
- Task control cards with cost/time ceilings and stop conditions.
- Durable-job definition or a clearly labelled manual-run substitute, including idempotency key and disable path.
- Operations snapshot: queue depth, oldest task age, retries by class, budget consumed, review backlog, and last terminal run status.
- Human publication decision marked hold, approve for a separate release action, or request changes. The capstone itself never publishes.
Failure tabletop
Inject one controlled failure: make a source unavailable, introduce a duplicate input key, or simulate a Gateway timeout after a draft appears. Show the classification, evidence inspected before retry, decision owner, and final state. “Retried and it worked” without this record does not pass.
Rubric
| Criterion | Weight | Pass signal |
|---|---|---|
| Role clarity and artifacts | 25% | Every node has an accountable role, inspectable handoff, and limited authority. |
| Gates and stop conditions | 30% | Budget, deadline, missing-evidence, and publication controls are explicit and exercised. |
| Observability | 25% | Signals, run history, failure classification, and escalation owner support a real decision. |
| Recoverability | 20% | The tabletop preserves evidence, prevents duplicate effect, and documents a safe resume or hold. |
Blameless postmortem
Write five short sections: what was expected; what happened; evidence and timeline; contributing conditions; and one control change with an owner and due date. Do not blame a role or model for a system condition. The best postmortem changes the graph, policy, threshold, or test so the next run is easier to inspect.
Final check
A pass means the workflow is accountable, bounded, and reviewable. It does not certify unattended publication or general production safety.
Check your understanding
Source provenanceVerification and sources
Review receipt rr_multi_agent_capstone_postmortem
- Outcome
- approved
- Method
- source-review
- Reviewer
- scout-independent-review
- Reviewed
Evidence
- openclaw-docs-multi-agent — openclaw-ec53d0e-multi-agent; snapshot
34df515eca92…
Limitations
- No production delivery, channel, or external side effect was exercised.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.