A trace you can use
Record stage, version, outcome and failure category. Decide which payloads are necessary for diagnosis and how they are protected and retained.
ENGINEERING / DESIGN NOTE 001
Useful AI. Explicit control.
Use rules for what can be specified. Use AI for language work that benefits from interpretation. Make the boundary between preparation and action visible.
01 / REFERENCE ARCHITECTURE
A workflow before an autonomous agent.
- 01Validate the input
- 02Retrieve approved context
- 03Interpret or prepare
- 04Check the output
- 05Ask the authorised person
- 06Act and record
INPUT → PREPARATION → AUTHORITY → ACTION
- 01 / RULES
Validate the input
Check required fields, allowed types and source permissions. Reject or hold incomplete work.
- 02 / SOURCES
Retrieve approved context
Use a bounded source set. Keep document versions and references attached to the result.
- 03 / AI-ASSISTED
Interpret or prepare
Extract, classify, summarise or draft where language work adds value. Do not invent missing facts.
- 04 / RULES
Check the output
Validate the schema and business constraints. Calculate numbers with deterministic logic.
- 05 / HUMAN
Ask the authorised person
Show what changed, the supporting evidence and the action approval will permit.
- 06 / CONTROLLED ACTION
Act and record
Perform only the approved action. Record the outcome and handle failure without duplicate effects.
Reference architecture for a scoped implementation. Each stage has a failure path; a missing prerequisite holds the item for its owner rather than continuing by assumption.
02 / STRUCTURED INTERFACES
A useful answer has a contract.
Illustrative interface, not a live API. The source references, proposed output and permission to act travel separately. A model response cannot grant itself approval.
Preparation is not permission
A source-linked draft can still be wrong. Validation, review and action authority remain separate steps.
{
"request_id": "SYN-EXAMPLE-01",
"source_refs": [
"approved-source:v3:section-2"
],
"proposed_action": "prepare_draft",
"result_status": "needs_review",
"approval": {
"required": true,
"granted": false
},
"external_action_allowed": false
}03 / ACCEPTANCE CASES
Test more than the happy path.
- Expected input
The agreed output is produced and can be traced to its inputs.
- Ambiguous result
Hold for review; uncertainty does not silently become approval.
- Missing information
Request the missing source or field and preserve the incomplete state.
- Incorrect input
Reject invalid types, values or formats before a downstream action.
- Unavailable integration
Record failure and use an agreed retry or escalation path.
- Unsafe request
Refuse actions outside the permitted workflow and data scope.
- Duplicate event
Prevent a retry from repeating a consequential external action.
- Source or instruction change
Re-run relevant acceptance cases before releasing the new version.
Reference cases for a customer acceptance plan. The exact tests and evidence are agreed for each implementation.
04 / OPERATIONAL DESIGN
Someone has to run it tomorrow.
A named owner
Someone must own exceptions, access changes and the decision to resume. A queue without an accountable person is not a recovery plan.
A controlled change
Re-test affected cases when a model, instruction, source or integration changes. Keep a previous working version and an explicit recovery procedure.
05 / EVIDENCE YOU CAN INSPECT
Try the boundaries yourself.
The Workflow Studio demonstrates local approval stops, resets, exceptions, structured data and event traces. Customer integrations, retries and operational monitoring require their own implementation and acceptance evidence.