Verifiedon 2026.7.1-2
Action boundary
Before you act
- Expected result
- A one-page map has complete request paths, credible ownership, explicit risks, and reversible action paths supported by current source receipts.
- Failure mode
- The capstone contains secrets, private transcript content, unsupported product claims, or an unapproved configuration/deployment change.
- Rollback
- Keep the deliverable local and redacted. Remove sensitive material, revert no system changes, and escalate unresolved boundary questions to the named owner.
Scenario
You inherit a proposed personal-assistant deployment. It will accept messages from an operator’s chosen channel, call one read-only internal service, and return a response. It may later add a team room and browser node. You are not asked to install or expose anything. Your job is to make the design safe to review.
Deliverable
Submit one redacted page containing:
- an original system and request/data-flow diagram;
- the Gateway, agent, session, memory, model, channel, tool, and recipient surfaces that actually apply;
- at least three explicit boundaries: identity/credentials, untrusted content, and external side effect;
- an owner and stop/escalate rule for each external action;
- source receipts with revision and review date; and
- the current status: proposed, tested in sandbox, approved, or not approved.
Do not substitute a video, copied transcript, or generic security checklist for this work. The page must be understandable without third-party media.
Rubric
| Criterion | Weight | Pass signal |
|---|---|---|
| Complete path | 30% | Each inbound route can be traced through Gateway, session, agent, possible tool, and outbound route. |
| Credible ownership | 25% | Every external action and boundary has a named accountable owner and escalation path. |
| Risk clarity | 25% | Trust, data, and tool boundaries are explicit; session routing is not called authorization. |
| Reversible action | 20% | A stop condition, non-production test boundary, and rollback/handoff rule appear before any proposed change. |
A passing capstone proves disciplined analysis—not production readiness. Any addition of public ingress, a privileged tool, new plugin, mixed-trust audience, or external recipient needs its own review.
Final check
Before sharing, remove secrets, QR codes, personal identifiers, raw transcripts, private hostnames, and unnecessary log output. Confirm that the source receipt links resolve to the exact reviewed revision and that your claims distinguish the current documented behaviour from planned design decisions.
Source provenanceVerification and sources
Review receipt rr_foundations_operating_map_capstone
- Outcome
- approved
- Method
- source-review
- Reviewer
- forge-independent-review
- Reviewed
Evidence
- openclaw-foundations-primary — openclaw-main-2e26244-architecture; snapshot
f8054bd87f73…
Limitations
- Primary-source editorial review; capstone is a redacted planning artifact, not proof of production readiness.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.