> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cortex-labs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Build and test a workflow with Kato

> Use your own brief to build a document-review workflow, inspect its graph and test each outcome.

Build a workflow for your own document-review task with Kato. Choose its name before sending the request. The workflow receives your short task brief, drafts a briefing document and asks one named person to review it. Only approval leads to output publication. You will finish with a checked, tested workflow draft.

## 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.

<Steps>
  <Step title="Describe the workflow">
    [Open Kato](/getting-started/navigate-the-app#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.
  </Step>

  <Step title="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:

    ```text theme={null}
    Entry → LLM → Create artefact → Verdict (approve) → Publish → Published completion
                                     ├─ reject → Rejected completion
                                     └─ requestChanges → Changes needed completion
    ```

    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.
  </Step>

  <Step title="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](/workflow-builder/building-blocks) for the block and edge rules.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Check the result

You should have an unpublished workflow definition draft and three inspected test runs. Approval publishes the exact reviewed test output; rejection and requested changes do not. Testing a draft method and publishing an output are distinct operations.

When you are ready to make the method reusable, follow [Publish the method separately](/workflow-builder/build-reviewed-report#publish-the-method-separately). Publish the selected definition version explicitly, then inspect a run before adding triggers. A full recurring brief needs its own collection, evidence cutoff, review and reporting design.

For direct authoring, use [Build and test a workflow in Forge](/workflow-builder/build-reviewed-report). [How workflow runs retain evidence and decisions](/workflow-builder/how-workflow-runs-work) explains the execution record.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.