Skip to content
TUN.

Resources

Start with the essentials.

Introductory Engineering guidance produced for this website: a way in, a review checklist, and the vocabulary used across these pages.

01Getting started

Five steps into one workflow

This is introductory Engineering guidance produced for this website. It is deliberately narrow: one workflow, examined properly, teaches more than a survey of many.

  1. 01

    Select one workflow

    Choose a single workflow that already matters and already has an owner. Breadth comes later; a real workflow exposes real constraints.

  2. 02

    Write the intent

    State the outcome the workflow should produce, the constraints it must respect, and the acceptance criteria that would let someone say it worked.

  3. 03

    Map authority and dependencies

    List the actors, the data each step touches, the tools it calls, and the decisions that require a person. Mark where authority actually lives.

  4. 04

    Test one consequential step

    Pick the step with the largest external consequence. Exercise the normal path, a failure, and an unknown outcome before anything else.

  5. 05

    Decide evidence and recovery

    Name what you retain as proof, and what you will do when the step fails or its outcome cannot be determined. Write down what cannot be undone.

02Review checklist

Engineering review checklist

Questions to ask before an intelligent workflow takes consequential action. The download contains exactly these questions.

Download checklist (Markdown)

Intent and ownership

  • Is the intended outcome written down in terms a non-author can evaluate?
  • Are the acceptance criteria specific enough to fail?
  • Is there a named owner accountable for the workflow in production?
  • Is it clear which outcomes are out of scope?

Data boundaries

  • Which data sources does the workflow read, and who owns them?
  • Is any sensitive data crossing a boundary it should not?
  • How fresh must context be for the result to remain valid?
  • Is retrieved content treated as untrusted input rather than instruction?

Tool permissions and approval scope

  • What is each tool permitted to do, and what is it explicitly refused?
  • Are permissions enforced by the application independently of model behaviour?
  • Which actions require human approval before execution?
  • Does an approval cover one specific action, or an open-ended class of actions?

Execution evidence and verification

  • Is approval recorded separately from execution?
  • What evidence proves the action occurred, beyond a returned status?
  • Is verification independent of the component that performed the action?
  • Is an unverified outcome displayed as unverified?

Duplicates, failure, and recovery

  • Is the action idempotent, and if not, how are duplicates prevented?
  • What happens when the outcome is unknown rather than failed?
  • Which failures can be retried, compensated, rolled back, or only escalated?
  • Which effects are irreversible, and is that stated to the people involved?

Monitoring and change

  • Which signals would show the workflow drifting from its intent?
  • Who investigates an incident, and with what access?
  • How is a change reviewed before it reaches production?
  • Is the evidence record itself reviewed periodically for usefulness?

03Glossary

Working vocabulary

Intent
The outcome a person wants, stated with enough constraint and criteria that success and failure can be told apart.
Agent
A component that plans and takes steps toward a goal using tools. Its proposals are not permissions.
Tool
A bounded capability a system may call, with defined inputs, outputs, scope, and failure modes.
Authority
The right to make a particular decision or cause a particular effect. Held by people and enforced by systems.
Approval
A recorded human decision permitting a specific action. Distinct from executing that action.
Evidence
Retained records that let someone reconstruct what was decided, what happened, and on what basis.
Verification
Independent confirmation of an outcome. A step completing is not verification of its effect.
Recovery
What can be done after a failure: retry, compensate, roll back, or escalate. Not every effect can be reversed.