Lesson 6 of 6 · 0%Capstone: publish an operating map, not a deploymentAssessment
Course map

Foundations and Architecture

0 of 6 complete0 of 6

Lesson 6.1 · 60 minutes

Capstone: publish an operating map, not a deployment

Produce a one-page, evidence-led operating map that makes an OpenClaw deployment reviewable before anyone installs, exposes, or automates it.

Skip course map
Current lessonCapstone: publish an operating map, not a deployment0% complete · 0/6 lessons

Foundations and Architecture

0% complete · Current: Capstone: publish an operating map, not a deployment

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:

  1. an original system and request/data-flow diagram;
  2. the Gateway, agent, session, memory, model, channel, tool, and recipient surfaces that actually apply;
  3. at least three explicit boundaries: identity/credentials, untrusted content, and external side effect;
  4. an owner and stop/escalate rule for each external action;
  5. source receipts with revision and review date; and
  6. 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

Limitations

  • Primary-source editorial review; capstone is a redacted planning artifact, not proof of production readiness.

Open the public evidence snapshot

Lesson checkpoint

Ready to move on?

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