Classify the message path before connection

Verifiedon 2026-07-302026.7.1

The first connection is a design decision

“Connect our chat” is not a technical specification. It hides at least six decisions: which provider is trusted, which identity can initiate work, what data crosses the boundary, which actions are allowed, who may receive a reply, and how an operator stops the path. If those decisions are not written down, the first credential or webhook configuration silently becomes policy.

This lesson uses a synthetic support-triage request so you can design the path without handling customer data. The goal is not to configure Telegram, WhatsApp, Discord, or a generic webhook from memory. Provider APIs, event names, permissions, and delivery semantics change. Before any provider-specific step, use the current OpenClaw documentation index and the OpenClaw release history. This course was reviewed against OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4; re-check that boundary before publication.

A six-part inventory

Start with a blank page, not a provider dashboard. Record one row per message path. “Support triage” may have an inbound event, a classification step, a draft, an approval request, and an outbound message; do not collapse these into “the bot.” For each row, answer:

1. Source and provider: Where did the event originate? Use a synthetic source such as test-discord-channel, never a real channel name in the learner artifact.
2. Stable identity: What provider-controlled identifier proves the sender or endpoint? A display name, avatar, email From header, or forwarded quote is presentation, not authority.
3. Data class: Is the payload public test data, internal operational data, personal data, secrets, or an unknown class? Unknown is a stop condition, not permission to continue.
4. Action class: Is OpenClaw only classifying, drafting, reading, writing, changing configuration, or causing an external side effect? Separate a draft from a send.
5. Recipient class: Which exact test destination is permitted? “The team” is not a destination. Define allowed, prohibited, and approval-required classes.
6. Retention and stop owner: Where is the decision record retained, for how long, and who can disable inbound acceptance and outbound delivery?

A useful inventory also records the route version, approval requirement, provider event identifier, and the evidence you expect after the test. If a field is unknown, write UNKNOWN — HOLD and name who must resolve it. An honest gap is safer than a confident guess.

Worked example: synthetic support triage

Suppose a test team wants to send a synthetic support message to OpenClaw, classify it as billing-question or technical-question, draft a response, and send only to a disposable reviewer chat. The inventory might contain these rows:

The prohibited row is as important as the allowed row: an external customer, a personal account, or an unverified destination must never be an implicit fallback. Add a default-deny rule before writing any allow rule.

{
"event": "evt_test_0042",
"provider": "synthetic-webhook",
"sender": "actor_test_17",
"dataClass": "synthetic-support",
"action": "draft-only",
"destination": "reviewer-test-room",
"approval": "required-before-send",
"retentionOwner": "records-owner",
"disableOwner": "integration-owner"
}

This record is intentionally not a provider configuration. It is a decision receipt. Never put tokens, webhook URLs, personal phone numbers, real chat IDs, customer text, or copied production logs into it.

Lab: draw and challenge the path

Create a left-to-right diagram with these boxes: synthetic sender → provider boundary → channel adapter → OpenClaw/Gateway work → policy gate → approver → delivery adapter → test recipient. Draw a red trust-boundary line around the provider and another around the recipient. Label each arrow with its data class and identity proof. Add a branch from every policy gate to drop and log. Add a second branch from the approval gate to hold when the approval is missing or expired.

Then run five questions against your own drawing:

• Can a correctly named but unallowlisted sender reach classification?
• Can a draft reach an external destination without an approval record?
• Can a timeout be mistaken for a confirmed send?
• Can the provider retry after local configuration is deleted?
• Who can disable the path, and what evidence proves it is disabled?

Expected result: each question has a named policy outcome and owner. Failure cases are not “the system errors”; they are explicit decisions such as drop, hold, quarantine, or escalate.

Failure handling and rollback

If the request owner cannot name the destination, stop before credentials. If the provider cannot expose a stable event or sender identity, hold the integration for provider research. If the intended action is irreversible, keep the path draft-only until the human gate is designed. If a real identifier appears in your artifact, delete the copy, rotate the exposed credential if relevant, and rebuild with synthetic values; do not “clean it up later.”

Rollback is deliberately boring: do not connect the channel, preserve the unresolved inventory as a review record, and return the missing decisions to the request owner. The learner artifact is the redacted inventory and diagram, not a working bot. In Lesson 2, you will turn the identity rows into an allowlist without treating names as authority.

Source receipt

Primary source index: docs.openclaw.ai/llms.txt. Version receipt: OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30. The exercise is provider-neutral; it does not claim that a particular provider adapter, permission set, or webhook mode is enabled.