BUZZ for Service Design Teams
When I use BUZZ for Service Design, I am not looking for a prettier chat client. I am looking for the missing collaboration surface between a human designer and a role team. BUZZ gives me five primitives that matter in practice. First, a relay stores signed events. Second, every human or runtime appears as an identity with a 64-hex public key. Third, I get private stream channels with explicit membership. Fourth, I can mention one exact member by pubkey and see whether the reply came back from that same identity. Fifth, I get one per-channel Canvas document that acts as an index over the work.
The sharp edge is the boundary. BUZZ is where conversation, roster, attribution, and visible handoffs live. It is not the ASD store. A message can be genuine, signed, and useful, while still proving nothing about whether an artifact persisted through sd_artifact_write, whether a review passed, or whether a human gate receipt exists. I keep repeating that because the failure mode is seductive. Once a channel looks alive, people start treating the transcript as the system of record. That is exactly what ASD is designed to prevent.
The generated BUZZ Persona Pack carries the same canonical inventory as the other emitted ASD targets: 10 role prompts, 80 shipped skills from 81 sources, 30 sd_* tools, 228 pack-local MCP resources when the corpus is present, 38 registered artifact kinds, 39 catalog rows, 7 authored templates, and 12 emitted targets across the wider platform. That inventory matters because it tells me the pack is aligned with the rest of ASD. It does not tell me that a BUZZ-native host executed every tool, that every persona is materialized as a healthy runtime, or that a given channel has the right members. Those are separate proofs.
| BUZZ primitive | What it proves | What it does not prove |
|---|---|---|
| Relay event | A signed message, membership change, or Canvas update happened. | That an ASD artifact was persisted or reviewed. |
| Public-key identity | Which human or runtime authored the event on the wire. | That the identity belongs to the right persona definition without an audit join. |
| Private stream channel | The engagement has an explicit member list and conversation boundary. | That every member is healthy, unique, or authorized to mutate the ASD store. |
| Exact mention | A request was addressed to one chosen runtime public key. | That the runtime's reply cited resolvable workspace ids. |
| Canvas | The channel exposes a shared artifact index. | That the index itself is persistence, or that a phase may advance. |
This is why BUZZ fits Service Design so well. Service Design is already a team sport with visible handoffs, specialist roles, and human judgment at the hard edges. BUZZ preserves that shape. The orchestrator can delegate. The critic can block. The librarian can report drift. I can hold the phase gate myself. The channel shows the social topology honestly instead of flattening it into one assistant voice.
Personas, Identities and Public Keys
The Persona Pack is deliberately keyless. That design choice is the whole safety story. The pack definition tells BUZZ what a persona is supposed to be: canonical slug, prompt, runtime metadata, pack-local MCP wiring. It does not mint a public key, start a runtime, or join a channel. The owner does that later. So I keep two nouns separate: the definition and the runtime identity.
The ten canonical persona slugs are exact and boring on purpose:
| Role | Persona slug | What I expect it to own |
|---|---|---|
| Orchestrator | sd-orchestrator | Method sequence, handoffs, visible phase-gate preparation |
| Researcher | sd-researcher | Evidence register and provenance-grounded asks |
| Synthesizer | sd-synthesizer | Insight, affinity, and persona work |
| Mapper | sd-mapper | Journey maps, blueprints, and ecosystem structures |
| Ideator | sd-ideator | HMWs, concepts, and opportunity framing |
| Prototyper | sd-prototyper | Prototype plans, walkthroughs, and tests |
| Measurer | sd-measurer | KPI chains and service measurement logic |
| Critic | sd-critic | Evidence-cited review rows and veto posture |
| Presenter | sd-presenter | Report/export assembly from final artifacts only |
| Librarian | sd-librarian | Canon, provenance, and method drift checks |
Those slugs are not mention targets. They are pack definitions. A live runtime becomes real only when the owner materializes it in BUZZ, assigns a provider/model/runtime host, and gets an identity-backed public key. The honest join key is runtime.persona_id. Each runtime should expose exactly one runtime.persona_id that matches exactly one pack definition. Then, and only then, I can say that a runtime public key represents sd-mapper or sd-critic.
This is where people get sloppy. They see a green card in the UI labeled “Maya” and assume the orchestrator exists, is healthy, is the only orchestrator instance, and is ready to receive a mention in the current channel. None of that follows. A definition may exist with no runtime. A runtime may exist but be inactive. Two runtime instances may report the same persona id. A healthy runtime may still be absent from the channel I care about. A slug is stable metadata. A pubkey is the actual routing surface.
The pack itself stays safely small in scope. It installs through BUZZ's native Persona Pack workflow. It carries relative MCP wiring so the installed pack can point to mcp/bin/server.mjs without hardcoding a developer machine path. What it never does is write BUZZ application storage directly, create identities, or bind members to a channel. That is owner-authorized runtime work outside the emitted pack. Good. The compiler should emit definitions, not side effects.
The Safe Sequence, End to End
I run BUZZ engagements in one safe sequence and I do not improvise it. First I install and validate the Persona Pack through the native BUZZ workflow. Second I owner-materialize the ten runtimes. Third I create the private engagement channel. Fourth I add the audited runtime pubkeys as members. Fifth I verify the membership and resolve display names from the exact pubkeys. Sixth I post the human kickoff and send a scoped mention to one chosen runtime. Seventh I persist any actual ASD records through the pack-local MCP or the CLI, not through chat. Eighth I link those records from Canvas. Ninth I stop at the human phase gate.
The first live BUZZ commands are straightforward. I use buzz channels list to inspect existing sd/ channels, then create a dedicated private stream for the engagement and add the roster by pubkey:
buzz channels list
buzz channels create \
--name sd/<engagement> \
--type stream --visibility private \
--description "Fictional ASD engagement; synthetic evidence only."
buzz channels add-member --channel <channel-uuid> --pubkey <runtime-pubkey>
buzz channels add-member --channel <channel-uuid> --pubkey <runtime-pubkey>
# repeat until the audited roster is complete
buzz channels members --channel <channel-uuid>
buzz users get --pubkey <runtime-pubkey>Notice what is absent. There is no “deploy team” shortcut in my acceptance story. There is no broad “forceNewInstance” wave. There is no trust fall from slug to mention target. I want the exact runtime public key in hand because the public key is what the relay will later attach to the response.
After the roster is in place, I post a kickoff that states the fictional boundary, the project id, the authority boundary, and the stop condition. Then I send the first exact runtime mention. The content can include a friendly display-name reference, but the automation contract rides on --mention <pubkey>:
buzz messages send --channel <channel-uuid> \
--mention <orchestrator-runtime-pubkey> \
--content "@sd-orchestrator — start Discover coordination for project <project-id>; use only the cited evidence IDs; ask researcher and mapper for bounded work; stop for my framing decision before Define."That sentence does three jobs. It names one exact addressee. It constrains the evidence boundary. It gives the runtime a stop line. BUZZ works best when every ask is auditable against a clear deliverable and a clear refusal condition. A vague prompt may still produce prose. It will not produce proof.
Once replies start landing, I separate collaboration from persistence on purpose. If Maya replies with a workplan and Liam replies with evidence ids, those replies are claims until the ids resolve in the workspace. If I want a project, evidence, artifact, review, handoff, or gate record, I create it through the pack-local MCP or the CLI. BUZZ stays the coordination surface. The ASD store stays the record. That cut is the whole method.
Fail-Closed Identity Audit
Before I trust any mention target, I run the read-only identity audit. The command is simple:
node scripts/buzz-live-identity-audit.mjs \
--input ./audit.json \
--channel-id <channel-uuid> \
--output ./identity-audit.jsonThe important part is what happens inside. The audit joins Persona Pack definitions, live runtimes, optional channel membership, and optional mention targets. It checks for missing definitions, missing runtimes, multiple definitions, multiple runtime instances for one persona, missing runtime pubkeys, runtime error states, inactive runtimes, missing channel membership, ambiguous mention targets, and mismatched mention recipients. It reports a safe remediation plan instead of silently choosing for me.
The script is aggressively bounded. It is read-only and plan-only. It never loads credentials. It never fetches a private key. It never contacts BUZZ on its own. It has no mutation surface. It rejects --apply and --confirm outright. Its only allowed BUZZ CLI inspection step, when membership checking is in scope, is buzz channels members --channel <channel-uuid>. That is it.
persona_id. That refusal is a feature. The moment the tool auto-chooses among ambiguous runtimes, your later mention-to-reply claim becomes soft and editorial instead of operational.I like this audit because it refuses to flatter me. If the runtime is missing, it says missing. If the membership is absent, it says absent. If a proposed mention's pubkey does not match the chosen runtime pubkey, it fails. In other words, it behaves like the rest of ASD: fail closed, generate a repair plan, and stop short of mutation.
Case: Metrovale OneRecovery (Observed Slice)
Article 37 is the right place to learn restraint. The Metrovale OneRecovery material is valuable precisely because it is bounded. In the observed private channel sd/metrovale-one-recovery, the owner first saw the ten ASD personas and then added general Claude and Codex advisory identities, producing a 13-member roster. The slice includes a genuine orchestrator reply, relay-confirmed orchestrator-to-researcher and orchestrator-to-mapper handoffs, synthetic researcher and mapper content, a Canvas artifact index, and advisory Claude/Codex storyboard responses. The human Discover gate remained blocked.
The boundary list is explicit and I keep it explicit here. Metrovale does not prove MCP project-store persistence, durable artifact ids, a visible Critic verdict, ACP spawn or transport, host execution, reload, recovery, cleanup, phase completion, a presenter reply, or a rendered deck. The generated offline Canvas document for Article 37 is useful, but it is verified offline rather than BUZZ-live. That distinction matters. If I blur it, I teach the wrong lesson.
There is a second lesson in Metrovale. A Canvas row can honestly show observed, draft, or planned without pretending everything is finished. In the captured register, the project charter and authority were observed in BUZZ, the starter evidence and a journey-map outline were observed responses, the advisory storyboard existed only as BUZZ replies with no deck file, and the research plan, service blueprint, measurement plan, review-veto log, executive report, and knowledge register remained planned. That is honest operational publishing.
Lab: Aster Grove Makerspace Live Run
Article 39 is the chapter's live lab because it closes the loop cleanly. The client is fictional. The BUZZ lane is real. The tutorial proves what a full, bounded session looks like when I insist on ids, receipts, and phase discipline. Here is the condensed twelve-step run I want practitioners to copy.
- Create an isolated ASD project. In the article, the project id is
aster-grove-makerspace-6a8498ef. Isolation matters because it prevents one engagement from smearing ids into another. - Register synthetic evidence. Ten rows go in first: quotes, telemetry, and documents. Each one gets a SHA-256 id that later replies must cite.
- Write artifacts through the review gate. Stakeholder map, journey, KPI tree, and change plan are persisted through the store; the blueprint deliberately fails once, gets a Critic veto, then is remediated on the same artifact id.
- Create the private BUZZ channel and roster. The live channel is
sd/aster-grove-makerspacewith 13 members: owner, ten ASD runtimes, and two coding-agent advisors. - Post the owner kickoff. The kickoff states that the service is fictional, names the project id, states the human authority boundary, and keeps the channel from becoming an evidence register by accident.
- Mention the orchestrator by public key. Maya receives a scoped Discover coordination ask addressed to her runtime pubkey, rather than merely to her display name.
- Dispatch specialist work in parallel. Liam gets provenance checking. Kai gets failure-demand mapping. Their replies come back with evidence citations that can be checked against the store.
- Record the human gate in the ASD store first. The owner advances Discover to Define with approval receipt
ag-gate-001only after factcheck is green. - Ask the Critic to verify the persisted review history. Marcus checks the blueprint veto/remediation chain against the store and cites the actual review-veto-log and evidence row.
- Render the Canvas index from the workspace. The channel index is generated from store records, not typed in the channel.
- Set the Canvas live, get it back, and verify the round trip. The retrieved document matches the generated one modulo a trailing newline, and verify passes all checks.
- Continue the loop without fabrication. Maya opens Define, Nadia resolves the synthesis method registry, Rowan sees only the Canvas and not the authoritative store, refuses to fabricate, and the session pauses honestly instead of inventing evidence.
That last step is my favorite because it shows the boundary holding under pressure. Rowan had enough information to bluff. He had the registry. He had the Canvas. He had context. He still declined to invent because he did not have the authoritative workspace. That is what an AI-native Service Design stack should do when access is partial.
asd phase-advance --projectId aster-grove-makerspace-6a8498ef \
--toPhase define --idempotencyKey astergrove-gate-discover-01 \
--approvalReceipt '{"receiptId":"ag-gate-001","approvedBy":"mehran","decision":"approve","rationale":"framing question selected from store-backed Discover outputs","approvedAt":"2026-08-23T07:40:00.000Z"}'The channel announcement comes after this store receipt exists. Never before. Agents prepare the decision. I authorize the phase move. That is not a culture preference. It is a protocol boundary.
The Critic step is just as important. Marcus does not wave through the blueprint because the conversation felt coherent. He checks the persisted review chain: the veto row, the cited evidence, the same-id remediation, and the final review state. Article 39 makes this concrete by using a deliberate defect in the blueprint lane name and then proving the repair on the same artifact id.
By the time the Aster Grove run reaches its freeze frame, the workspace shows 10 evidence rows, 11 artifacts, 1 typed handoff, and 10 planned kinds. Ten of the artifacts are final with Critic passes. One insight-set draft appears without a binding channel reply, so its authorship is left unresolved in the ledger instead of being guessed after the fact. That single choice tells you the chapter's whole ethic. Truth beats completeness theatre.
Canvas: The Shared Index
The BUZZ Canvas is one page per channel. I use it as the front door to the engagement, never as the store itself. The generator that keeps it honest is scripts/buzz-canvas-index.mjs. It renders from persisted workspace records, refuses dangling ids, accepts only registered planned kinds, and can later prove that the document survived a live set/get round trip on the relay.
The lifecycle is mechanical:
node scripts/buzz-canvas-index.mjs render \
--project-dir tmp/buzz39/projects/aster-grove-makerspace-6a8498ef \
--channel sd/aster-grove-makerspace \
--channel-id 361023a9-31cb-4b40-845f-19d64f7827ee \
--fictional \
--planned research-plan --planned interview-guide --planned opportunity-matrix \
--planned hmw-set --planned concept-set --planned prototype-plan \
--planned walkthrough-script --planned storyboard --planned test-report \
--planned recovery-playbook \
--out articles/39/canvas
buzz canvas set --channel 361023a9-31cb-4b40-845f-19d64f7827ee --content - \
< articles/39/canvas/aster-grove-makerspace.md
buzz canvas get --channel 361023a9-31cb-4b40-845f-19d64f7827ee \
> retrieved-canvas.md
node scripts/buzz-canvas-index.mjs verify \
--canvas-dir articles/39/canvas \
--project-dir tmp/buzz39/projects/aster-grove-makerspace-6a8498ef \
--retrieved retrieved-canvas.md --fictionalThe render step writes a document with twelve contract sections. The verify step checks five things: content hash, presence of all twelve sections, stale-link resolution, relay round trip, and drift against a fresh render. It is a proper integrity loop, not a screenshot ritual.
| Canvas section | Why it exists |
|---|---|
| 1. Charter and data boundary | States project identity and reminds readers that the Canvas is navigation, not proof. |
| 2. Phase and human-gate state | Shows the current phase and any approval receipts on record. |
| 3. Participant roster | Lists durable participation from records, not mere channel presence. |
| 4. Evidence register | Indexes evidence sources and ids. |
| 5. Artifact register | Lists kind, id, status, owner, review state, and evidence coverage. |
| 6. Critic findings and remediation | Replays review-veto logs and same-id remediation state. |
| 7. Typed handoff queue | Shows persisted handoff records and unsupported spawn boundaries. |
| 8. Decisions, assumptions, and risks | Makes blocked gates, missing artifacts, and open drafts visible. |
| 9. Prototypes and tests | Indexes prototype-plan, walkthrough-script, storyboard, and test-report artifacts. |
| 10. KPI ownership | Shows who owns measurement artifacts and targets. |
| 11. Final report and recovery playbook | Indexes delivery-side artifacts without inventing them. |
| 12. Index integrity | Carries the round-trip content hash and verification posture. |
The planned rows matter more than they first appear. In Aster Grove and Metrovale, planned kinds such as research-plan, interview-guide, opportunity-matrix, hmw-set, concept-set, prototype-plan, walkthrough-script, storyboard, test-report, and recovery-playbook can appear as planned only because they are registered kinds. If I try to smuggle an unregistered label into the index, render fails closed. If I leave a stale id in place, verify fails closed. That is exactly how an index should behave.
Boundaries: What BUZZ Does Not Prove
Let me end bluntly. BUZZ does not prove workspace persistence unless the cited project, evidence, artifact, review, handoff, or gate ids resolve in the ASD store. It does not prove ACP transport because ACP is record-only in ASD and host-agent-spawn is unsupported. It does not prove that a runtime public key maps to the correct persona without the read-only audit. It does not prove that a phase advanced because only a human approval receipt can do that. It does not prove that a rendered deck, prototype, or report exists simply because someone discussed one in-channel.
That is not a limitation to hide. It is the operating model. BUZZ is the collaboration lane on the open agent network. The ASD workspace is the persistent rigor engine. ACP records typed coordination and stops there. Human gates stay human. Once I accept those boundaries, BUZZ becomes incredibly powerful: exact role mentions, visible handoffs, live attribution, a shared Canvas front door, and an honest record of what the team knew at each moment. Once I ignore those boundaries, it becomes another chat transcript pretending to be a project system.
So the practical rule is simple. Mention by pubkey. Verify by audit. Persist through MCP or CLI. Index through Canvas. Advance only with a human receipt. Everything else is commentary.