Auteur playbook · Internal tool or automation

Automate the repetition. Keep authority visible.

Internal software creates leverage by changing how work is performed. Its quality depends on permissions, explanation, approval, escalation, audit, and recovery—not merely time saved.

Complete build process

Five stages from manual work to governed assistance.

Begin with the decision and its consequence. Automation depth should follow evidence and reversibility, not technical capability.

01 · FRAME

Map the work and authority

Observe the actual workflow, exceptions, judgment, handoffs, data sensitivity, and cost of a wrong action.

Work

  • Shadow the people doing the task
  • Separate recommendation, approval, and execution
  • Identify exceptions, abuse, compliance, and escalation paths

Artifacts

  • Operational decision map
  • Role and permission model
  • Automation-risk ledger

Exit when: the accountable person, permissible automation, and non-automatable judgments are explicit.

02 · DIRECT

Define the assistance boundary

Specify inputs, recommendation, reasoning, confidence, approval, execution, audit, correction, and escalation.

Work

  • Set role-based access and data minimization
  • Define low-, medium-, and high-consequence paths
  • Choose human-in-the-loop points and override behavior

Artifacts

  • Automation-boundary brief
  • Decision and event schema
  • Acceptance and safety gates

Exit when: every automated action has authority, evidence, override, and audit requirements.

03 · DELIVER

Start with suggestion and approval

Deliver one complete workflow with the lowest proportionate autonomy and an explicit feedback loop.

Sequence

  • Read-only observation or shadow mode
  • Suggestion with explanation
  • Human approval and governed execution
  • Audit event and correction capture

Guardrails

  • Least-privilege credentials
  • Idempotent actions
  • Rate and scope limits
  • Kill switch and manual fallback

Exit when: one real task improves without hiding responsibility or making failure irrecoverable.

04 · VERIFY

Test decisions, permissions, and exceptions

Evaluate normal work and the cases where the system must defer, escalate, reject, or stop.

Evidence

  • Representative and adversarial task set
  • Permission and cross-role isolation tests
  • Audit completeness and tamper review
  • Failure, retry, duplicate, and rollback tests

Human review

  • Can operators understand and challenge suggestions?
  • Does confidence create automation bias?
  • Are escalation and manual fallback practical?

Exit when: the system acts only inside its approved authority and produces enough evidence to reconstruct every material action.

05 · LEARN

Compare leverage with new risk

Measure time and quality without ignoring overrides, missed exceptions, escalation burden, and operator trust.

Monitor

  • Acceptance, correction, override, escalation, and error
  • Time saved and time shifted into review
  • Performance by task, role, and consequence

Decide

  • Keep suggestion-only
  • Expand authority for proven low-risk cases
  • Reduce or remove automation where evidence is weak

Repeat when: the workflow, people, policy, data, or consequence changes.

Worked example

AI-assisted support triage without invisible decisions.

The vague request is “automate ticket routing.” The useful slice makes one recommendation visible and reviewable.

  1. 01

    Observe

    Map how agents recognize category, urgency, customer risk, and exceptions.

  2. 02

    Suggest

    Show category, priority, reason, confidence, and the evidence used.

  3. 03

    Approve

    Require an agent to confirm or correct before routing.

  4. 04

    Record

    Store the suggestion, decision, correction, actor, and resulting action.

  5. 05

    Escalate

    Send sensitive or uncertain cases to the right human queue.

  6. 06

    Learn

    Use correction patterns to revise rules before considering more autonomy.

Result: measurable assistance with visible accountability—not an opaque routing bot.

Definition of done

Operational quality needs three controls.

Every material action should be authorized, understandable, and reconstructable.

Authority

  • Roles and permissions match responsibility
  • Automation stays inside explicit limits
  • High-consequence actions require approval
  • Credentials have least privilege

Understanding

  • Reasons and source evidence are visible
  • Uncertainty is not disguised
  • Correction and override are practical
  • Escalation reaches an accountable person

Recovery

  • Actions are idempotent and auditable
  • Partial failure is detectable
  • Manual fallback and kill switch work
  • Events reconcile with external systems
When consequences rise

Add system-level traceability and readiness gates.

The System Integrity overlay connects product intent, feature layers, evidence, release state, recovery, and operational activation.

Open System Integrity →