Workflow walkthroughs
See how inputs, tools, review and results fit together.
Walk through a document intake workflow
This walkthrough uses a synthetic document and describes an example architecture. It does not submit a file or run a paid tool. A document arrives Imagine that your team receives a form and needs five fields entered into an existing record. Today someone opens the file, copies the values and checks the result. The proposed workflow has six steps: | Step | What happens | What must be checked | | --- | --- | --- | | 1. Intake | Accept a permitted file and identify the request. | File type, size, account access and duplicates. | | 2. Store | Keep the source at the agreed destination. | Access controls, retention and deletion. | | 3. Extract | Read text and propose the required fields. | Missing pages, unreadable text and uncertain values. | | 4. Review | A person compares the proposed record with the source. | Corrections and a clear approve-or-return decision. | | 5. Deliver | Write the approved result to the destination. | Correct record, permissions and duplicate prevention. | | 6. Record | Keep the outcome and any usage receipt. | Successful work, failures, retries and the agreed charging rule. | Try the smallest meaningful example Write down five expected values for a synthetic document. Run the proposed implementation only after its preview is available, compare the result, correct it, and check the destination. Then test an unreadable page and the same request twice. The aim is to learn how the whole workflow behaves, including the exception path. Decide what stays with a person A person may review every result at first. Once you have evidence of how the workflow performs, you can decide whether particular low-risk cases need a different review policy. The policy belongs in the scope; it should not be guessed by an assistant. Bring the results, open questions and required integrations into the solution brief.
Connect tools without losing the thread
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 to capture the decisions that a diagram alone cannot show.