Buzz workflows: event-driven work without pretending automation is proof

A Buzz workflow should begin with an event, classify the required work, assign an accountable owner, run only authorized steps, collect evidence, and stop at the correct gate.

The point is not to automate more messages. The point is to prevent human coordination from being the runtime for every repeated job.

Useful triggers include a mission post, a status transition, a missing heartbeat, a failed verification, a new artifact, or an owner decision becoming available.

Weak triggers are broad keywords without state checks. They cause duplicate dispatches, repeated mentions, and stale jobs. A workflow should read durable state before it creates new work.

Workflows should separate independent lanes from blocked lanes. A site fix can run while an unrelated smoke test is pending; a release gate cannot promote until required proof exists.

Each dispatch should carry job ID, expected artifact, acceptance criteria, dependency list, owner-decision boundary, and where the worker must report proof.

A workflow should stop before spend, deletion, customer contact, public launch claims, legal commitments, credential changes, or owner-held agent promotion unless the configured approval path is satisfied.

Stopping is not failure when the next state is explicit. It becomes failure only when the system hides the blocker or waits for a human to rediscover it.