Sketch a Process in Plain Text Before Automating It

The AZET team disclosure: AZET operates azet.io, and we write as its maker team. A hypothetical club booklet moving between a contributor and an editor provides this illustrative guide for reference exploration, not a demonstrated AZET feature.

As of 2026-10-12

“Send the page to the editor, then put it in the booklet” hides a question: what happens when the page has no title? A straight arrow makes the process look settled even though the next step depends on missing information.

Give the diagram a small vocabulary

For this hypothetical exercise, a casual drawing club accepts one page from each contributor for a shared booklet. The page contains an invented drawing and a title. We will follow one submission, not the entire booklet production schedule.

Define the notation before drawing. Square brackets contain actions or states. Angle brackets contain questions. An arrow means “this can happen next.” Text beside a branch states the condition that permits it.

The distinction between an action and a state needs words, too. “Editor checks title” is an action. “Waiting for contributor revision” is a state. An arrow entering a waiting state does not imply that anything automatically leaves it.

Hypothetical diagram legend
[Owner: verb + object] = action
[Waiting: named reason] = paused state
<question?> = decision with labelled exits
--> = next step when its condition is satisfied
[End: reason] = this submission path stops here

Draw the ordinary path and its interruption

Start with the shortest complete path, then add the missing title case. Keep the decision in the editor's lane because the editor performs the check in our invented process.

[Contributor: submit page]
  --> [Editor: check title]
  --> <Title present?>
      yes --> [Editor: accept page]
          --> [Editor: add page to draft booklet]
          --> [End: page included in draft]
      no  --> [Editor: request a title]
          --> [Waiting: contributor response]
              revised page received --> [Editor: check title]
              contributor withdraws  --> [End: withdrawn]

Notice what the loop returns to: the title check, not acceptance. A revision still needs to pass the condition. Returning directly to “add page” would silently remove the reason for the branch.

The sketch deliberately says “draft booklet.” Inclusion in a draft does not mean publication, printing, or distribution. A diagram becomes misleading when its final state implies more completion than its actions establish.

Write down what crosses a handoff

An arrow between owners deserves a little more detail than an arrow inside one person's work. Here, the contributor hands over a page and the editor receives it. Specify the object and the receiving condition.

For the hypothetical submission, use this companion note:

Handoff H1
Sender: contributor
Receiver: editor
Object: one readable page; title may be missing
Receipt condition: editor can open and identify the page
If unreadable: waiting for a replacement page
Ownership while waiting: editor tracks the pending submission

The main diagram now needs an earlier readability check if unreadable pages are in scope. That is a useful discovery, not a reason to hide the note. Add that branch in the next version, or explicitly limit the current sketch to readable pages.

For this exercise, we choose the second option and label the scope “readable submissions only.” A visible boundary is easier to review than an unspoken assumption.

Find the arrow that says too much

A plausible failure is drawing “request title --> check title” without the waiting state. Read literally, it says the editor can check a revised title immediately after requesting it. The contributor's action has vanished.

Another failure is leaving two exits from a decision unlabelled. Readers cannot tell whether both steps happen, one is chosen, or either is optional. If two actions must both finish, say so and identify the point where they rejoin. Do not rely on their position on the page.

Here is a hypothetical AI review prompt for the sketch:

Read this diagram using its supplied legend. For every arrow, explain the event or condition that allows movement. Flag missing branch labels, owner changes without a named object, loops without a recheck, and endings that imply unshown work. Suggest wording changes only. Do not add tools or integrations.

Walk a token through the drawing

Use three invented submission cards: one titled page, one untitled page later revised, and one untitled page later withdrawn. Move each card through exactly the available arrows.

For every move, name the current owner, the available input, and the exit condition. If you must narrate an extra event absent from the drawing, either add it or record it as outside scope.

Then review a fourth card that never receives a reply. It should remain waiting. If you want a deadline or closure rule, decide it explicitly rather than allowing the diagram to invent one.

FAQ

Should every tiny action get a box?

Only when it changes ownership, state, input, or a decision relevant to the sketch. Too many boxes can bury the handoff you are trying to understand.

Can one box have several owners?

It can, but describe their separate responsibilities. “Club handles revision” leaves uncertainty about who notices a reply and who checks it. Name those roles when they matter.

Is a diagram an automation specification?

Not by itself. This sketch explains intended movement and unresolved conditions. It says nothing about permissions, execution, or whether any application can perform the actions.

The maker introduction we published on October 3 described the AI assistant's email waitlist. Visit azet.io for that waitlist and current notices if you want to follow the project. This article supplies no fresh availability check.