Tools are easier to replace when the handoff between them is clear.

## Describe each connection

For every step, name the information it receives, the result it returns, the identity allowed to use it, and what counts as completion.

| Connection | Example agreement |
| --- | --- |
| Intake to extraction | A request ID, an approved source reference and the required fields. |
| Extraction to review | Proposed values, confidence or uncertainty information, and the source reference. |
| Review to destination | The approved values, reviewer decision and destination record. |
| Completed work to billing | A validated usage event under the agreed charging rule. |

The business meaning matters more than a particular diagram format. “Approved intake record” is clearer than an arrow with no explanation.

## Make failures visible

Decide how an operator sees failed work, which failures can be retried, and how duplicate requests are recognized. A retry should not silently create a second business record or a second charge.

## Keep a clear owner

Your existing customer account system should keep owning customer access. Your approved commercial process should keep owning prices and entitlements. Connecting a chat or another tool should not create an unrelated second account or billing record.

## Use a diagram as a draft

A conversation can describe steps in text, a table, JSON or Mermaid. Those are useful planning artifacts. A synchronized visual editor is a separate product feature; a code block in chat is not a working canvas.

Use the [brief template](/hc/productpat/articles/productpat-en-solution-brief) to capture the decisions that a diagram alone cannot show.