Skip to content
TUN.

Patterns

Engineering patterns

Illustrative approaches to making intelligent systems understandable, controllable, and observable.

All example data on this page is fictional.

01Define what may happen before it happens.

Approval before action

A system can draft and publish an update on a person's behalf. Publishing reaches an audience outside the team, so the consequential step is the send, not the draft.

  1. Ask
  2. Think
  3. Propose
  4. Approve
  5. Act
  6. Verify
  7. Learn

Proposed flow

  1. 01Ask — a person states the goal and the boundaries.
  2. 02Think — the system assembles context, records its assumptions, and writes a concise rationale.
  3. 03Propose — the exact action, destination, and consequence are shown before any control to approve.
  4. 04Approve — a person decides. Approval is a recorded decision, not an execution.
  5. 05Act — execution happens as a separate, explicit step.
  6. 06Verify — the outcome is confirmed independently of the call returning.
  7. 07Learn — findings update the intent brief and the controls, not the permissions.

“Think” means recorded context, assumptions, and a concise rationale — not a purported transcript of hidden reasoning.

Human control

  • The approver sees destination, message, and consequence on the same screen as the decision.
  • Approval and execution are distinct actions; neither triggers the other automatically.
  • Rejection ends the flow before any external effect.

Evidence to retain

  • Who approved, what exactly was approved, and when.
  • The proposal as approved, not a later edited version.
  • The verification result, including 'unknown'.

Failure considerations

  • An approval control that only looks authoritative while the underlying permission is unenforced.
  • Treating a returned success code as proof the recipient received anything.
  • Retrying an unknown outcome and duplicating an external action.

Simulation — publishing a status update

Choose a scenario, then advance each step yourself. Approval does not execute, and execution does not verify.

Interactive simulation. No messages are sent, no external systems are connected, and no real authorization is performed.

Scenario — select before starting

Proposed action — fictional example data

Action
Publish project status update
Destination
#project-northfield (fictional team channel)
Message
Northfield integration: context service is live in staging. Approval routing is still pending review, so no production traffic yet. Next checkpoint Thursday.
Consequence
The message becomes visible to everyone in that channel. Publishing cannot be unsent; a correction would be a second message.

Status

Awaiting approval

Simulated record

No steps taken yet. Approval alone will not execute anything.

02Separate source material from interpretation.

Evidence before an answer

A reader asks a question that the system answers from internal documents. The useful answer distinguishes what was found from what was inferred.

Proposed flow

  1. 01Identify the sources consulted, including their owner and date.
  2. 02Extract the passages that bear on the question, unaltered.
  3. 03State the limitations: what the sources do not cover.
  4. 04Synthesise an answer, marked as interpretation.
  5. 05Keep extraction and synthesis visually and structurally distinct.

Human control

  • The reader can see the extracted material without accepting the synthesis.
  • Low-coverage answers are presented as low coverage rather than confident prose.
  • A person can mark a source as stale or out of scope.

Evidence to retain

  • Source identity and ownership.
  • Freshness: when the source was last reviewed.
  • Coverage gaps acknowledged in the answer.

Failure considerations

  • Fabricated citations that have the shape of research without the substance.
  • Confident synthesis built on a single stale document.
  • Collapsing extraction and interpretation into one undifferentiated block of text.

03Detect failures and understand recovery limits.

Observe and recover

A step in an automated workflow fails, or its outcome cannot be determined. What the system may safely do next depends on the kind of action involved.

Proposed flow

  1. 01Detect: a signal shows the step did not complete as expected.
  2. 02Classify: failed before effect, failed after effect, or outcome unknown.
  3. 03Choose a response: retry, compensate, roll back, or hand to a person.
  4. 04Record the decision and its reasoning.
  5. 05Close the loop by confirming the final state, not the attempted one.

Human control

  • Unknown outcomes stop automatic progress and surface to a person.
  • Compensation and rollback are explicit, reviewable operations.
  • Escalation has a named owner, not a queue nobody reads.

Evidence to retain

  • The observed signal and the time it was observed.
  • The classification and who or what made it.
  • The final confirmed state of the external system.

Failure considerations

  • Retrying a non-idempotent external action and sending it twice.
  • Calling a rollback complete when the external effect was never reversible.
  • Monitoring that reports the workflow finished while the outcome remains unverified.

Four responses, with different limits

  • RetryAttempt the same action again. Safe only when the action is idempotent or the failure is known to have occurred before any effect.
  • CompensatePerform a second action that offsets the first — a correction notice, a refund, a follow-up message. The original effect still happened.
  • Roll backReturn a system to its prior state. Realistic for internal state; rarely available for external sends, payments, or third-party writes.
  • Manual interventionHand the case to a named person with the context required to decide. The correct answer when the state is genuinely unknown.

These examples are explanatory. No live integrations are involved, and no claim of universal reversibility is intended.