Capstone: publish an operating map, not a deployment

Verifiedon 2026-07-302026.7.1-2

The capstone boundary

This capstone is a design-review artifact, not a deployment exercise. You will publish a one-page, redacted operating map for a fictional personal-assistant system before anyone installs, exposes, pairs, or automates it. The result should let a second operator answer: what receives a request, where context is stored, which tool or node could act, who owns each boundary, what evidence proves an outcome, and where the system must stop.

The design uses the full Foundations mental model. The architecture source gives the Gateway, clients, nodes, channels, and WebSocket flows. The agent-loop source separates accepted runs, queued turns, model proposals, tool events, lifecycle outcomes, and persistence. The session source and memory source prevent you from collapsing context, transcripts, and durable notes. The security source supplies the single-trusted-operator boundary and the separate-Gateway decision.

A mature map answers five review questions in order. First, what enters: identify the channel, accepted sender class, attachments, room history, and any webhook or automation. Second, where it is routed: name the Gateway, session scope, and trust cell. Third, what the model sees: list bootstrap files, skills, memory, provider, and data minimisation. Fourth, what can act: list tools, plugin-provided surfaces, nodes, credentials, approval gates, and sandbox assumptions. Fifth, what leaves: name the recipient, channel route, delivery evidence, retention, and owner. This sequence keeps a diagram from becoming a decorative architecture picture.

Use status labels consistently. Observed means an inventory, log category, or current source supports the statement. Proposed means a design choice not yet implemented. Unverified means the connection might exist but requires evidence. Not approved means the owner has explicitly stopped the change. Never use “secure” as a status without naming the threat model and controls. A personal assistant with one trusted operator is a different boundary from a shared bot serving mutually untrusted people.

The learner artifact should include a small evidence ledger beside the visual: claim, source URL, reviewed revision, owner, and limitation. For example, the architecture document supports Gateway ownership and node roles; it does not prove that your fictional channel is allowlisted. The security document supports the separate-Gateway recommendation for hostile multi-user access; it does not approve your credentials. The agent-loop document supports lifecycle categories; it does not prove that a recipient saw a message. This ledger makes peer review faster and makes future freshness work possible.

When the map is finished, a reviewer should be able to reject one boundary without losing the whole design. If the recipient is unclear, the architecture can remain a proposed read-only fixture. If the browser node is too powerful, remove that branch and keep the channel-to-model path. If a mixed-trust audience appears, split the trust cell before adding a tool. This modularity is the point of a map: it turns an all-or-nothing deployment conversation into bounded decisions with clear owners.

That means a “pass” is a reviewable state, not a green light to connect accounts. Keep the page local until the next owner gate is explicitly accepted.

It should demonstrate restraint as clearly as it demonstrates structure: no execution is success when the brief is to establish a safe boundary first.

This is a capstone about accountable thinking, not about making a confident-looking picture.

It rewards clear boundaries, evidence, and reversible decisions over polish or optimism.

This capstone leaves no permission hidden.

Keep every decision observable, bounded, and reversible.

Scenario and required deliverable

You inherit a proposed personal-assistant deployment. It will accept messages from one chosen channel, call one read-only internal service, and return a response. A team room and browser node may be added later. You are not asked to install or expose anything. Your job is to make the design safe to review.

Create one page with these sections:

1. Scope and status: fictional system name, OpenClaw stable range >=2026.7.1-2 <2026.8.0, reviewed revision 2e26244cec32e61f6117740d3ea273b1ecb54efc, and status proposed, sandbox-tested, approved for implementation, or not approved.
2. Original system and request/data-flow diagram: every active request route must be traceable through Gateway, session, agent/model, possible tool/node, and outbound route.
3. Operating-surface table: Gateway, client, node, channel, session, transcript, memory, provider, tool, plugin, and recipient rows only where they actually apply.
4. At least three explicit boundaries: identity/credentials, untrusted content, and external side effect. Add retention and mixed-trust boundaries when relevant.
5. Ownership and escalation: a named accountable owner, evidence required, stop condition, and rollback/handoff for each external action.
6. Source receipts: direct primary links, exact revision, verification date, and limitations. A source receipt supports a claim; it does not approve your design.

The page must remain readable without a video or JavaScript. Do not include secrets, QR codes, personal identifiers, raw transcripts, recipient names, private hostnames, or copied third-party course material.

Worked example: a reviewable one-page map

A weak artifact says: Channel → OpenClaw → internal service → answer. It hides session scope, the Gateway owner, model-provider processing, tool policy, recipient, and what happens if the result is wrong. A stronger synthetic artifact says:

Allowlisted operator channel → Gateway (auth + routing) → per-channel-peer session (context only) → agent turn/model (proposal) → read-only fixture lookup (policy + approval) → redacted result → operator review → same-channel reply (delivery record required).

Its table then adds:

The map says what is observed, proposed, and unknown. It does not claim production readiness because no real deployment was changed.

Lab: produce and peer-check the artifact

Start with a blank document or diagram tool. Use generic names such as CHANNEL_A, GATEWAY_1, FIXTURE_LOOKUP, and RECIPIENT_CLASS_OPERATOR. For every arrow, add data type, identity class, decision control, and evidence. For every external action, add owner and rollback. If a relationship is not confirmed by an inventory or source, label it unverified.

Peer-check your own artifact using these questions:

• Can a reviewer trace a request without asking you what an unlabeled arrow means?
• Does any row imply that a session key authenticates a sender?
• Does any skill, memory note, plugin install, or model response appear as enforcement when it is only context or capability?
• Could a team room or contractor access the same delegated authority? If so, is a separate trust cell explicit?
• Do “sent,” “delivered,” and “model proposed” have different evidence labels?
• Is every claim tied to a current primary URL and exact revision?

status: proposed
supported-openclaw: ">=2026.7.1-2 <2026.8.0"
reviewed-revision: 2e26244cec32e61f6117740d3ea273b1ecb54efc
external-actions: none executed
open-questions: [recipient approval, browser-node scope]
next-gate: named security owner review
rollback: keep local; do not expose or install

1. The Gateway is the central routing and session owner, not the channel.
2. The session selects context; it is not an identity or authorization boundary.
3. The tool and outbound recipient each require an explicit owner and stop rule.

Rubric and expected result

A passing artifact earns credit on four dimensions:

Expected result: another operator can review the page without needing your private environment or accepting an unsupported claim. A passing capstone proves disciplined analysis—not production readiness. Any addition of public ingress, privileged tool, new plugin, mixed-trust audience, or external recipient needs its own review.

Failure cases and rollback

The capstone fails if it contains secrets, copied transcripts, unsupported product claims, a diagram that skips the Gateway/session/tool path, or an implied approval hidden in a model response. It also fails if the learner uses the artifact to justify a real install or channel exposure. A beautiful diagram is not evidence if its connections are invented.

If a sensitive value enters the draft, keep the document local, remove the value, and tell the data owner if policy requires. If a source cannot substantiate a claim, mark it requires primary receipt and add a stop condition. If ownership is unclear, set status to not approved and escalate; do not assign authority to a session ID, plugin, model, or course completion. No system change needs to be rolled back because the capstone is planning-only.

Source receipt and handoff

This capstone was reviewed against the OpenClaw stable window 2026.7.1-2, revision 2e26244cec32e61f6117740d3ea273b1ecb54efc, on 2026-07-30. Keep these direct receipts with the artifact: architecture, agent loop, sessions, tools, and security. Record limitations: the exercise is redacted, synthetic, and not evidence that a deployment is safe to publish.