Separate Operator Intent From System Execution

Thesis: Risky automation is easier to validate and audit when the operator declares the desired outcome and the system produces a plan before making changes.

Declare operator intent as an explicit artifact

Treat the operator’s goal as data. An intent object is the single source of truth for what the operator wants (not how to do it). The object should contain: a clear desired state, constraints (time window, blast radius, scope), an identity for who requested it, and acceptance criteria. When the operator declares intent as data you get predictable validation, small blast radius, and the ability to rehearse without side effects.

Tradeoffs: intent objects increase upfront work for simple changes, but they reduce cognitive load for risky or multi-step operations. They are wrong when the task is a one-off trivial edit; their cost outweighs the benefit.

Produce a plan and validation phase before touching systems

Systems must translate intent into a concrete, reviewable plan. The plan and validation phase takes the intent object and produces a sequence of operations, a change window, a risk statement, and a set of dry-run validation checks. The plan answers these questions:

• What adapters will run and in what order? (dependencies and rollback points)
• What will each step change and how will success be measured? (assertions)
• What is the estimated blast radius and which systems are allowed to fail? (scoping)

Validation during the plan phase means running non-destructive checks: schema validation, simulated API calls, a read-only rehearsal against a mirror, or synthetic assertions that prove preconditions. Treat the validation phase as a contract: if it fails, the plan is rejected and the requester must update the intent object or accept higher risk.

Failure modes: incomplete validation can produce plausible but wrong plans; explicit acceptance criteria mitigate this. The plan-and-validate approach costs time and human attention, so tune it to the risk profile of each intent.

Keep execution adapters small and permissioned

An execution adapter is the bounded component that turns a planned step into concrete actions against a downstream system. Adapters should be:

• Small, audited, and single-purpose
• Least-privilege: only the credentials and scopes needed for their task
• Idempotent where possible, or carry a clear compensating action

Adapters also report structured results, not freeform logs: success/failure, affected objects, observed state, and a unique plan-step id. This makes automated reconciliation and automated rollback practical.

Costs: more adapters means more integration work. But the isolation reduces blast radius and simplifies testing: test an adapter in isolation with fake downstreams. When to skip adapters: when an operation is entirely local and trivial; otherwise prefer the adapter pattern.

Make audit and rollback evidence first-class

Every plan run must emit audit and rollback evidence. Audit evidence is an immutable record linking intent object → plan → executed steps → results. Include hashes of the intent object and plan so reviewers can prove the executed plan matches the declared intent.

Rollback evidence is a description of how to revert each step, plus an automated rollback script or adapter. Record both the state before the change and the assertions used to verify success. If a step is non-reversible, mark it and require higher-level approvals.

Practical format for evidence:

• Intent ID, requester, timestamp
• Plan ID, plan steps, adapters referenced
• For each step: pre-state snapshot, post-state snapshot, adapter result, duration
• Rollback step or compensating transaction reference

This evidence is the thing auditors and postmortems read. Without it you get a narrative instead of a reproducible investigation.

Acceptance criteria, dry runs, and guardrails

Acceptance criteria belong on the intent object. They are machine-evaluable statements like “no more than 2% traffic loss” or “all nodes return healthy within 3 minutes”. Use dry runs to validate the plan against these criteria. Dry runs should:

• Execute non-destructive checks
• Produce the same plan logs and evidence formats as a real run
• Be repeatable and tied to the intent ID

Guardrails enforce limits: rate limits, time windows, required approvals for risky steps, and automatic abort on unexpected side effects. Guardrails are the last line of defense against a plan that passes validation but behaves poorly in production.

A reusable checklist for intent-driven automation

Validation & Execution Checklist (use this every time):

1. Intent object completed: desired state, constraints, requester identity, acceptance criteria.
2. Produce plan: ordered steps, adapters, pre/post assertions, rollback actions.
3. Run validation phase: schema checks, dry-run, simulated adapter runs, and acceptance criteria evaluation.
4. Approval gate: automated or human approval if validation passes and risk exceeds threshold.
5. Execute adapters: run steps in bounded batches, collect structured results per step.
6. Emit audit and rollback evidence: immutable records and snapshot hashes.
7. Monitor against acceptance criteria during and after execution; trigger rollback if breached.
8. Post-run review: capture lessons, update adapters or acceptance criteria if needed.

Use this checklist as a lightweight policy. For low-risk changes compress or skip items; for high-risk work all items should be non-skippable.

When this approach is wrong and how to scale it

This pattern is overkill for throwaway edits or tiny, immediate fixes where the cost of building an intent object and plan exceeds the operational cost. It also hits diminishing returns when changes are so frequent that the plan-and-validate cycle slows delivery unacceptably.

To scale: automate intent creation (templates), pre-validate common patterns, and increase the reuse of adapters. Make the plan-and-validation tooling fast and visible. Finally, tune the acceptance criteria to the business need: more stringent where safety matters, laxer where speed matters.

Takeaway

Designing systems that separate operator intent from execution reduces surprise and makes automation auditable. An intent object, a plan and validation phase, execution adapters, and robust audit and rollback evidence are the minimal components for safe automation. Use the provided checklist as operational acceptance criteria; treat non-reversible steps as first-class risk items requiring explicit acknowledgment. For implementation help or a quick review of your intent schema, send a short note to /contact.