|
| 1 | +--- |
| 2 | +summary: "Lightweight production AI governance checklist for OpenClaw architecture changes" |
| 3 | +read_when: |
| 4 | + - Adopting external AI architecture advice for OpenClaw |
| 5 | + - Adding evaluation, replay, tracing, cost, or agent context governance |
| 6 | + - Reviewing whether an AI system change needs a larger architecture project |
| 7 | +title: "Production AI governance" |
| 8 | +--- |
| 9 | + |
| 10 | +OpenClaw already has several production AI building blocks: scoped |
| 11 | +`AGENTS.md` files, workspace skills, memory search, provider replay policies, |
| 12 | +diagnostic traces, session usage accounting, plugin lifecycle traces, channel |
| 13 | +routing, and QA lanes. Use this page when an external production AI checklist |
| 14 | +or architecture diagram looks useful, but the right answer is governance and |
| 15 | +verification rather than a repo-wide rewrite. |
| 16 | + |
| 17 | +The default stance is lightweight adoption: |
| 18 | + |
| 19 | +- Strengthen existing OpenClaw contracts before adding new layers. |
| 20 | +- Prefer evidence, replay, and targeted docs over broad directory reshuffles. |
| 21 | +- Keep core extension-agnostic; owner-specific behavior stays in the owning |
| 22 | + plugin, channel, or provider. |
| 23 | +- Do not change live config, credentials, provider defaults, channel defaults, |
| 24 | + or runtime services as part of this pass. |
| 25 | + |
| 26 | +## Adoption matrix |
| 27 | + |
| 28 | +| External layer | OpenClaw mapping | Decision | |
| 29 | +| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | |
| 30 | +| App entry and config | Gateway, CLI, Control UI, typed config docs | Adapt through existing docs and config contracts | |
| 31 | +| Retrieval and memory | [Memory search](/concepts/memory-search), memory backends, QMD/session search | Adopt source and scope requirements; do not add a new retrieval stack by default | |
| 32 | +| Services and routing | [Agent loop](/concepts/agent-loop), [Channel routing](/channels/channel-routing), provider/runtime helpers | Adapt through existing owner boundaries | |
| 33 | +| Prompt and agent context | [System prompt](/concepts/system-prompt), scoped `AGENTS.md`, [Skills](/tools/skills), workspace files | Adopt as task contracts and scoped context, not hardcoded prompts | |
| 34 | +| Agents and tools | Agent runtime hooks, plugin hooks, tools, subagents | Adapt with documented hook points; avoid hidden contract bypasses | |
| 35 | +| Security guards | Gateway security, tool policy, exec approvals, sandboxing, hooks | Adapt; fix the core path first unless the surface is high risk | |
| 36 | +| Evaluation | Unit tests, replay tests, QA lanes, live tests | Adopt a minimum golden and replay contract for high-risk paths | |
| 37 | +| Observability and cost | Diagnostics, stability events, traces, session usage, `/usage`, `/status` | Adopt a stage-level checklist before adding new telemetry backends | |
| 38 | +| Data boundaries | Memory roots, session stores, external artifacts such as cron task ledgers and command lane snapshots | Adapt via explicit snapshot or artifact boundaries | |
| 39 | +| Docs and coding agent context | Docs read hints, scoped `AGENTS.md`, skills, repo rules | Adopt; keep guidance discoverable and scoped | |
| 40 | +| Semantic cache, query rewriter, adaptive router | No default adoption | Defer until cost or quality evidence proves the need | |
| 41 | +| Repo-wide folder structure | Existing OpenClaw layout and owner boundaries | Reject as-is | |
| 42 | + |
| 43 | +## Minimum evaluation contract |
| 44 | + |
| 45 | +Any high-risk AI pipeline should have at least one executable or documented |
| 46 | +golden case for each relevant behavior below. Link to existing tests when they |
| 47 | +already cover the behavior; do not invent a parallel test harness only to match |
| 48 | +an external checklist. |
| 49 | + |
| 50 | +- **Memory retrieval:** results preserve source, scope, and degraded-mode |
| 51 | + behavior. A memory failure should not silently become unscoped context. |
| 52 | +- **Provider and tool replay:** replay preserves transcript bytes and tool |
| 53 | + results unless a documented repair path intentionally rewrites them. |
| 54 | +- **Channel routing:** every configured inbound surface is named separately. |
| 55 | + DMs, groups, channels, threads, mentions, slash commands, webhooks, and |
| 56 | + native command delivery are distinct surfaces when the config exposes them. |
| 57 | +- **Agent context:** scoped `AGENTS.md`, workspace files, skills, and memory |
| 58 | + rules are loaded through the documented prompt/context path. |
| 59 | +- **Cost and context growth:** unusually large token, context, or cache-read |
| 60 | + changes can be traced back to a session, model, provider, or stage. |
| 61 | + |
| 62 | +Use [Testing](/help/testing) for regular suite selection and QA commands. |
| 63 | + |
| 64 | +## Observability checklist |
| 65 | + |
| 66 | +Before a high-risk pipeline change is considered production-ready, an operator |
| 67 | +should be able to answer these questions from existing logs, diagnostics, |
| 68 | +session metadata, or test artifacts: |
| 69 | + |
| 70 | +- Which stage failed or produced the surprising output? |
| 71 | +- Which session, agent, model, provider, channel, and inbound surface were |
| 72 | + involved? |
| 73 | +- What input and output summaries are safe to inspect without exposing raw |
| 74 | + payloads or credentials? |
| 75 | +- Are token, cache, and cost changes attributable to a stage or provider? |
| 76 | +- Can user feedback, a support report, or a diagnostics bundle be linked back |
| 77 | + to the relevant run? |
| 78 | +- Is the failure mode covered by a targeted test, replay, QA scenario, or live |
| 79 | + smoke? |
| 80 | + |
| 81 | +Start with existing surfaces such as diagnostics export, stability events, |
| 82 | +session usage, cache traces, plugin lifecycle traces, and provider replay tests. |
| 83 | +Add a new telemetry backend only after this checklist shows an actual gap. |
| 84 | + |
| 85 | +## Agent context boundaries |
| 86 | + |
| 87 | +The coding-agent context layer maps to OpenClaw's existing scoped context |
| 88 | +system: |
| 89 | + |
| 90 | +- Repo rules live in `AGENTS.md` and scoped `AGENTS.md` files. |
| 91 | +- Agent persona and workspace memory live in the agent workspace, not in repo |
| 92 | + docs. |
| 93 | +- Skills provide reusable operating procedures and should stay scoped to the |
| 94 | + agent or plugin that needs them. |
| 95 | +- System prompt changes must go through the documented prompt assembly path. |
| 96 | +- Multi-agent or multi-persona setups need separate workspaces and agent state; |
| 97 | + do not rely on `agentId` alone to isolate persona, memory, or auth behavior. |
| 98 | + |
| 99 | +When a new channel, plugin, agent, or automation surface is added, document the |
| 100 | +inbound surfaces it exposes and the context sources it is allowed to load. |
| 101 | + |
| 102 | +## Stop rules |
| 103 | + |
| 104 | +Stop this lightweight adoption path and open a separate architecture project if |
| 105 | +the change requires any of the following: |
| 106 | + |
| 107 | +- Public SDK or Gateway protocol changes. |
| 108 | +- Provider defaults, channel defaults, credential handling, or live config |
| 109 | + mutation. |
| 110 | +- A new telemetry backend, database, queue, or external service. |
| 111 | +- Moving owner-specific extension behavior into core without evidence that |
| 112 | + multiple owners need a generic seam. |
| 113 | +- Semantic cache, query rewriting, or adaptive routing without concrete cost, |
| 114 | + quality, or reliability evidence. |
| 115 | +- Repo-wide folder or package restructuring. |
| 116 | + |
| 117 | +## Verification entry points |
| 118 | + |
| 119 | +For docs-only governance changes, use: |
| 120 | + |
| 121 | +```bash |
| 122 | +pnpm docs:list |
| 123 | +git diff --check |
| 124 | +``` |
| 125 | + |
| 126 | +If trace, cost, replay, routing, or runtime code changes are made, run the |
| 127 | +smallest targeted test that covers the touched surface first. Escalate to |
| 128 | +`pnpm check:changed` when shared runtime, config, protocol, or public contract |
| 129 | +behavior changes. |
| 130 | + |
| 131 | +## Related |
| 132 | + |
| 133 | +- [Gateway architecture](/concepts/architecture) |
| 134 | +- [Agent loop](/concepts/agent-loop) |
| 135 | +- [System prompt](/concepts/system-prompt) |
| 136 | +- [Agent workspace](/concepts/agent-workspace) |
| 137 | +- [Memory search](/concepts/memory-search) |
| 138 | +- [Channel routing](/channels/channel-routing) |
| 139 | +- [Usage tracking](/concepts/usage-tracking) |
| 140 | +- [Diagnostics export](/gateway/diagnostics) |
| 141 | +- [Testing](/help/testing) |
0 commit comments