What should a human review in an AI-generated diagram?

Start with provenance and the critical path: whether every claim traces to source, whether trust and traffic cross the right boundaries, whether failure and recovery are explicit, and whether the diagram answers its named engineering decision.

Why require a human correction?

A correction tests whether the reviewer understands the system and whether the artifact can carry that understanding forward. Moving a box for aesthetics does not test the model; fixing readiness, trust, ownership, or recovery does.

How do I know the next agent update preserved the review?

Name the element ids and meaning that must remain, request a targeted update to the same diagram, then re-check the critical path in the browser. Do not infer preservation merely because the canvas still looks similar.

Does this page contain customer results?

No. The OAuth and Kubernetes materials are internally produced illustrative fixtures. Participant-derived diagrams, screenshots, quotes, or outcomes would require written permission and would be labelled separately.

AI diagram review workflow · two failure modes

Review what the diagram means before polishing how it looks

A plausible canvas can still hide a broken trust boundary or send traffic to the wrong workload. Bound the source, name the critical path, make one correction that changes the model, and verify that the next agent update preserves it before the diagram reaches a teammate.

Scope

Named evidence

Path

One decision

Human

Model correction

Agent

Preserved update

Team

Owned questions

Editable OAuth PKCE sequence diagram used to demonstrate source boundaries, trust-path review, human correction, and preserved agent follow-up — Faithful SVG render from the editable v2 spec. The review makes state validation and verifier handling explicit before a same-canvas failure-path update.Open full-size SVG

Second failure mode

Use the same rubric when the domain changes

OAuth review asks whether state, verifier, token exchange, and failure handling cross the right trust boundaries. Kubernetes review asks whether readiness, liveness, Service selection, and rollback have the right operational meaning. A reusable review process must expose both kinds of error without pretending they are the same system.

Kubernetes rollout review used alongside the OAuth sequence to compare human corrections for readiness, traffic eligibility, and rollback — The Kubernetes proof catches a different failure: readiness must control Service eligibility while liveness remains a restart signal.

Human review rubric

SOURCE BOUNDARY
[ ] Every node and edge traces to named source or an explicitly standard relationship.
[ ] Unsupported services, vendors, and data flows are removed or labelled uncertain.

CRITICAL PATH
[ ] The diagram answers one named engineering decision.
[ ] Trust, traffic, readiness, failure, and recovery transitions are explicit where relevant.

HUMAN CORRECTION
[ ] A reviewer changes the system model, not only layout or color.
[ ] The correction and its reason are recorded beside the canvas.

PRESERVED UPDATE
[ ] The follow-up targets the same diagram and names what must survive.
[ ] Stable element ids and the reviewed critical path are checked after the update.

TEAM HANDOFF
[ ] Unresolved questions have an owner or a pinned comment.
[ ] Invite editors for changes; use a public link only for read-only review.

Human review is valuable when it changes an engineering conclusion. In the OAuth proof, the reviewer protects state and PKCE boundaries. In the Kubernetes proof, the reviewer connects readiness to Service eligibility. The domain changes; the review discipline does not.

Product boundary: Both diagrams are internally produced source fixtures, not participant results, customer screenshots, or testimonials. They demonstrate a review method but do not prove that the method improves team outcomes. Any participant-derived source, quote, image, or result requires written publication permission.

Failure comparison

One review method, two critical paths

The table does not score the diagrams against each other. It shows what each review question means in two domains so a technical lead can reuse the method without flattening domain expertise.

Swipe to compare

Job	OAuth PKCE review	Kubernetes rollout review
Source boundary	Use only the supplied PKCE flow note; do not invent provider endpoints, token contents, or implementation behavior.	Use only Deployment, Service, and Ingress YAML plus standard controller ownership; do not invent cloud or mesh services.
Critical path	State must be created and validated before code exchange; the verifier stays server-side and failure creates no session.	Readiness controls Service endpoint eligibility; Ingress reaches only Ready pods; liveness has a separate restart role.
Human correction	Move state validation to the trust boundary and annotate verifier and token exposure constraints.	Add the missing readiness-to-Service dependency and separate pod-template inputs from live traffic.
Preserved update	Add explicit state-mismatch rejection without moving the reviewed trust boundary or removing its note.	Add the rollback decision without moving the reviewed input stage or deleting the readiness edge.
Team handoff	Assign unresolved security questions in pinned comments and invite the reviewer who can change the flow.	Assign rollout ownership, invite the application or platform editor, and use a public link only for read-only review.

Stop when the evidence fails

If a node or edge cannot trace to the allowed source, remove it, mark it uncertain, or expand the source scope explicitly. Visual plausibility is not a substitute for provenance.

Share when the correction survives

Run the targeted follow-up on the same diagram, re-check the named critical path, then hand unresolved questions to a person through comments or an invite.

Reproduce it

Copy setup

Name the decision and allowed evidence

Write the engineering question the diagram must answer, list the only source the agent may use, and forbid unsupported services or behavior. A diagram without a bounded decision is difficult to review honestly.

Connect the agent with review-safe scope

Mint a read + write Personal Access Token and connect @excaliwow/mcp. Keep publish and delete disabled while the diagram is still under review.

MCP client config

{
  "mcpServers": {
    "excaliwow": {
      "command": "npx",
      "args": ["-y", "@excaliwow/mcp"],
      "env": {
        "EXCALIWOW_TOKEN": "excw_pat_…"
      }
    }
  }
}

Correct, preserve, then hand off

Apply the rubric above in order. Make a model-changing correction in the browser, request a targeted update to the same diagram, re-check the correction, and only then invite an editor or attach a read-only share link.

Human review

Change what the agent misunderstood

Highlight state validation as the trust-boundary decision and change the failure node to a strong red treatment.
Add a reviewer note that the verifier stays server-side and tokens never appear in the browser URL.

Same-canvas follow-up

Send the correction back

Update the same diagram in place: add the explicit state-mismatch rejection and secure cookie flags without moving the human-highlighted trust boundary.

Review the critical path, not the pixels

Every shown node and edge traces to the named source or an explicitly standard relationship.
OAuth state validation occurs before exchange, and the verifier remains server-side.
Kubernetes readiness gates Service endpoints while liveness remains a separate restart signal.
The named human correction survives the same-diagram agent follow-up.
Unresolved questions become a pinned comment or named owner before an invite or share handoff.

Common questions

What should a human review in an AI-generated diagram?: Start with provenance and the critical path: whether every claim traces to source, whether trust and traffic cross the right boundaries, whether failure and recovery are explicit, and whether the diagram answers its named engineering decision.
Why require a human correction?: A correction tests whether the reviewer understands the system and whether the artifact can carry that understanding forward. Moving a box for aesthetics does not test the model; fixing readiness, trust, ownership, or recovery does.
How do I know the next agent update preserved the review?: Name the element ids and meaning that must remain, request a targeted update to the same diagram, then re-check the critical path in the browser. Do not infer preservation merely because the canvas still looks similar.
Does this page contain customer results?: No. The OAuth and Kubernetes materials are internally produced illustrative fixtures. Participant-derived diagrams, screenshots, quotes, or outcomes would require written permission and would be labelled separately.

Review one critical path with a person

Start free—no credit card. First 10,000 verified accounts keep the core workspace free; 3 diagrams to start and earn more capacity.

Start free