“Add approval before publishing” sounds specific until a coding agent has to decide what approval means. Does it cover a draft ID or exact text? What happens if the draft changes? Can a double-click create two releases? A diagram becomes useful context when the brief connects its participants and steps to decisions the implementation must preserve.
This lesson turns a proposed sequence into a bounded implementation brief. The example is a fictional release-note agent that reads merged changes, generates drafts, and publishes through a gateway. You can use the method with your chosen coding assistant; tool access and integration capabilities must be checked separately.
State the behavioral change
In the starting design, the maintainer chooses a draft and requests publication. The server loads that draft's latest text. Between viewing and publishing, another generation can replace the current revision. The desired change is precise: publication must use an immutable snapshot of the revision the maintainer approved.
Our example chooses the following policy. The server checks that the submitted revision is current when it accepts approval and captures the snapshot. An edit committed before that check makes the approval stale. An edit after acceptance creates a newer draft but does not rewrite the already accepted publication operation. A product with different expectations may require cancellation or reapproval; decide that explicitly.
Write this policy beside the sequence. An arrow labelled “approve” cannot carry all of it on its own.
Connect model steps to code responsibilities
The proposed sequence has five important steps: submit draft ID and revision, authorize the maintainer, atomically capture the approved snapshot and reserve a publication operation, publish that snapshot, then store the receipt. Reuse the existing console, runner, store, and gateway participants. The change adds behavior; it does not automatically justify new services.
Describe which code responsibility owns each check. The console displays the revision. The authenticated server path checks authority. The store enforces the revision comparison and reservation in one transaction. The gateway owns the external request and its result classification. The LLM does not choose whether the approval is valid.
Keep a short mapping from model labels to discovered symbols. An illustrative mapping could be accept publication → publication_handler, reserve snapshot → draft_store, and send release → publication_gateway. These are role names, not paths in the Unograph repository. Verify the real locations before authorizing edits.
Live model · Sequence view
Locate the approval and publication boundaries
The target publication sequence separates server authorization, atomic snapshot reservation, asynchronous delivery, and receipt storage. The accepted operation binds an approved revision to a release target.
Explore scenarios in this model
- Architecture view
- G - Generate a draft
- P - Publish an approved snapshot
- S - Reject a stale first approval
- D - Repeat or conflict with publication intent
- U - Remote write with a lost response
- R - Reconcile the original outcome in background
These links open the same public model in a selected view. They do not change its source.
Open this viewer on its own ↗ if the frame is unavailable. The explanation remains readable without the viewer.
Exploration is local to your viewer. Reload or Reset view returns to the source layout.
Write a brief the agent can check
A useful brief contains the objective, evidence, scope, invariants, and observable checks. Here is a complete task you can adapt after replacing the model and repository references:
Implement revision-bound publication for the release-note agent. Use the agreed publication sequence and the inspected repository commit as the baseline. First confirm the handler, store transaction, gateway, and relevant tests; report any mismatch with the model.
Accept a draft ID and expected revision from an authenticated maintainer. Check publication authority on the server. In one store transaction, compare the current revision, capture an immutable snapshot, and reserve one publication operation for the tenant, draft, revision, and release target. Reject a stale first approval without contacting the release host. Later draft edits must not change the reserved payload.
Repeated submissions for that operation must return its existing state. A reused request identity with a different payload must be rejected. Retain a stable downstream operation identity if the release host supports the required idempotency contract. A timeout after sending must remain unresolved until reconciliation establishes the outcome; do not silently start a new publication.
Limit edits to the discovered publication path, store migration, gateway result handling, and focused tests. Preserve the generation prompt and repository read tools. Do not add a provider or change deployment configuration. If the existing host cannot support safe recovery, stop the retry portion and describe the missing capability.
Return the diff, migration considerations, checks actually run with their results, unverified assumptions, and any model change needed. Leave final code review to the maintainer.
The operation identity here represents one business intent across repeated requests, here one intended publication. Do not make the agent infer it from identical text: two intentional releases can contain the same content. AWS's discussion of idempotent APIs explains why explicit request identity and payload validation matter. The example's exact key and approval policy are design choices, not requirements imposed by that source.
Make acceptance observable
Replace “works correctly” with checks that can distinguish an acceptable patch from a plausible one.
- Approving revision 7 publishes revision 7's captured text even if revision 8 is created afterward.
- If revision 8 already exists when the first approval for revision 7 is checked, the request is rejected and the gateway is not called.
- Two concurrent submissions for the same approved revision and target reserve one operation; only its claiming worker dispatches it.
- A sent request whose response is lost is shown as unresolved, with no new publication created by a blind retry.
These checks cross different boundaries. A handler unit test can show that a rejected request never calls a fake gateway. It cannot establish that a database transaction is atomic or that a real provider deduplicates requests. Name the required integration checks as well.
Choose the smallest useful brief
A detailed brief takes time to prepare and can overconstrain implementation. Specify decisions that affect externally visible behavior, ownership, and recovery. Let the implementer choose routine helper names and local decomposition. If the task extracts a Strategy for ordering pickups, specify that eligibility and capacity stay with the session while the ordering algorithm may vary. If the task spans an uncertain provider contract, investigate that uncertainty before asking for a complete patch.
The model is a shared reference for the task. It does not grant repository access or make an assistant understand a particular diagram format. Provide a textual description of the critical sequence alongside any approved model link, then confirm what the chosen tool can actually read.
Try it in Unograph
In Unograph, use the publication sequence to locate the last step before the external write. Make the approved revision and captured snapshot explicit in that flow. Write one acceptance check for that boundary and attach the agreed model reference to your task using your team's normal handoff process.
For the evidence-gathering step, read Understand an AI Agent's Code with Architecture and Sequence Diagrams. Continue with Model Failure Paths Before an AI Agent Implements Them to test the brief against stale state, duplication, and uncertain outcomes. Both belong to the release-note agent learning path.