Before you begin
You need permission to author and test workflows in Forge, permitted models, and a test workspace in which you can execute the workflow and create artefacts. Choose one reviewer who can update that workspace and has clearance for the subject. Use an appropriate test workspace. Draft workflow tests execute their configured steps, including output publication on an approval path. Keep outputs clearly labelled as test material and leave external delivery, collection and schedules out of this exercise. Prepare a short brief from your own material that the selected providers and reviewer may receive. Adapt this structure:Purpose: [what the document should support]. Audience: [who will read it]. Scope: [topic and optional exact period]. Required sections: [sections]. Source facts: [the permitted facts or text I supply]. Unresolved questions: [known gaps]. Do not invent sources or findings.Replace each field with a short brief from your own task. Use a small input whose facts you can verify directly; no supplied brief or dataset is required.
1
Describe the workflow
Open Kato and send:
Help me build a draft workflow named [workflow name]. It takes a required text brief, drafts a briefing document in British English and saves a draft artefact. A reviewer I name decides whether to approve, reject or request changes. Publish the output only on approval. Reject and request changes should end with separate named outcomes. Do not add a revision loop, schedule or external delivery. Leave the workflow definition unpublished.Supply the test workspace and reviewer’s identifier. Ask Kato to show the proposed steps and confirm the supported models and inputs before authoring the draft.
2
Create and open the draft
Agree the proposed graph, then ask Kato to create it and open the workflow in Forge. Inspect the actual graph and selected configuration.The intended paths are:Check the required brief input, drafting instructions, document destination, named reviewer and Verdict decision route. Confirm all three exits are connected. A direct Create artefact → Publish connection would bypass the review requirement for this exercise.
3
Correct the graph before testing
Ask for a targeted change if the draft differs from the request. For example:
Keep the current draft. Connect requestChanges to the Changes needed completion without looping back to drafting. Check that only the approve exit reaches Publish.Reopen the changed graph and inspect it. A saved graph still needs valid inputs and connections before it can run. Use Workflow steps and connectors for the block and edge rules.
4
Test approval
Ask Kato to start a draft test in the named test workspace using your brief, or use Forge’s test controls. Inspect the run’s drafted text and saved subject before the reviewer decides.Have the named reviewer approve the exact draft through the review controls. If Kato performs a decision on your behalf, it needs your authority and a gated approval; a conversational “looks good” is not a recorded Verdict decision.Check that the approval path publishes that output version and reaches Published. Inspect the recorded reviewer, publication result and receipt. The briefing must preserve your brief’s scope and distinguish supplied facts from unverified claims.
5
Test rejection and requested changes
Start two separate draft tests with the same brief. Have the reviewer reject one and request changes on the other, including a comment.Verify Rejected and Changes needed complete on their respective paths, with no output publication from those paths. The saved drafts remain inspectable in run history. This graph records requested changes; it does not revise the document automatically.Inspect failures and actual usage. Correct the draft and repeat the affected cases before accepting it. Retrying a model step can repeat tool effects in a workflow that includes effectful tools.