Control Systems for AI Work

01 — Executive Thesis

AI does not remove control problems. It relocates them.

Before AI, weak work systems usually failed in visible ways: unclear instructions, missing source material, inconsistent handoff, poor review, or no ownership.

After AI enters the workflow, those failures often become faster, prettier, and harder to diagnose.

The model produces. The automation routes. The dashboard updates. The operator feels progress.

Then the real question arrives:

Who decided this was correct?

A control system for AI work defines the boundary between assistance and authority. It specifies what AI may access, what it may generate, what it may change, what must be reviewed, what must be logged, and what must remain under human judgment.

The durable operator is not the one who refuses AI. The durable operator is the one who can supervise it without being quietly absorbed by it.

---

02 — Signal Map

Primary Signal

AI-assisted work is shifting from generation to execution, which makes control design a professional skill.

Expansion Focus

This report focuses on AI work boundaries, authority levels, stop rules, source authority, output control, review gates, and operator-intent preservation.

System Impact

Without control design, AI workflows create:

• unreviewed decisions
• unclear source use
• prompt drift
• output inconsistency
• false confidence
• automation mistakes
• operator dependency
• difficult recovery after errors

Related Vectors

Human-in-the-loop architecture, auditable workflows, drift and failure management, AI context engineering, file systems, automation design, operational governance, remote work resilience.

---

03 — 13 Field Hacks

1. Label the autonomy level. Manual, assisted, semi-automated, automated with review, automated with escalation.
2. Separate suggestion from action. Drafting is not sending. Summarizing is not deciding. Recommending is not approving.
3. Define source authority. Tell the system what is official, draft, background, outdated, or prohibited.
4. Use stop rules for exploration. Research ends at a decision, shortlist, test, draft, or timed checkpoint.
5. Put review before irreversible action. Sending, deleting, paying, publishing, committing, and escalating need gates.
6. Give every workflow an owner. “The automation did it” is not accountability.
7. Preserve decision receipts. Record source, output, reviewer, date, and next step.
8. Control tool access. The AI should not have more access than the task requires.
9. Use bounded prompts. Audience, task, source, constraint, output format, and review criteria are not decorations.
10. Create a kill switch. If you cannot stop it quickly, you do not control it.
11. Design for wrong outputs. Assume failure will happen. Decide what catches it.
12. Review control weekly. AI workflows drift when nobody inspects the edges.
13. Avoid invisible authority. If the AI effectively decides, say so and add governance.

---

04 — Core System Thesis

AI control has six layers:

1. Intent Layer — what the operator is trying to accomplish.
2. Authority Layer — what AI may access, infer, generate, or change.
3. Context Layer — what sources and constraints shape the work.
4. Action Layer — what the workflow does with the output.
5. Review Layer — where human judgment enters.
6. Record Layer — what evidence remains for audit, improvement, or recovery.

Most AI workflow failures happen when these layers are collapsed.

The operator gives a vague request, the AI uses unclear context, the output enters a workflow, nobody reviews it carefully, and no useful record remains.

That is not leverage.

That is fog with a progress bar.

---

05 — Operating Architecture

Control Principle

If an AI workflow cannot answer these seven questions, it is not controlled. It is merely operational.

---

06 — Control Models

Model A — Manual AI Assist

Use case: drafting, brainstorming, summarizing, outlining.

AI role: suggestion engine.

Human role: full decision authority.

Control need: source labels, output review, no automatic action.

Best for low-risk knowledge work.

Model B — AI-Assisted Workflow

Use case: recurring research, internal memos, content briefs, synthesis.

AI role: structured work assistant.

Human role: review and approval.

Control need: source packet, task brief, output schema, review checklist.

Best for repeatable work where output quality matters.

Model C — Semi-Automated AI Workflow

Use case: ticket triage, reporting, routing, draft generation, data classification.

AI role: generates or routes structured outputs.

Human role: approves exceptions and samples outputs.

Control need: approval gates, exception rules, logs, periodic audits.

Best for workflows with clear patterns and moderate risk.

Model D — Automated with Exception Escalation

Use case: bounded operational workflows with clear failure states.

AI role: executes within defined constraints.

Human role: handles exceptions and reviews logs.

Control need: strong guardrails, observability, rollback path, escalation owner.

Best only when the workflow is mature and failure consequences are understood.

Model E — Prohibited / Not Yet Ready

Use case: high-impact or unclear decisions.

AI role: no direct authority.

Human role: full control.

Control need: use AI only for support, not decision or execution.

Best for legal, medical, financial, immigration, employment, sensitive identity, and irreversible actions unless expert governance is in place.

---

07 — Real-World Application: Build an AI Work Control Card

The project introduced by this report is an AI Work Control Card.

It is a one-page control packet for any recurring AI workflow.

AI WORK CONTROL CARD

WORKFLOW NAME:
OBJECTIVE:
OWNER:
AI ROLE:
AUTONOMY LEVEL:
SOURCE MATERIAL:
PROHIBITED SOURCES:
OUTPUT TYPE:
OUTPUT SCHEMA:
ACTION AFTER OUTPUT:
REVIEW REQUIRED:
ESCALATION PATH:
KILL SWITCH:
LOG / RECORD LOCATION:
REVIEW CADENCE:

Application Rule

Every recurring AI workflow should have a control card before it has automation.

A workflow without a control card is allowed to exist as an experiment. It is not allowed to become infrastructure.

The card should also include an exploration boundary when the workflow involves research, comparison, synthesis, or open-ended investigation. Otherwise, “gather more context” becomes an unlicensed delay mechanism.

---

08 — Implementation Plan

Day 1 — Choose one AI workflow

Pick a recurring workflow where AI is already being used or likely to be used.

Examples:

• research summary
• content brief
• client memo
• support triage
• meeting synthesis
• application tailoring
• project status update
• document comparison

Day 2 — Define operator intent

Write the objective in one sentence.

Bad:

Use AI to help with research.

Better:

Use AI to produce a source-grounded shortlist of three options with tradeoffs and a recommendation.

Day 3 — Set autonomy level

Choose one:

• manual
• assisted
• semi-automated
• automated with review
• automated with exception escalation
• prohibited / not ready

Day 4 — Define authority boundaries

Specify what AI can:

• read
• summarize
• infer
• draft
• classify
• recommend
• change
• send
• delete
• publish

Most workflows should start with read/summarize/draft only.

Day 5 — Build the review gate

Decide:

• who reviews
• what they check
• what triggers escalation
• what cannot proceed without approval

Day 6 — Add recordkeeping

Create a decision receipt:

• input/source
• output
• reviewer
• date
• decision
• next action

Day 7 — Run the control test

Ask:

1. Can I explain the workflow?
2. Can I inspect the output path?
3. Can I stop it?
4. Can I recover from failure?
5. Can I improve it next time?

If the answer is no, do not scale the workflow.

---

09 — 6 Overhyped / Avoid

“AI can just handle that.”

This sentence has destroyed more clarity than most tools ever created.

“The model is good enough now.”

Maybe. The workflow still needs source control, review, and consequences.

“We’ll add governance later.”

Later is where broken systems go to become expensive.

“It’s only a draft.”

Drafts become source material when people are tired.

“The automation saves time.”

So does skipping inspection on a bridge. Briefly.

“The human is technically still in the loop.”

A human rubber-stamping outputs they do not understand is not control. It is theater with a checkbox.

---

10 — Anti-Patterns & Risks

---

11 — Templates & Systems

AI Work Control Card

WORKFLOW NAME:
OBJECTIVE:
OWNER:
AI ROLE:
AUTONOMY LEVEL:
SOURCE MATERIAL:
PROHIBITED SOURCES:
OUTPUT TYPE:
OUTPUT SCHEMA:
ACTION AFTER OUTPUT:
REVIEW REQUIRED:
ESCALATION PATH:
KILL SWITCH:
LOG / RECORD LOCATION:
REVIEW CADENCE:

Autonomy Label Set

LEVEL 0 — Manual
LEVEL 1 — AI-assisted
LEVEL 2 — AI-generated, human reviewed
LEVEL 3 — AI-routed, human exception review
LEVEL 4 — AI-executed with monitoring
LEVEL 5 — Prohibited / not approved

Five-Question Control Test

1. What starts the workflow?
2. What can AI access or change?
3. What output is produced?
4. Who reviews it before consequence?
5. What happens when it fails?

Decision Receipt

workflow_name:
date:
source_material:
ai_output:
human_reviewer:
decision:
changes_made:
approved_for_action:
next_review:

Exploration Stop Rule

EXPLORATION OBJECTIVE:
TIME BOX:
OUTPUT REQUIRED:
DECISION POINT:
STOP CONDITION:
NEXT ACTION:

---

12 — Project Layer

Project

Build an AI Work Control System for one recurring workflow.

Minimum Viable Output

• one AI Work Control Card
• autonomy label
• source authority notes
• review gate
• decision receipt
• stop rule
• weekly review reminder

Upgraded Output

• prompt version log
• source manifest
• output schema
• exception escalation flow
• automation kill switch
• dashboard or audit checklist
• monthly control review
• workflow owner map

Success Criteria

The workflow is controlled when:

• the operator can explain it
• the owner is named
• sources are labeled
• AI authority is bounded
• review exists before consequence
• a record remains
• failure has a path

---

13 — Mobility / Continuity Layer

AI control matters more when the operator is mobile, tired, traveling, interrupted, working across time zones, or relying on cloud systems under imperfect conditions.

A portable control layer should include:

• offline access to control cards
• clear owner/reviewer notes
• decision receipts stored in exportable format
• kill-switch instructions available without hunting
• no irreversible AI actions while in unstable access conditions
• source packets available offline when possible
• documented fallback workflow if AI or automation is unavailable

The travel rule is simple:

If you would not trust the workflow from an airport, do not call it controlled.

---

14 — Technical Insert

AI Workflow Control Registry

This simple Python script creates a local control registry for AI workflows and flags workflows missing required control fields.

from pathlib import Path
import csv

REGISTRY = Path("ai_workflow_control_registry.csv")

required_fields = [
    "workflow_name",
    "owner",
    "autonomy_level",
    "source_material",
    "output_type",
    "review_required",
    "kill_switch",
    "log_location"
]

sample_workflows = [
    {
        "workflow_name": "weekly_research_summary",
        "owner": "operator",
        "autonomy_level": "LEVEL 2 — AI-generated, human reviewed",
        "source_material": "source_packet_weekly_research",
        "output_type": "decision_memo",
        "review_required": "yes",
        "kill_switch": "manual only; no auto-send",
        "log_location": "logs/weekly_research_summary"
    }
]

def validate_workflow(workflow):
    missing = []
    for field in required_fields:
        if not workflow.get(field):
            missing.append(field)
    return missing

with REGISTRY.open("w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=required_fields + ["status"])
    writer.writeheader()

    for workflow in sample_workflows:
        missing = validate_workflow(workflow)
        workflow["status"] = "OK" if not missing else f"MISSING: {', '.join(missing)}"
        writer.writerow(workflow)

print(f"Control registry written to {REGISTRY}")

Manual / No-Code Alternative

Use a spreadsheet with the following columns:

workflow_name
owner
autonomy_level
source_material
output_type
review_required
kill_switch
log_location
last_reviewed
status

Review weekly and mark each workflow:

• OK
• needs review
• missing control
• not approved for automation

Power-User Alternative

Use Airtable, Notion database, GitHub issues, or a lightweight internal dashboard to track:

• AI workflow inventory
• autonomy level
• approved tools
• source packets
• output schemas
• review owners
• failure logs
• prompt versions
• monthly audit status

For advanced setups, connect the registry to automation logs so every AI-assisted workflow leaves a traceable record.

---

15 — Maintenance Model

Weekly

• Review one active AI workflow
• check control card completeness
• inspect one recent output
• verify owner and review gate
• update decision receipt

Monthly

• audit autonomy levels
• review tool permissions
• check prompt/version drift
• confirm kill switches
• review exceptions and failures
• retire workflows that no longer need automation

Quarterly

• review all AI workflows
• reclassify autonomy levels
• archive unused prompts
• update source authority rules
• test recovery process
• refresh operator control standards

Before Scaling

Do not scale an AI workflow until:

• the control card is complete
• the failure mode is understood
• logs exist
• review is assigned
• rollback or stop procedure exists
• the operator can explain the system without opening seven tabs and making a face

---

16 — Closing Assessment

AI work becomes dangerous when convenience is mistaken for control.

The serious operator does not need to reject AI, agents, or automation. The serious operator needs to define where authority lives.

Control is the ability to explain, inspect, stop, review, recover, and improve the workflow.

Anything less is not a system.

It is a suggestion engine wearing the operator’s jacket.

---

17 — Source Notes

This report is grounded in the control concerns raised by VANGUARD SIGNAL — Issue 003 and aligns with current AI governance and agent-design guidance. NIST’s AI Risk Management Framework centers AI risk work around governance, mapping, measuring, and managing. OpenAI’s practical agent-building guidance emphasizes use-case selection, agent logic, orchestration, guardrails, and predictable operation. Gartner’s public agentic AI guidance warns that agentic AI raises complexity, integration, observability, governance, security, technical debt, and unpredictable-decision risks.

Primary references:

• NIST AI Risk Management Framework
• OpenAI, *A Practical Guide to Building AI Agents*
• Gartner, agentic AI oversight / vendor guidance