That gives us a useful point-in-time question:

Does the system satisfy the specification right now?

But production systems don't stay still.

Traffic changes. Dependencies degrade. Certificates expire. Configuration is modified. Feature flags move. Data grows. People make manual changes. Agents take actions. Infrastructure is replaced. And so on.

A system can be conformant immediately after a deployment and stop being conformant hours or days later.

That's the problem I want to explore here.

Operational drift is the divergence between the operational specification and the state we continue to observe over time.

This is broader than configuration drift. Configuration drift asks whether infrastructure or configuration differs from a declared state.

Operational drift asks whether the system still behaves within the boundaries we intended, even if the configuration has not changed at all.

A service can have exactly the same configuration it had yesterday and still drift operationally because latency increased, error rate degraded, replica availability fell, a dependency became unhealthy, a policy is no longer being enforced, or evidence disappeared.

In this article, I’ll show you how to model operational drift, establish a conformance baseline, reevaluate a system over time, distinguish temporary noise from meaningful divergence, preserve drift evidence, classify severity, and decide when drift should trigger an alert, an investigation, or an automated response.

The central idea is this: conformance tells you whether reality matches intent at a point in time. Drift tells you whether that relationship is changing.

Prerequisites

You should be comfortable with:

• software architecture

• TypeScript or a similar language

• observability

• operational specifications

• evidence-based evaluation

• conformance

• basic monitoring concepts

You don't need a specific infrastructure platform.

The examples use a deployment scenario, but the same model applies to infrastructure, data pipelines, backup systems, access controls, AI agents, and other operational workflows.

Table of Contents

• Prerequisites

• What Operational Drift Means

• Operational Drift Isn't the Same as Configuration Drift

• Start with a Conformance Baseline

• Observe the Same Constraints Over Time

• Model Drift Explicitly

• Temporary Variation Isn't Always Drift

• Use Windows Instead of Single Samples

• Distinguish Drift from Missing Evidence

• Add Severity and Persistence

• Detect Directional Drift Before a Threshold Fails

• Preserve the Evidence Behind Drift

• A Reusable Drift Evaluator

• A Small End-to-End Example

• How Drift Detection Applies to Multiple Executors

• How Drift Detection Applies to AI Agents

• When Drift Should Trigger Action

• What Operational Drift Can't Tell You

• A Practical Drift Detection Workflow

• From Point-in-Time Conformance to Continuous Verification

• Conclusion

What Operational Drift Means

Suppose a deployment finishes at 10:00.

The operational specification says:

version = v42
available replicas >= 3
error rate <= 1%
p95 latency <= 400 ms

Immediately after deployment, the evidence says:

version = v42
available replicas = 3
error rate = 0.4%
p95 latency = 280 ms

The system is conformant.

Now suppose that at 14:00 the evidence says:

version = v42
available replicas = 3
error rate = 0.8%
p95 latency = 370 ms

The system is still conformant, but something has changed.

The error rate and latency are moving toward their limits.

At 16:00:

version = v42
available replicas = 3
error rate = 1.4%
p95 latency = 460 ms

Now the system is no longer conformant.

The operational specification didn't change. The executor did not necessarily run again. But reality moved.

That's operational drift.

A useful way to think about it is:

Specification
      ↓
Expected operational boundaries
      ↓
Observed state at T0
      ↓
Observed state at T1
      ↓
Observed state at T2
      ↓
Drift evaluation

The key idea is temporal: conformance is a snapshot, while drift is a relationship across snapshots.

Operational Drift Isn't the Same as Configuration Drift

Configuration drift is likely a familiar infrastructure concept to you.

By configuration drift, I mean a difference between the configuration or infrastructure state you declared and the state that actually exists in the environment.

For example:

desired replicas = 3
actual replicas = 2

Here, the declared state says the service should have three replicas, but the running environment only has two. The configuration and the actual state no longer match.

Or:

Terraform state != deployed infrastructure

In that case, infrastructure has changed outside the expected Terraform-managed state, or Terraform's record no longer matches what's actually deployed.

Those are both configuration drift because the mismatch is between a declared configuration and the environment that should reflect it.

That's useful, but it's narrower.

Operational drift can exist even when configuration is unchanged.

Consider this specification:

error rate <= 1%

The deployment configuration may still be identical to yesterday.

Yet traffic mix may have changed, a downstream API may have slowed down, a database index may have degraded, a certificate may be approaching expiration, or a queue backlog may have grown.

So:

configuration drift
=
declared configuration != actual configuration

while:

operational drift
=
observed operational state != intended operational boundaries

The two can overlap, but they're not the same thing.

That distinction matters because production failures are often behavioral before they are configurational.

Start with a Conformance Baseline

Drift needs a reference point. The easiest reference is a known conformant state.

For example:

type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

Suppose the system was evaluated after deployment:

const baseline: DeploymentEvidence = {
  version: "v42",
  replicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

and all required constraints passed.

That baseline gives you two useful things.

First, you know the system satisfied the specification at that point. And second, you have a concrete evidence snapshot against which later observations can be compared.

This doesn't mean later evidence must match the baseline exactly. That would be too strict.

It means later evidence can be evaluated in two ways:

Does it still satisfy the specification?

How is it changing relative to the baseline?

Those are different questions. Both are useful.

Observe the Same Constraints Over Time

Suppose you collect evidence every hour:

type TimedEvidence = {
  timestamp: string;
  evidence: DeploymentEvidence;
};

For example:

const observations: TimedEvidence[] = [
  {
    timestamp: "10:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.004,
      p95LatencyMs: 280,
    },
  },
  {
    timestamp: "12:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.006,
      p95LatencyMs: 320,
    },
  },
  {
    timestamp: "14:00",
    evidence: {
      version: "v42",
      replicas: 3,
      errorRate: 0.008,
      p95LatencyMs: 370,
    },
  },
];

Each observation can be evaluated against the same specification.

This gives you a conformance sequence:

10:00  PASS
12:00  PASS
14:00  PASS

At first glance, everything looks healthy. But a closer look reveals that the evidence is moving in one direction.

That's where drift detection becomes more interesting than ordinary threshold monitoring.

Model Drift Explicitly

A minimal drift result might look like this:

type DriftStatus =
  | "STABLE"
  | "DEGRADING"
  | "VIOLATED"
  | "UNKNOWN";

This gives the evaluator four explicit states. STABLE means the observed behavior remains within the expected range without meaningful deterioration. DEGRADING means the system is still within its allowed boundary but is moving in an unfavorable direction. VIOLATED means the current evidence has crossed the specification's limit. UNKNOWN means there's not enough evidence to classify the state safely.

Then:

type DriftResult = {
  constraint: string;
  status: DriftStatus;
  baseline?: number;
  current?: number;
  limit?: number;
};

DriftResult keeps the classification together with the values that explain it. baseline is the known-good reference, current is the latest observation, and limit is the boundary defined by the specification. Those fields are optional because some constraints may not be numeric or some evidence may be missing.

For latency:

baseline = 280
current = 370
limit = 400

This example says latency started from a known-good value of 280 ms, is now 370 ms, and must remain at or below 400 ms. The constraint hasn't failed, but the current value is much closer to the boundary.

That may be worth labeling:

DEGRADING

A drift model therefore doesn't replace conformance. It adds another dimension.

You can have:

conformance = PASS
drift = DEGRADING

That combination is often more actionable than either signal alone.

Temporary Variation Isn't Always Drift

Production systems are noisy.

One slow request doesn't mean the system is drifting. One missing sample doesn't mean the service is unhealthy. And one temporary spike doesn't necessarily justify intervention.

Suppose latency samples are:

280
290
420
285
295

The 420 sample crosses the limit. But the system immediately returns to normal.

Compare that with:

280
310
340
370
395

The second sequence may never cross the limit. But it shows persistent degradation.

That's why drift shouldn't be defined as:

current != baseline

or even:

one sample crossed threshold

Drift is more useful when it accounts for persistence and direction.

Use Windows Instead of Single Samples

A better approach is to evaluate observations over a window.

For example:

function average(
  values: number[]
): number {
  return (
    values.reduce(
      (sum, value) => sum + value,
      0
    ) / values.length
  );
}

Now suppose you evaluate the last five latency observations:

const latencyWindow = [
  300,
  320,
  340,
  360,
  380,
];

const currentAverage =
  average(latencyWindow);

This smooths temporary noise.

You can compare that window with an earlier window:

const baselineWindow = [
  270,
  275,
  280,
  285,
  290,
];

const baselineAverage =
  average(baselineWindow);

The earlier window gives you a short historical reference for typical behavior. The later window represents the more recent operating state. Comparing the two averages helps you see whether the whole signal has shifted, rather than reacting to one unusual sample.

Then calculate the change:

const delta =
  currentAverage -
  baselineAverage;

If baselineAverage is 280 ms and currentAverage is 340 ms, the delta is +60 ms. That doesn't mean the latency constraint has failed, but it does show that recent latency is materially worse than the earlier window.

This doesn't prove a problem exists, but it gives you a more stable signal.

The exact window size should come from the operational context.

A five-minute window may make sense for latency. A one-day window may make more sense for storage growth.

Distinguish Drift from Missing Evidence

This follows the same principle as conformance.

Suppose latency evidence disappears.

That's not the same as:

latency is stable

and it's not the same as:

latency violated the threshold

It is:

UNKNOWN

For example:

function evaluateLatencyDrift(
  baseline: number | undefined,
  current: number | undefined,
  limit: number
): DriftStatus {
  if (
    baseline === undefined ||
    current === undefined
  ) {
    return "UNKNOWN";
  }

  if (current > limit) {
    return "VIOLATED";
  }

  if (current > baseline) {
    return "DEGRADING";
  }

  return "STABLE";
}

The function evaluates the cases in a deliberate order. First, if either the baseline or the current observation is missing, it returns UNKNOWN because there's not enough evidence to make a safe comparison. If evidence exists and the current value is already above the allowed limit, it returns VIOLATED. If the value is still below the limit but worse than the baseline, it returns DEGRADING. Only when none of those conditions apply does it return STABLE.

This is still simplistic because any increase over the baseline becomes DEGRADING, even if the change is tiny or temporary. In a real system, you would usually combine this with tolerances, windows, persistence, or trend rules. But it preserves an important rule: absence of evidence isn't evidence of stability.

That becomes especially important when the observability system itself is degraded.

Add Severity and Persistence

Drift becomes more useful when you know how important the constraint is and how long the drift has persisted.

For example:

type DriftSeverity =
  | "INFO"
  | "WARNING"
  | "CRITICAL";

type DriftObservation = {
  constraint: string;
  status: DriftStatus;
  severity: DriftSeverity;
  consecutiveWindows: number;
};

Here, severity describes the operational impact of the affected constraint, while consecutiveWindows records how many observation windows have produced the same drift condition in a row. Keeping both matters because one brief warning is different from a warning that has persisted for eight consecutive windows, and a critical replica violation may deserve action even if it has only appeared twice.

Now you can distinguish:

latency
DEGRADING
WARNING
1 window

from:

latency
DEGRADING
WARNING
8 windows

and:

replicas
VIOLATED
CRITICAL
2 windows

The second signal is more persistent, but the third is more severe.

That helps determine what response is appropriate.

Detect Directional Drift Before a Threshold Fails

One of the most useful aspects of drift detection is recognizing directional movement.

Suppose the error-rate limit is:

1%

and observations are:

0.2%
0.4%
0.6%
0.8%

Nothing has failed yet, but the trend is clear.

A simple slope can capture that direction.

For example:

function slope(
  values: number[]
): number {
  if (values.length < 2) {
    return 0;
  }

  return (
    values[values.length - 1] -
    values[0]
  ) / (values.length - 1);
}

This helper looks at the first and last values in the series and divides their difference by the number of intervals between them. It's a deliberately simple trend indicator: a positive result means the metric increased across the window, a negative result means it decreased, and a value near zero means it stayed roughly flat.

Then:

const errorRates = [
  0.002,
  0.004,
  0.006,
  0.008,
];

const trend =
  slope(errorRates);

Here, the error rate rises from 0.002 to 0.008, so trend is positive. The code isn't trying to predict the future or perform full statistical analysis. It's only making the direction of change explicit so the system can notice sustained movement toward the 1% boundary before the boundary is actually crossed.

A positive trend doesn't automatically mean failure, but it tells you the system is moving toward the boundary.

This is where drift detection differs from basic alerting.

Basic threshold alert:

tell me when error rate > 1%

Drift detection:

tell me when error rate is persistently moving toward 1%

The second can give you time to investigate before the system becomes non-conformant.

Preserve the Evidence Behind Drift

A drift result should be explainable.

For example:

{
  "constraint": "error-rate",
  "status": "DEGRADING",
  "baseline": 0.004,
  "current": 0.008,
  "limit": 0.01,
  "window": "10m",
  "consecutiveWindows": 4,
  "observedAt": "2026-10-13T18:00:00Z"
}

This is better than:

drift detected

because someone can answer:

what changed?
compared with what?
how close are we to the limit?
how long has this been happening?
when was it observed?

That matters for debugging, as well as for auditability.

A Reusable Drift Evaluator

We can generalize the model.

First define a drift rule:

type DriftRule<T> = {
  name: string;
  severity: DriftSeverity;
  evaluate(
    baseline: T,
    current: T
  ): DriftStatus;
};

Then define a drift specification:

type DriftSpec<T> = {
  name: string;
  rules: DriftRule<T>[];
};

And an evaluator:

type DriftRuleResult = {
  name: string;
  status: DriftStatus;
  severity: DriftSeverity;
};

function evaluateDrift<T>(
  spec: DriftSpec<T>,
  baseline: T,
  current: T
): DriftRuleResult[] {
  return spec.rules.map(
    (rule) => ({
      name: rule.name,
      status:
        rule.evaluate(
          baseline,
          current
        ),
      severity:
        rule.severity,
    })
  );
}

The evaluator doesn't need to understand latency, error rate, replicas, or certificates.

Each rule owns its own comparison logic. That makes the engine reusable.

A Small End-to-End Example

Let’s create a drift specification for a deployment.

Start with evidence:

type DeploymentEvidence = {
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

Now define rules:

const driftRules:
  DriftRule<DeploymentEvidence>[] = [
    {
      name: "replicas",
      severity: "CRITICAL",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.replicas === undefined ||
          current.replicas === undefined
        ) {
          return "UNKNOWN";
        }

        if (current.replicas < 3) {
          return "VIOLATED";
        }

        if (
          current.replicas <
          baseline.replicas
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
    {
      name: "error-rate",
      severity: "CRITICAL",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.errorRate === undefined ||
          current.errorRate === undefined
        ) {
          return "UNKNOWN";
        }

        if (current.errorRate > 0.01) {
          return "VIOLATED";
        }

        if (
          current.errorRate >
          baseline.errorRate * 1.5
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
    {
      name: "latency",
      severity: "WARNING",
      evaluate: (
        baseline,
        current
      ) => {
        if (
          baseline.p95LatencyMs === undefined ||
          current.p95LatencyMs === undefined
        ) {
          return "UNKNOWN";
        }

        if (
          current.p95LatencyMs > 400
        ) {
          return "VIOLATED";
        }

        if (
          current.p95LatencyMs >
          baseline.p95LatencyMs * 1.25
        ) {
          return "DEGRADING";
        }

        return "STABLE";
      },
    },
  ];

Create the drift specification:

const driftSpec:
  DriftSpec<DeploymentEvidence> = {
    name: "orders-runtime-drift",
    rules: driftRules,
  };

Now define baseline and current evidence:

const baseline:
  DeploymentEvidence = {
    replicas: 3,
    errorRate: 0.004,
    p95LatencyMs: 280,
  };

const current:
  DeploymentEvidence = {
    replicas: 3,
    errorRate: 0.007,
    p95LatencyMs: 360,
  };

Evaluate:

const drift =
  evaluateDrift(
    driftSpec,
    baseline,
    current
  );

Possible output:

replicas     STABLE      CRITICAL
error-rate   DEGRADING   CRITICAL
latency      DEGRADING   WARNING

The system may still be conformant, but it's no longer operationally stable relative to its baseline.

That's valuable information.

How Drift Detection Applies to Multiple Executors

Suppose two executors both successfully deployed the same service.

Immediately after deployment:

Executor A → conformant
Executor B → conformant

That doesn't mean their long-term operational behavior is identical.

Over time:

Executor A
error rate stable
latency stable
replicas stable

Executor B
error rate rising
latency rising
replicas stable

Both executors satisfied the initial specification, but their downstream operational behavior is different.

Drift gives you another comparison dimension.

You can ask:

Which executor produces more stable outcomes?
Which one drifts more often?
Which one produces more unknown evidence?
Which one needs recovery more frequently?

This is especially useful when executor choice is dynamic.

How Drift Detection Applies to AI Agents

AI agents introduce another kind of variability.

An agent may produce different plans for the same objective.

For example:

Run 1:
scale
deploy
observe

Run 2:
deploy canary
observe
expand

Run 3:
create parallel environment
switch traffic

Each plan may be valid, and each may initially conform.

But the long-term outcomes can differ.

One plan may produce a stable system, while another may create a system that slowly moves toward a boundary.

This gives us a useful separation:

agent chooses the execution path
specification defines acceptable boundaries
evidence describes the observed state
conformance evaluates the current state
drift evaluates how that state changes over time

That allows agent autonomy without making the agent the only judge of its own outcomes.

When Drift Should Trigger Action

Not every drift signal should trigger automation.

A useful response model might be:

STABLE
→ no action

DEGRADING + low severity
→ observe

DEGRADING + persistent
→ investigate

VIOLATED + warning
→ alert

VIOLATED + critical
→ rollback / remediate / escalate

UNKNOWN
→ collect evidence / block risky automation

The exact policy depends on the operation.

For example, automatically restarting a stateless service may be acceptable. But automatically rolling back a database migration may not be.

Drift detection should therefore produce evidence and classification. Policy should decide what action is permitted. That keeps observation, evaluation, decision, and execution separate.

What Operational Drift Can't Tell You

Operational drift doesn't automatically tell you why the system changed.

Suppose latency rises from:

280 ms

to:

390 ms

Drift detection can tell you:

latency is degrading

It can't automatically prove the cause.

The cause might be traffic growth, database contention, a downstream dependency, network degradation, a code regression, or resource exhaustion.

Drift is therefore a detection mechanism. It's not root-cause analysis.

The baseline can also be wrong.

If the baseline was captured during an unusually good period, normal behavior may look like degradation.

So drift quality depends on good specifications, good evidence, good baselines, appropriate windows, and correct rules.

A Practical Drift Detection Workflow

If you want to introduce operational drift detection into an existing system, I would use this sequence.

1. Start with a Conformant Operation

Pick an operation where you already know the system satisfies the specification.

2. Preserve the Baseline Evidence

Store the evidence associated with that known-good state.

3. Identify Drift-Sensitive Constraints

Not every constraint needs trend analysis.

Start with things like:

latency
error rate
capacity
queue depth
availability
certificate age
backup freshness

4. Define Observation Windows

Choose windows based on operational behavior.

5. Define Stable, Degrading, Violated, and Unknown

Make the states explicit.

6. Add Severity

Separate informational drift from critical drift.

7. Add Persistence

Avoid reacting to one noisy sample.

8. Preserve Evidence

Store baseline, current state, thresholds, windows, and timestamps.

9. Separate Detection from Response

Don't make every drift signal trigger an automatic action.

10. Revisit the Model

If the system produces constant false positives, improve the rule. If it misses real degradation, improve the evidence or the window.

Don't simply widen thresholds until everything looks stable.

From Point-in-Time Conformance to Continuous Verification

Conformance gives us this:

Specification
+
Evidence
↓
Evaluation
↓
PASS / FAIL / UNKNOWN

Drift adds time:

Specification
+
Evidence at T0
+
Evidence at T1
+
Evidence at T2
↓
Drift Evaluation
↓
STABLE / DEGRADING / VIOLATED / UNKNOWN

That changes the operational model.

We're no longer asking only:

Did the operation succeed?

or:

Is the system conformant now?

We can also ask:

Is the system moving away from the intended state?

That's a much stronger foundation for operational control, especially when systems become more autonomous.

Conclusion

Operational conformance tells us whether observed evidence satisfies the specification at a point in time.

Operational drift tells us whether that relationship is changing.

A useful drift model should preserve:

baseline evidence
current evidence
constraint boundaries
observation windows
direction of change
severity
persistence
unknown states
timestamps

That gives us a way to distinguish temporary noise, persistent degradation, actual violation, and missing evidence.

The executor doesn't need to know any of this. The executor performs the work. The specification defines the intended boundaries.

Evidence tells us what's happening. Conformance tells us whether the current state is acceptable. Drift tells us whether the system is moving away from that acceptable state.

At this point, the pieces are starting to form a larger operational model:

Intent
↓
Specification
↓
Executor
↓
Evidence
↓
Conformance
↓
Drift
↓
Governed response

The next step is to put those pieces together explicitly.

That's where I want to define Specification-Driven Operations, or SDOps, as a complete operating model.

By executor independence, I mean that the operational specification remains stable even when the mechanism performing the work changes.

That gives us a useful architecture:

Specification
      ↓
Executor
      ↓
Evidence

But it leaves an important question unanswered: how do we decide whether the evidence produced by an execution actually satisfies the specification?

That's a conformance problem.

A deployment can finish successfully from the executor's point of view and still violate the operational contract.

A remediation agent can complete every action it planned and still leave the system outside acceptable limits.

A restore operation can finish without errors and still fail to restore the required data.

This is why a generic status like:

success = true

isn't enough.

We need a way to compare what should have happened with what was actually observed and produce a result that's explicit, explainable, and useful.

In this article, I'll show you how to model operational conformance, evaluate individual constraints, distinguish pass, fail, and unknown outcomes, handle tolerances, work with missing evidence, assign severity, calculate a useful conformance summary, and avoid turning conformance into a misleading score.

The examples use TypeScript and a deployment scenario, but the same approach applies to infrastructure changes, incident response, backup restoration, data pipelines, and AI-operated systems.

The central idea is this: conformance isn't whether the executor says it succeeded. Conformance is whether observed evidence satisfies the operational specification.

Prerequisites

You should be comfortable with:

• key software architecture concepts

• TypeScript or a similar language

• basic testing

• observability

• CI/CD concepts

• operational specifications

• executor independence

You don't need a particular deployment platform, and the examples are deliberately small so the evaluation model stays visible.

Table of Contents

• Prerequisites

• What Conformance Means in This Context

• Start with a Specification and Evidence

• Evaluate Constraints Individually

• Don't Reduce Everything to Pass or Fail

• Treat Missing Evidence as Unknown

• Use Tolerances Where Exact Comparison Is Wrong

• Add Severity to Constraints

• Separate Hard Constraints from Advisory Constraints

• Build a Reusable Conformance Evaluator

• Calculate a Conformance Summary Carefully

• Why a Single Score Can Be Dangerous

• Preserve the Evidence Behind the Verdict

• Conformance Should Be Reproducible

• How This Applies to Multiple Executors

• How This Applies to AI Agents

• A Small End-to-End Example

• A Practical Conformance Workflow

• What Conformance Can't Prove

• From Execution Success to Verifiable Operations

• Conclusion

What Conformance Means in This Context

In ordinary language, conformance means complying with a rule, standard, or requirement.

Here, I use the term more specifically:

Operational conformance is the evaluation of whether, and where, observed execution evidence satisfies the requirements defined by an operational specification.

In this context, evidence is the set of observable facts collected from the system that can be compared against the specification. It's not a success verdict. It's the data used to produce that verdict.

That definition has three parts.

1. The Specification

This defines what should be true.

For example:

version = v42
available replicas >= 3
error rate <= 1%
p95 latency <= 400 ms

2. The Evidence

This describes what was actually observed.

For example:

version = v42
available replicas = 3
error rate = 0.4%
p95 latency = 280 ms

3. The Evaluation

This compares the evidence with the specification.

For example:

version             PASS
available replicas  PASS
error rate           PASS
p95 latency          PASS

Conformance is therefore not an executor property. It's the result of evaluating evidence against a specification.

Conceptually:

Specification
      +
Evidence
      ↓
Conformance Evaluation
      ↓
Result

Start with a Specification and Evidence

Suppose we have this deployment specification:

type DeploymentSpec = {
  version: string;
  minReplicas: number;
  maxErrorRate: number;
  maxP95LatencyMs: number;
};

const spec: DeploymentSpec = {
  version: "v42",
  minReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

Now define the evidence:

type DeploymentEvidence = {
  version: string;
  replicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

const evidence: DeploymentEvidence = {
  version: "v42",
  replicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

The simplest possible evaluator might return a boolean:

function conforms(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): boolean {
  return (
    evidence.version === spec.version &&
    evidence.replicas >= spec.minReplicas &&
    evidence.errorRate <= spec.maxErrorRate &&
    evidence.p95LatencyMs <= spec.maxP95LatencyMs
  );
}

This works, but it has a problem.

If the result is:

false

you don't know why. That's not enough for operational work.

Evaluate Constraints Individually

Instead of one boolean, evaluate each constraint separately.

type ConstraintResult = {
  name: string;
  passed: boolean;
};

function evaluateDeployment(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): ConstraintResult[] {
  return [
    {
      name: "version",
      passed:
        evidence.version === spec.version,
    },
    {
      name: "replicas",
      passed:
        evidence.replicas >= spec.minReplicas,
    },
    {
      name: "error-rate",
      passed:
        evidence.errorRate <= spec.maxErrorRate,
    },
    {
      name: "latency",
      passed:
        evidence.p95LatencyMs <= spec.maxP95LatencyMs,
    },
  ];
}

ConstraintResult gives each check a name and a boolean result. The evaluateDeployment() function compares one observed value at a time against the corresponding rule in the specification. It checks whether the deployed version matches exactly, whether the replica count is high enough, and whether error rate and latency stay below their limits.

Instead of collapsing all of those checks into one true or false, the function returns one result per constraint. That lets the caller see exactly which requirement passed or failed.

Now the output can be:

version       PASS
replicas      PASS
error-rate    PASS
latency       PASS

or:

version       PASS
replicas      FAIL
error-rate    PASS
latency       FAIL

This is much more useful. A failed operation becomes explainable.

Don't Reduce Everything to Pass or Fail

Binary evaluation is still sometimes too simple.

Suppose the specification requires:

error rate <= 1%

but your observability system is unavailable.

What should the result be?

PASS is clearly wrong.

FAIL may also be misleading, because that mixes two different situations:

the system violated the constraint

and:

we do not know whether the system violated the constraint

A better model uses at least three states:

PASS
FAIL
UNKNOWN

For example:

type ConstraintStatus =
  | "PASS"
  | "FAIL"
  | "UNKNOWN";

Unknown evidence should never silently become success.

Treat Missing Evidence as Unknown

Suppose evidence becomes partial. In other words, the system may return some observations but not all of them. A deployment record might tell us which version is running and how many replicas are available, while the error-rate metric is temporarily unavailable.

We can represent that by making each evidence field optional:

type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

The evaluator then needs to distinguish between a real violation and a missing observation:

function evaluateErrorRate(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): ConstraintStatus {
  if (
    evidence.errorRate === undefined
  ) {
    return "UNKNOWN";
  }

  return (
    evidence.errorRate <= spec.maxErrorRate
  )
    ? "PASS"
    : "FAIL";
}

The first branch asks whether an error-rate value was observed at all. If it was not, the evaluator returns UNKNOWN instead of guessing. If the value exists, the function compares it with the maximum allowed error rate and returns PASS or FAIL.

This produces:

errorRate = 0.004 → PASS
errorRate = 0.03  → FAIL
errorRate missing → UNKNOWN

That distinction matters. Missing telemetry, here, means that a metric or operational signal we expected to observe wasn't available. For example, because the monitoring system didn't report an error-rate value for that execution window. If missing telemetry is treated as success, conformance becomes dangerously optimistic.

Use Tolerances Where Exact Comparison Is Wrong

Some constraints should use exact equality.

For example:

deployed version must equal v42

Others should not.

Numerical systems may need tolerances because measured or computed values can differ by tiny amounts even when they're operationally equivalent. Floating-point arithmetic, sampling, rounding, and measurement noise can all produce values that shouldn't fail a constraint just because they're not exactly equal.

function withinTolerance(
  observed: number,
  expected: number,
  tolerance: number
): boolean {
  return (
    Math.abs(observed - expected)
    <= tolerance
  );
}

Then:

withinTolerance(
  1.9999999,
  2,
  0.0001
);

returns true.

The function computes the absolute difference between the observed and expected values, then checks whether that difference stays within the allowed tolerance. This is useful when tiny numeric differences are expected and exact equality would create false failures.

But tolerances should come from the operational domain. They shouldn't be introduced simply to make failures disappear.

Add Severity to Constraints

Not every constraint has the same operational importance.

Suppose two constraints fail:

p95 latency = 405 ms
replicas = 0

Both are failures, but they're not equivalent.

A small latency miss may deserve attention without requiring an immediate rollback. Zero available replicas, on the other hand, may mean the service is unavailable and should trigger urgent recovery. Severity lets the evaluation preserve that operational difference instead of treating every failure as equally important.

type Severity =
  | "INFO"
  | "WARNING"
  | "CRITICAL";

type ConstraintResult = {
  name: string;
  status: ConstraintStatus;
  severity: Severity;
};

Here, status tells us whether the constraint passed, failed, or couldn't be evaluated. severity tells us how important that result is operationally.

The two dimensions are separate: a constraint can fail with WARNING severity or fail with CRITICAL severity.

Then:

latency
FAIL
WARNING

replicas
FAIL
CRITICAL

This matters when deciding whether to continue, pause, rollback, or escalate.

Separate Hard Constraints from Advisory Constraints

Some requirements define whether the operation is acceptable at all. Others are useful signals but don't necessarily block execution.

This is different from severity. Severity describes the impact of a result, while constraint mode describes whether that rule participates in the final conformance decision. A REQUIRED constraint must pass for the operation to be conformant. An ADVISORY constraint can fail and still leave the operation conformant overall, although the failure should still be reported.

type ConstraintMode =
  | "REQUIRED"
  | "ADVISORY";

A result can now include:

type ConstraintResult = {
  name: string;
  status: ConstraintStatus;
  severity: Severity;
  mode: ConstraintMode;
  expected?: unknown;
  observed?: unknown;
};

For example:

version
REQUIRED
PASS

latency-target
ADVISORY
FAIL

The operation may still be conformant overall, but with a warning. That's more expressive than one global boolean.

Build a Reusable Conformance Evaluator

So far, the examples have been tied to one deployment and a handful of hard-coded checks. The next step is to separate the evaluation mechanism from the individual rules so the same engine can evaluate different operational specifications.

To do that, we represent each rule as a Constraint<T>. Each constraint carries its own name, severity, mode, and evaluation function. An OperationalSpec<T> then becomes a collection of those constraints.

type Constraint<T> = {
  name: string;
  severity: Severity;
  mode: ConstraintMode;
  evaluate(
    evidence: T
  ): ConstraintStatus;
};

type OperationalSpec<T> = {
  name: string;
  constraints: Constraint<T>[];
};

Then:

function evaluateConformance<T>(
  spec: OperationalSpec<T>,
  evidence: T
): ConstraintResult[] {
  return spec.constraints.map(
    (constraint) => ({
      name: constraint.name,
      status:
        constraint.evaluate(evidence),
      severity:
        constraint.severity,
      mode:
        constraint.mode,
    })
  );
}

The specification owns what should be evaluated.

The evaluator collects the results. It doesn't need to know the meaning of each constraint. It simply executes every constraint's evaluation function and preserves the resulting status, severity, and mode. That keeps the evaluation engine generic while the specification remains responsible for the operational rules.

The expected and observed fields are optional in this minimal example, but in a production system I would populate them, or store references to the underlying evidence, so the final verdict remains explainable and auditable.

Calculate a Conformance Summary Carefully

Individual results are useful, but sometimes you also need a summary.

type ConformanceSummary = {
  total: number;
  passed: number;
  failed: number;
  unknown: number;
  conformant: boolean;
};

Then:

function summarize(
  results: ConstraintResult[]
): ConformanceSummary {
  const required =
    results.filter(
      (result) =>
        result.mode === "REQUIRED"
    );

  const passed =
    results.filter(
      (result) =>
        result.status === "PASS"
    ).length;

  const failed =
    results.filter(
      (result) =>
        result.status === "FAIL"
    ).length;

  const unknown =
    results.filter(
      (result) =>
        result.status === "UNKNOWN"
    ).length;

  const conformant =
    required.every(
      (result) =>
        result.status === "PASS"
    );

  return {
    total: results.length,
    passed,
    failed,
    unknown,
    conformant,
  };
}

Overall conformance now requires all required constraints to pass.

Notice what that means for UNKNOWN: because every() requires a required constraint to have status PASS, a required constraint with missing evidence makes the overall result non-conformant rather than silently passing.

Advisory constraints still appear in the report. They just don't determine the final verdict.

Why a Single Score Can Be Dangerous

It's tempting to create one single score:

conformance = 92%

But that can be misleading.

Suppose:

9 low-risk constraints pass
1 critical security constraint fails

A naïve score says:

90% conformant

Operationally, that may be completely unacceptable.

If you calculate a score, you should preserve:

constraint-level results
severity
required/advisory status
unknown evidence
failure reasons

The score can summarize, but it shouldn't erase the evidence.

Preserve the Evidence Behind the Verdict

A conformance result shouldn't only say FAIL. It should preserve what produced that verdict.

{
  "constraint": "minimum-replicas",
  "expected": ">= 3",
  "observed": 2,
  "status": "FAIL",
  "severity": "CRITICAL"
}

This lets someone answer:

What did we expect?
What did we observe?
Which rule was applied?
Why did it fail?

That is especially important when conformance decisions trigger automated recovery.

Conformance Should Be Reproducible

Suppose an operation executes at 10:00.

At 10:01, the error rate is:

0.6%

At 14:00, the dashboard shows:

2.1%

If you reevaluate the old operation using current telemetry, you may get a different result.

Conformance should therefore be evaluated against evidence associated with the execution window. By execution window, I mean the period during which the operation ran and its immediate effects were being verified. For a deployment that finished at 10:00, for example, you might evaluate health using the telemetry collected between 10:00 and 10:05 rather than whatever the dashboard happens to show several hours later.

The point is to bind the verdict to the evidence that was available for that specific execution. Otherwise, later changes in the system can retroactively change the apparent result of an operation that already happened.

A reproducible record might preserve:

specification version
execution ID
evidence snapshot
evaluation rules
timestamp

For example:

{
  "executionId": "deploy-812",
  "specVersion": "3",
  "evaluatedAt": "2026-10-06T10:01:00Z",
  "evidence": {
    "version": "v42",
    "replicas": 3,
    "errorRate": 0.006,
    "p95LatencyMs": 290
  }
}

Now the decision can be reconstructed later.

How This Applies to Multiple Executors

Suppose two executors run the same specification.

Executor A:

version      PASS
replicas     PASS
error-rate   PASS
latency      PASS

Executor B:

version      PASS
replicas     FAIL
error-rate   PASS
latency      PASS

The question is no longer:

Which executor is better?

The immediate question is:

Which execution satisfied the specification?

You answer that by running the same conformance evaluator against the evidence produced by each executor. The specification and evaluation rules stay the same; only the evidence changes.

In the example above, Executor A satisfies the specification because every required constraint evaluates to PASS. Executor B does not, because its replica constraint evaluates to FAIL. That gives us a common basis for comparison without requiring the two executors to use the same internal steps.

Over time, executor performance can be compared using conformance rate, failure categories, latency, cost, recovery frequency, and unknown evidence rate. But conformance remains the contract-level evaluation.

How This Applies to AI Agents

AI agents make explicit conformance especially important.

An agent may choose different plans for the same objective.

Agent execution 1:
scale
deploy
observe
route

Agent execution 2:
deploy canary
observe
expand

Agent execution 3:
create parallel environment
switch traffic

Because the agent can choose a different plan each time, comparing executions step by step isn't very useful. One run might use a canary rollout while another creates a parallel environment, and both can still be valid ways to reach the same objective.

What stays stable is the specification: the objective, constraints, and evidence requirements don't change just because the agent chooses a different path.

After each run, the system collects evidence about the resulting state. The conformance evaluator then compares that evidence with the same specification used for every other run. This lets the agent vary the execution plan while keeping the definition of success outside the agent itself.

Specification
      ↓
AI Agent
      ↓
Dynamic Plan
      ↓
Execution
      ↓
Evidence
      ↓
Conformance

The agent can propose actions. It shouldn't be the only authority deciding whether those actions achieved the intended outcome.

A Small End-to-End Example

Start by defining the evidence:

type DeploymentEvidence = {
  version?: string;
  replicas?: number;
  errorRate?: number;
  p95LatencyMs?: number;
};

Now define the constraints:

const constraints:
  Constraint<DeploymentEvidence>[] = [
    {
      name: "version",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (!evidence.version) {
          return "UNKNOWN";
        }

        return (
          evidence.version === "v42"
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "replicas",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (
          evidence.replicas === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.replicas >= 3
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "error-rate",
      severity: "CRITICAL",
      mode: "REQUIRED",
      evaluate: (evidence) => {
        if (
          evidence.errorRate === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.errorRate <= 0.01
        )
          ? "PASS"
          : "FAIL";
      },
    },
    {
      name: "latency-target",
      severity: "WARNING",
      mode: "ADVISORY",
      evaluate: (evidence) => {
        if (
          evidence.p95LatencyMs === undefined
        ) {
          return "UNKNOWN";
        }

        return (
          evidence.p95LatencyMs <= 350
        )
          ? "PASS"
          : "FAIL";
      },
    },
  ];

Create the specification:

const deploymentSpec:
  OperationalSpec<DeploymentEvidence> = {
    name: "deploy-orders-v42",
    constraints,
  };

Evaluate:

const evidence:
  DeploymentEvidence = {
    version: "v42",
    replicas: 3,
    errorRate: 0.004,
    p95LatencyMs: 370,
  };

const results =
  evaluateConformance(
    deploymentSpec,
    evidence
  );

const summary =
  summarize(results);

The result might be:

version          PASS     REQUIRED
replicas         PASS     REQUIRED
error-rate       PASS     REQUIRED
latency-target   FAIL     ADVISORY

And:

conformant = true

Every required constraint passed.

The advisory latency target failed, so the operation should still surface a warning.

A Practical Conformance Workflow

If you want to introduce conformance evaluation into an existing system:

1. Pick one operation.

2. Define the specification.

3. Classify constraints as required or advisory.

4. Assign severity.

5. Define the evidence model.

6. Decide how missing evidence becomes UNKNOWN.

7. Evaluate constraints individually.

8. Produce a summary.

9. Preserve the evidence snapshot.

10. Version the specification.

11. Revisit rules that produce unexpected failures or unknowns.

Don't simply weaken the specification to make results pass.

What Conformance Can't Prove

Conformance can tell you:

The observed evidence satisfies the specification.

It can't automatically tell you:

The specification is correct.

The specification may be wrong, and the evidence may also be wrong.

So conformance depends on:

specification quality
evidence quality
evaluation correctness

It's a verification mechanism, not absolute truth.

From Execution Success to Verifiable Operations

Traditional automation often ends here:

execute
↓
success / failure

A conformance-based model adds more structure:

Specification
↓
Executor
↓
Execution
↓
Evidence
↓
Constraint Evaluation
↓
Conformance

Now you can ask:

Which requirements were satisfied?

Which failed?

Which could not be evaluated?

What evidence supports the verdict?

If the system is conformant immediately after execution, you now have a baseline.

From that baseline, you can keep observing the system over time.

And then ask:

What happens when reality starts to diverge from the specification after the operation has already succeeded?

That's operational drift.

Conclusion

A successful executor isn't enough. Neither is a green pipeline or a completed agent plan.

What matters is whether the resulting system satisfies the operational specification.

That requires three things:

Specification
Evidence
Evaluation

A useful conformance model should preserve:

constraint-level results
PASS / FAIL / UNKNOWN
severity
required vs advisory rules
observed values
expected values
evidence snapshots
specification version

The executor performs the work, evidence describes what happened, and the specification defines what should have happened.

Then the conformance evaluator compares the two.

That gives us a stronger foundation for traditional automation and for increasingly autonomous systems.

But conformance at one point in time isn't the end of the story. A system can conform now and drift later.

The next question is:

How do we detect when observed reality stops matching operational intent?

That's where I want to go next.

The reason is simple: the specification should describe what success means, and the executor should decide how to achieve it.

That separation creates a useful possibility.

If the operational specification is independent from the execution mechanism, then more than one executor should be able to satisfy the same specification.

That sounds straightforward. But in practice, it raises several difficult questions:

Can two different executors achieve the same operational outcome?

How do we compare them?

What must remain stable when the executor changes?

Which differences are acceptable?

What evidence should each executor produce?

How do we know whether executor independence is real or just theoretical?

These questions matter because modern software systems rarely keep one execution mechanism forever.

Teams change:

CI/CD platforms
cloud providers
deployment systems
infrastructure tools
orchestration engines
incident automation
AI agents

If changing the executor also changes the meaning of the operation, then the system isn't really specification-driven. The executor still owns too much of the intent.

In this article, I’ll show you how to separate an operational specification from its executors, run the same specification through two different implementations, collect evidence, compare outcomes, and identify where executor independence breaks down.

The goal isn't to prove that two executors behave identically internally.

The goal is to determine whether they can satisfy the same operational contract.

Prerequisites

You should be comfortable with:

• software architecture

• interfaces and dependency inversion

• TypeScript or a similar language

• CI/CD and deployment concepts

• observability

• basic testing

• operational specifications

You don't need Kubernetes, Terraform, or any specific cloud platform. The examples are intentionally small and in-memory so the architecture stays visible.

Table of Contents

• Prerequisites

• What Executor Independence Actually Means

• Why Executor Independence Matters

• Start with One Stable Operational Specification

• Define an Executor Contract

• Build a First Executor

• Build a Second Executor

• Run the Same Specification Through Both Executors

• Compare Evidence, Not Internal Steps

• Normalize Executor-Specific Evidence

• Separate Execution Evidence from Conformance

• What Counts as Equivalent Execution?

• Where Executor Independence Usually Breaks

• How to Test Executor Portability

• Why This Matters for AI Agents

• A Small End-to-End Example

• A Practical Workflow

• What Executor Independence Does Not Mean

• From Replaceable Tools to Stable Operational Intent

• Conclusion

What Executor Independence Actually Means

Executor independence means that the operational specification remains valid even if the mechanism that performs the work changes.

For example, suppose the specification says:

Deploy Orders version v42.

Constraints:
- at least 3 replicas available
- error rate <= 1%
- p95 latency <= 400 ms
- rollback must remain possible

One executor may implement that using:

Kubernetes rolling deployment

Another may use:

blue/green deployment

Another may use:

a managed cloud deployment service

And later, an AI agent may generate its own execution plan.

If every executor can be evaluated against the same specification, then the specification is doing its job.

Conceptually:

                    ┌── Executor A
Operational Spec ───┼── Executor B
                    ├── Executor C
                    └── AI Agent

The specification stays stable while the execution mechanism changes.

That's executor independence.

Why Executor Independence Matters

Software teams replace tools constantly. A deployment workflow might move from:

Jenkins
↓
GitHub Actions
↓
Argo CD
↓
Kubernetes operator

If every migration requires rediscovering:

what success means
what constraints matter
what evidence is required
when rollback is allowed

then the operational meaning was never truly independent from the old tool.

This creates several risks.

1. Tool lock-in: The system may be technically portable while the operational rules are not.

2. Hidden behavior changes: A new executor may preserve the same deployment steps but lose an important constraint.

3. Reimplementation drift: Teams may recreate the old behavior approximately rather than exactly.

4. Audit gaps: It becomes difficult to prove that the new executor preserves the same operational contract.

Executor independence gives you a stronger migration target: preserve the specification, replace the mechanism.

Start with One Stable Operational Specification

To test executor independence, first define something stable.

For example:

type DeploymentSpec = {
  service: string;
  version: string;
  minReplicas: number;
  maxErrorRate: number;
  maxP95LatencyMs: number;
};

Then:

const spec: DeploymentSpec = {
  service: "orders",
  version: "v42",
  minReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

This specification shouldn't contain:

kubectl
helm
terraform
AWS
Azure
Argo
GitHub Actions

Those belong to executors.

The specification describes the operational contract.

Define an Executor Contract

Now define the minimum interface an executor must satisfy.

For example:

type ExecutionEvidence = {
  deployedVersion: string;
  availableReplicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

interface DeploymentExecutor {
  execute(
    spec: DeploymentSpec
  ): Promise<ExecutionEvidence>;
}

This interface doesn't say how deployment happens.

It only says:

given a specification,
perform the operation,
return evidence

In this article, evidence means the observable facts produced or collected after execution that let us evaluate what actually happened. For a deployment, that might include the version that is running, the number of available replicas, the measured error rate, and p95 latency.

Evidence isn't the executor's opinion that the operation succeeded. It's the data we can compare against the specification.

That's important. If the executor interface includes tool-specific concepts, portability starts leaking.

For example, this would be more coupled:

interface DeploymentExecutor {
  executeKubectlCommand(
    namespace: string,
    manifestPath: string
  ): Promise<void>;
}

Now the interface already assumes Kubernetes.

That's not executor-independent.

Build a First Executor

Let’s create a simple in-memory executor.

class RollingDeploymentExecutor
  implements DeploymentExecutor {
  async execute(
    spec: DeploymentSpec
  ): Promise<ExecutionEvidence> {
    return {
      deployedVersion: spec.version,
      availableReplicas:
        spec.minReplicas,
      errorRate: 0.004,
      p95LatencyMs: 280,
    };
  }
}

This executor simulates a rolling deployment.

Internally, you can imagine that it:

starts new replicas
waits for health
gradually replaces old replicas

But none of that appears in the specification. The executor owns the mechanism.

Build a Second Executor

Now create a different strategy.

class BlueGreenExecutor
  implements DeploymentExecutor {
  async execute(
    spec: DeploymentSpec
  ): Promise<ExecutionEvidence> {
    return {
      deployedVersion: spec.version,
      availableReplicas:
        spec.minReplicas + 2,
      errorRate: 0.003,
      p95LatencyMs: 260,
    };
  }
}

This executor may conceptually:

create a parallel environment
verify it
switch traffic
keep the old environment available

Its internal process is different, but its evidence shape is the same. That means both can be evaluated against the same operational specification.

Run the Same Specification Through Both Executors

Now execute both.

const rolling =
  new RollingDeploymentExecutor();

const blueGreen =
  new BlueGreenExecutor();

const rollingEvidence =
  await rolling.execute(spec);

const blueGreenEvidence =
  await blueGreen.execute(spec);

At this point, we have:

same specification
different executors
different internal behavior
different evidence values

The important question isn't whether they performed the same steps. They didn't. The question is if they both satisfied the same operational contract.

Compare Evidence, Not Internal Steps

Executor independence depends on comparing outcomes rather than implementation details.

Suppose:

Rolling deployment:
replicas = 3
error rate = 0.4%
p95 = 280 ms

Blue/green:
replicas = 5
error rate = 0.3%
p95 = 260 ms

Those outputs aren't identical, but both may be conformant. That matters.

Executor independence doesn't require:

same commands
same number of steps
same topology
same timing
same infrastructure

It requires:

same operational intent
satisfied constraints
required evidence
acceptable outcome

This is similar to interface-based programming. Two implementations can behave differently internally while satisfying the same contract.

Normalize Executor-Specific Evidence

Real executors often return different evidence formats.

Suppose executor A returns:

{
  "readyReplicas": 3,
  "image": "orders:v42",
  "latencyP95": 280
}

Executor B returns:

{
  "instancesHealthy": 5,
  "releaseVersion": "v42",
  "p95Ms": 260
}

These can't be compared directly. You need adapters.

For example:

type CanonicalEvidence = {
  version: string;
  availableReplicas: number;
  p95LatencyMs: number;
};

Adapter A:

function normalizeRolling(
  raw: {
    readyReplicas: number;
    image: string;
    latencyP95: number;
  }
): CanonicalEvidence {
  return {
    version:
      raw.image.split(":")[1],
    availableReplicas:
      raw.readyReplicas,
    p95LatencyMs:
      raw.latencyP95,
  };
}

This adapter translates the rolling executor's native output into the canonical evidence model. It extracts the version from the image tag, maps readyReplicas to availableReplicas, and renames latencyP95 to p95LatencyMs.

The important point is that the adapter doesn't change the operational meaning. It only converts executor-specific field names and formats into the shared representation expected by the specification layer.

Adapter B:

function normalizeBlueGreen(
  raw: {
    instancesHealthy: number;
    releaseVersion: string;
    p95Ms: number;
  }
): CanonicalEvidence {
  return {
    version:
      raw.releaseVersion,
    availableReplicas:
      raw.instancesHealthy,
    p95LatencyMs:
      raw.p95Ms,
  };
}

This adapter does the same job for the blue/green executor. Its raw output uses different names, but those values represent the same operational concepts: version, available capacity, and p95 latency.

With both adapters in place, the rest of the system no longer needs to understand the executor-specific shapes. It can evaluate both results using the same canonical model.

Now both executors produce evidence that can be evaluated using the same model.

This is an important architectural boundary. Executor-specific evidence stays near the executor, while canonical evidence belongs to the specification layer.

Separate Execution Evidence from Conformance

The executor should produce evidence. It shouldn't decide whether the operation was successful from the perspective of the specification.

That distinction prevents another form of coupling.

For example, avoid:

return {
  success: true,
};

A generic success flag tells you very little.

Instead, return evidence:

return {
  deployedVersion: "v42",
  availableReplicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

Then evaluate it separately.

type ConformanceResult = {
  conformant: boolean;
  failures: string[];
};

function evaluateConformance(
  spec: DeploymentSpec,
  evidence: ExecutionEvidence
): ConformanceResult {
  const failures: string[] = [];

  if (
    evidence.deployedVersion !==
    spec.version
  ) {
    failures.push(
      "wrong-version"
    );
  }

  if (
    evidence.availableReplicas <
    spec.minReplicas
  ) {
    failures.push(
      "insufficient-replicas"
    );
  }

  if (
    evidence.errorRate >
    spec.maxErrorRate
  ) {
    failures.push(
      "error-rate-too-high"
    );
  }

  if (
    evidence.p95LatencyMs >
    spec.maxP95LatencyMs
  ) {
    failures.push(
      "latency-too-high"
    );
  }

  return {
    conformant:
      failures.length === 0,
    failures,
  };
}

The evaluator receives two things: the specification that defines what should be true, and the evidence that describes what was actually observed.

It checks each constraint independently. A wrong version adds wrong-version, too few replicas adds insufficient-replicas, and the error-rate and latency checks work the same way.

At the end, conformant is true only when no failures were recorded. Returning the individual failure names is useful because it explains why an execution didn't conform instead of collapsing everything into a generic false.

This is why the executor should return facts rather than a final verdict. The same evidence can be reevaluated later if the specification changes, if an audit needs to reconstruct the decision, or if you want to compare multiple executors using exactly the same rules.

Now:

executor → evidence

specification + evidence → conformance

This separation will become important later.

What Counts as Equivalent Execution?

Two executors don't need to produce identical evidence. They need to produce evidence that satisfies the same specification.

Suppose:

Executor A
replicas: 3
error rate: 0.4%
latency: 280 ms

Executor B
replicas: 5
error rate: 0.3%
latency: 260 ms

Both may pass.

Now suppose executor B produces:

replicas: 2
error rate: 0.3%
latency: 260 ms

It fails one constraint.

That means:

Executor A:
conformant

Executor B:
non-conformant

The executors are still independent implementations, but only one satisfied the specification for this execution.

That distinction matters.

Executor independence doesn't guarantee executor correctness. It only gives you a stable contract against which correctness can be evaluated.

Where Executor Independence Usually Breaks

There are several common failure modes.

Tool-Specific Fields in the Specification

For example:

kubernetesNamespace: production
helmChart: orders

If those are truly implementation details, they shouldn't live in the operational specification.

Executor-Owned Success Rules

If each executor defines its own thresholds, the specification is no longer authoritative.

Missing Evidence Normalization

Different executors may expose different concepts that are never mapped into a common model.

Hidden Preconditions

Executor A may require an approval. Executor B may not.

If approval is part of operational intent, that rule shouldn't live only inside one executor.

Hidden Recovery Behavior

One executor may rollback automatically, while another may leave the failed state running.

If recovery behavior matters, the specification should express that expectation.

Semantic Mismatch

Two tools may use the same words differently.

For example:

healthy
ready
available
running

Those concepts need explicit definitions. Otherwise executor portability is superficial.

How to Test Executor Portability

You can test executor independence explicitly.

Start with a suite of specifications.

For example:

const cases: DeploymentSpec[] = [
  {
    service: "orders",
    version: "v42",
    minReplicas: 3,
    maxErrorRate: 0.01,
    maxP95LatencyMs: 400,
  },
  {
    service: "payments",
    version: "v18",
    minReplicas: 5,
    maxErrorRate: 0.005,
    maxP95LatencyMs: 250,
  },
];

Then run each specification against every executor.

const executors:
  DeploymentExecutor[] = [
    new RollingDeploymentExecutor(),
    new BlueGreenExecutor(),
  ];

for (const spec of cases) {
  for (const executor of executors) {
    const evidence =
      await executor.execute(spec);

    const result =
      evaluateConformance(
        spec,
        evidence
      );

    console.log({
      spec: spec.service,
      executor:
        executor.constructor.name,
      result,
    });
  }
}

This produces a useful matrix:

               Rolling    BlueGreen
Orders v42     PASS       PASS
Payments v18   PASS       FAIL

Now you have evidence about executor portability.

That is much stronger than assuming that both tools support deployments, so they're equivalent.

Why This Matters for AI Agents

AI agents make executor independence even more interesting.

An AI agent may generate a new plan every time.

For example:

Execution 1:
scale
deploy
verify
route

Execution 2:
create parallel environment
verify
switch traffic

Execution 3:
deploy canary
observe
expand rollout

The plans differ, and the executor behavior is dynamic. That makes step-by-step equivalence unrealistic.

But the specification can still remain stable.

For example:

Deploy Orders v42.

Constraints:
replicas >= 3
error rate <= 1%
latency <= 400 ms

Evidence:
running version
replicas
error rate
latency

The AI agent can choose any acceptable plan, and its result is still evaluated using the same contract.

This creates a powerful boundary:

agent autonomy
inside
operational constraints

The agent can optimize execution. It can't silently redefine success.

A Small End-to-End Example

Let’s put the pieces together.

Start with the specification:

const spec: DeploymentSpec = {
  service: "orders",
  version: "v42",
  minReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

Create two executors:

const executors:
  DeploymentExecutor[] = [
    new RollingDeploymentExecutor(),
    new BlueGreenExecutor(),
  ];

Run them:

for (const executor of executors) {
  const evidence =
    await executor.execute(spec);

  const conformance =
    evaluateConformance(
      spec,
      evidence
    );

  console.log(
    executor.constructor.name,
    evidence,
    conformance
  );
}

Possible result:

RollingDeploymentExecutor

evidence:
version = v42
replicas = 3
error rate = 0.004
p95 = 280

conformance:
PASS

and:

BlueGreenExecutor

evidence:
version = v42
replicas = 5
error rate = 0.003
p95 = 260

conformance:
PASS

The executors didn't behave identically, and they didn't need to. They satisfied the same operational specification.

Now imagine the second executor reports:

replicas = 2

The result becomes:

BlueGreenExecutor

conformance:
FAIL

reason:
insufficient-replicas

That's exactly what we want: the specification remains stable, and the executor changes.

Evidence reveals whether the execution satisfies the contract.

A Practical Workflow

If you want to test executor independence in a real system, I would use this sequence.

1. Pick One Operation

For example:

deploy service
restore backup
rotate certificate
scale worker pool

2. Extract the Operational Specification

Define:

objective
constraints
evidence requirements
recovery expectations

3. Remove Tool-Specific Language

Look for:

kubectl
Terraform
GitHub Actions
AWS CLI
specific resource IDs

Keep only what is truly part of the operational intent.

4. Define an Executor Interface

Make the executor responsible for:

performing the operation
producing evidence

5. Build the First Adapter

Wrap the current implementation, don't rewrite it.

6. Build a Second Executor

Use:

another tool
another deployment strategy
a simulator
a test double
an AI agent

7. Normalize Evidence

Map executor-specific observations into a canonical evidence model.

8. Evaluate Conformance Separately

Don't let the executor decide whether it passed.

9. Compare Portability

Run the same specifications through multiple executors.

10. Investigate Differences

Ask:

Is the executor wrong?

Is the specification incomplete?

Is evidence missing?

Are the concepts actually equivalent?

Those differences are useful. They expose hidden coupling.

What Executor Independence Does Not Mean

Executor independence doesn't mean that all tools are interchangeable.

Different executors may have different:

capabilities
costs
latency
failure modes
security models
operational complexity

A specification may also require a capability that one executor simply can't provide.

For example:

zero-downtime deployment

may be feasible in one platform and impossible in another.

That's not a failure of the specification. It's useful information. The executor can't satisfy the contract.

Executor independence also doesn't mean ignoring implementation details. Implementation details still matter for:

performance
security
cost
reliability
maintainability

The point is narrower: the operational meaning shouldn't depend on one specific execution mechanism.

From Replaceable Tools to Stable Operational Intent

Software infrastructure changes constantly.

Tools come and go, execution strategies evolve, cloud platforms change, and agents become more capable.

If operational intent is embedded inside each executor, every change risks becoming a semantic migration.

But if intent is represented independently:

Operational specification
          ↓
     stable contract
          ↓
   replaceable executor

then the system becomes easier to evolve.

This also gives us something else:

evidence from multiple executors
evaluated against the same specification

At that point, we can stop asking:

Did the tool finish?

and start asking:

To what degree did this execution conform to the specification?

That's the next problem.

Conclusion

Executor independence isn't about pretending every tool is the same. It's about protecting operational intent from implementation churn.

A specification describes:

what should happen
what constraints must hold
what evidence is required

An executor decides:

how to make it happen

Then execution produces evidence. And evidence can be evaluated independently.

That gives us:

Specification
      ↓
Executor A ──→ Evidence A
Executor B ──→ Evidence B
      ↓
Evaluation

Two executors can use completely different strategies and still satisfy the same operational contract.

That's a useful property for ordinary automation.

It becomes even more important when executors are autonomous agents whose internal plans may change from one run to the next.

But once multiple executors can operate against the same specification, a new question becomes unavoidable:

How should we measure conformance between the specification and what actually happened?

That's where I want to go next.

A pipeline can deploy a release, Terraform can provision infrastructure, a runbook can restart a service, or an agent can inspect telemetry and choose a remediation step.

But all of those systems share the same weakness: they're usually better at executing instructions than at representing the intent behind those instructions.

That gap is easy to ignore while automation is simple. If a script only runs one command, the script itself may be enough to explain what should happen.

But as systems become more distributed, more policy-driven, and more autonomous, execution logic starts carrying responsibilities it was never designed to own.

A deployment workflow may now encode:

what should be deployed
where it may run
which constraints must hold
which evidence must be checked
who may approve the change
when rollback is required
which failures are acceptable

At that point, the automation is no longer just executing. It's also becoming the place where operational intent is defined.

And that's a problem.

Because when intent and execution are fused together, changing the executor can also change the meaning of the operation.

In my previous article, I introduced the idea of an executable operational specification: a machine-readable description of what an operation is supposed to achieve and how its outcome can be evaluated.

In this article, I want to go one level deeper.

The central question is:

What should exist between human intent and the system that executes it?

I will explore:

• why automation tools often become accidental specifications

• why intent and execution evolve at different speeds

• what gets lost when intent is embedded in pipelines and scripts

• why desired state is useful but still incomplete

• how to introduce an explicit operational intent layer

• how preconditions, constraints, evidence, and recovery rules fit into that layer

• how execution plans differ from operational specifications

• how this structure helps with AI agents

• and what this separation still can't solve

The goal isn't to add another abstraction for its own sake. The goal is to make operational decisions easier to understand, evaluate, and change without rewriting the meaning of the operation every time the execution mechanism changes.

Prerequisites

You should be comfortable with:

• key software architecture concepts

• CI/CD

• infrastructure automation

• observability

• distributed systems

• basic policy concepts

• TypeScript or a similar language

You don't need a specific orchestration tool or cloud platform. The examples are deliberately small and tool-independent.

Table of Contents

• Prerequisites

• Automation Tools Often Become Accidental Specifications

• Intent and Execution Change at Different Speeds

• What Gets Lost When Intent Lives Inside the Executor

• Desired State Helps, But It's Not the Whole Intent

• The Missing Layer

• A Small Deployment Example

• Separate Preconditions from Execution Steps

• Separate Constraints from the Mechanism

• Make Evidence Requirements Explicit

• Define Recovery Before Execution Starts

• Operational Specification vs Execution Plan

• Why This Matters for AI Agents

• A Minimal TypeScript Model

• A Practical Workflow

• What This Separation Doesn't Solve

• From Automation Logic to Operational Contracts

• Conclusion

Automation Tools Often Become Accidental Specifications

Consider a deployment workflow. It may begin as something simple:

steps:
  - build
  - test
  - deploy

Then production requirements appear.

You add:

approval
region validation
health checks
canary percentage
rollback logic
error-rate thresholds
latency thresholds
artifact verification

Eventually, the pipeline becomes the only place where the operation is fully described.

That creates an accidental architecture:

Operational intent
      ↓
pipeline configuration
      ↓
execution

The pipeline is now doing two jobs: it describes what the operation means and how the operation is executed.

Those responsibilities are related, but they're not identical.

Suppose this workflow says:

deploy:
  image: orders:v42

verify:
  errorRateBelow: 0.01

rollback:
  whenVerificationFails: true

That may work perfectly. But now imagine moving the deployment to another platform.

If the operational rules only exist inside this pipeline, you must rediscover and reimplement them while moving the executor.

The real migration becomes:

move execution mechanism
+
reconstruct operational intent

That's much more dangerous than just changing tooling.

Intent and Execution Change at Different Speeds

Operational intent is often relatively stable.

For example:

Deploy the approved version.

Maintain availability.

Do not exceed the error-rate threshold.

Keep rollback possible.

Do not deploy outside the approved region.

Those expectations may remain valid for years. But execution mechanisms change much more frequently.

A team may move through:

shell scripts
Jenkins
GitHub Actions
Argo CD
Kubernetes operators
cloud-native deployment services
AI agents

If intent is tightly coupled to those mechanisms, every tooling change risks becoming an operational redesign.

That creates unnecessary churn.

You want:

stable intent
     ↓
replaceable execution

not:

new executor
     ↓
rediscover the meaning of the operation

This separation becomes more important as automation becomes more sophisticated.

The more intelligence the executor contains, the easier it becomes for intent to disappear inside implementation details.

What Gets Lost When Intent Lives Inside the Executor

When operational intent is embedded directly in scripts and pipelines, several things become harder.

1. Review

A reviewer may see:

if: error_rate < 0.01

but not know whether that threshold is:

a business requirement
an SRE policy
a temporary rollout rule
a historical workaround

The value is executable. Its meaning isn't explicit.

2. Auditability

Six months later, somebody asks:

Why was this deployment allowed?

The answer may require reconstructing:

pipeline version
feature flags
runtime variables
dashboards
approvals
operator decisions

3. Portability

Changing tools means reimplementing rules.

4. Testing

You can test whether the pipeline works. But it's harder to test whether the operational intent itself is complete.

5. Governance

Authorization rules may become buried in workflow code.

For example:

production changes require approval

may be implemented as a platform-specific branch protection rule instead of being represented as part of the operation.

6. AI Execution

An AI agent may generate a valid sequence of commands while violating an unstated operational constraint.

The problem isn't that the executor is weak. It's that the intent isn't independently represented.

Desired State Helps, But It's Not the Whole Intent

Many modern systems already use desired-state models.

For example:

replicas: 3
image: orders:v42

That's useful.

The system can compare:

desired state
vs.
observed state

and reconcile the difference.

But operational intent often includes more than final configuration.

Suppose the desired state is:

orders:v42
replicas: 3

The operation may also require:

do not reduce availability below 99.9%
do not deploy if payment dependency is degraded
keep error rate below 1%
require approval for production
rollback if latency exceeds 400 ms

Those aren't simply target-state properties.

Some are:

preconditions
runtime constraints
evidence requirements
governance rules
recovery rules

Desired state is part of operational intent, but it's not always the entire operational intent.

The Missing Layer

A more explicit architecture looks like this:

Human / organizational intent
             ↓
Operational specification
             ↓
Execution planning / binding
             ↓
Executor
             ↓
Actions
             ↓
Evidence
             ↓
Evaluation

The operational specification is the missing layer.

Its job is not to execute commands. Its job is to preserve the meaning of the operation independently from the mechanism performing it.

That layer can contain:

objective
scope
preconditions
constraints
required evidence
authorization rules
recovery conditions

The executor then answers a different question:

How can I satisfy this specification using the tools available to me?

That's a cleaner separation.

A Small Deployment Example

Suppose we want to deploy version v42 of the Orders service.

The operational objective is:

Deploy Orders v42 to production.

But that's not enough.

We also know:

the payment dependency must be healthy
at least 3 replicas must remain available
error rate must remain below 1%
p95 latency must remain below 400 ms
production deployment requires approval
rollback must remain possible

We can represent those concerns separately.

type DeploymentIntent = {
  service: string;
  version: string;
  environment: string;
  preconditions: {
    paymentDependencyHealthy: boolean;
    approved: boolean;
  };
  constraints: {
    minAvailableReplicas: number;
    maxErrorRate: number;
    maxP95LatencyMs: number;
  };
  recovery: {
    rollbackOnViolation: boolean;
  };
};

Then:

const intent: DeploymentIntent = {
  service: "orders",
  version: "v42",
  environment: "production",
  preconditions: {
    paymentDependencyHealthy: true,
    approved: true,
  },
  constraints: {
    minAvailableReplicas: 3,
    maxErrorRate: 0.01,
    maxP95LatencyMs: 400,
  },
  recovery: {
    rollbackOnViolation: true,
  },
};

Notice what's missing. There's no:

kubectl
Terraform
GitHub Actions
Argo
cloud API

The intent doesn't yet care how the deployment happens.

That's deliberate.

Separate Preconditions from Execution Steps

A precondition answers:

Is this operation allowed to start?

That's different from:

Which step should run first?

For example:

payment dependency must be healthy
production approval must exist
artifact must be signed
maintenance window must be open

These aren't execution instructions. They're conditions that should be true before execution begins.

A simple evaluator might look like this:

type Preconditions = {
  paymentDependencyHealthy: boolean;
  approved: boolean;
};

function canStart(
  preconditions: Preconditions
): boolean {
  return (
    preconditions.paymentDependencyHealthy &&
    preconditions.approved
  );
}

If:

canStart({
  paymentDependencyHealthy: false,
  approved: true,
});

returns:

false

the operation shouldn't begin.

That decision shouldn't depend on whether the executor is Kubernetes, a script, or an AI agent. The precondition belongs to the operational intent.

Separate Constraints from the Mechanism

Constraints answer what must remain true while or after this operation runs.

Examples:

replicas >= 3
error rate <= 1%
latency <= 400 ms
cost increase <= 20%
region must remain us-east-1

An executor may use many different strategies to satisfy them.

For example, to maintain three replicas:

Kubernetes may use a rolling deployment
another platform may use blue/green deployment
an agent may temporarily scale capacity before switching traffic

The mechanism differs, but the constraint does not.

That's exactly why the constraint should live outside the executor.

Make Evidence Requirements Explicit

A constraint is only useful if you can evaluate it.

Suppose you define:

error rate <= 1%

Then you need a source of evidence.

For example:

Prometheus
Datadog
CloudWatch
OpenTelemetry
custom application metrics

The specification shouldn't necessarily hard-code one vendor. But it should say that evidence is required.

For example:

type EvidenceRequirement = {
  name: string;
  metric: string;
};

const evidenceRequirements:
  EvidenceRequirement[] = [
    {
      name: "availability",
      metric: "availableReplicas",
    },
    {
      name: "errors",
      metric: "errorRate",
    },
    {
      name: "latency",
      metric: "p95LatencyMs",
    },
  ];

The executor or evidence collector can decide where those values come from. The specification defines what must be known. That distinction is important.

Define Recovery Before Execution Starts

Many operational workflows define rollback only after something goes wrong. But that's too late. Recovery is part of operational intent.

For example:

If error rate exceeds 1%, stop rollout.

If p95 latency exceeds 400 ms, restore previous version.

If evidence is unavailable, require human review.

These aren't just implementation details. They express acceptable operational behavior.

A simple representation might be:

type RecoveryPolicy = {
  rollbackOnConstraintViolation: boolean;
  requireHumanReviewWhenEvidenceMissing:
    boolean;
};

The executor can implement rollback differently. The policy still belongs to the operation.

Operational Specification vs Execution Plan

This distinction is important.

An operational specification answers:

What should happen?

What must be true?

What evidence is required?

What happens if constraints fail?

An execution plan answers:

Which actions will we perform?

In what order?

Using which tools?

For example:

Specification

Deploy Orders v42.

Keep at least 3 replicas available.

Error rate <= 1%.

Rollback if the constraint is violated.

Execution plan

1. Scale Orders to 6 replicas.
2. Deploy v42 to 1 replica.
3. Route 10% of traffic.
4. Wait 5 minutes.
5. Check metrics.
6. Increase traffic.
7. Remove old replicas.

The plan is one possible way to satisfy the specification.

Another executor might produce a different plan. That's useful. It means the same operational intent can survive changes in tooling and execution strategy.

Why This Matters for AI Agents

This separation becomes especially important when the executor is an AI agent.

A traditional script usually has a predictable path while an agent may decide dynamically.

For the same incident, it might choose:

restart
scale
reroute
disable feature
change configuration

If correctness is defined by following one exact sequence, dynamic execution becomes difficult to verify.

But if correctness is defined by an operational specification, the agent has flexibility.

For example:

Objective:
restore checkout availability

Preconditions:
payment database reachable

Constraints:
authentication remains enabled
no payment duplication
error rate <= 1%
cost increase <= 20%

Evidence:
checkout success rate
duplicate payment count
error rate
cost delta

Recovery:
escalate if constraints cannot be satisfied

The agent can choose different actions, but its behavior is still bounded.

That gives us:

Intent
↓
Specification
↓
Agent-generated plan
↓
Execution
↓
Evidence
↓
Evaluation

The agent is free to decide how. It's not free to redefine what success means.

That distinction will become increasingly important as autonomous systems gain more operational authority.

A Minimal TypeScript Model

We can combine these ideas into a small generic model.

type OperationalSpec<TContext, TEvidence> = {
  name: string;

  canStart(
    context: TContext
  ): boolean;

  evaluate(
    evidence: TEvidence
  ): EvaluationResult;

  recovery: RecoveryPolicy;
};

type EvaluationResult = {
  conformant: boolean;
  failures: string[];
};

type RecoveryPolicy = {
  rollbackOnConstraintViolation: boolean;
};

For a deployment:

type DeploymentContext = {
  paymentDependencyHealthy: boolean;
  approved: boolean;
};

type DeploymentEvidence = {
  version: string;
  replicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

Then:

const deploymentSpec:
  OperationalSpec<
    DeploymentContext,
    DeploymentEvidence
  > = {
    name: "deploy-orders-v42",

    canStart: (context) =>
      context.paymentDependencyHealthy &&
      context.approved,

    evaluate: (evidence) => {
      const failures: string[] = [];

      if (evidence.version !== "v42") {
        failures.push(
          "wrong-version"
        );
      }

      if (evidence.replicas < 3) {
        failures.push(
          "insufficient-replicas"
        );
      }

      if (evidence.errorRate > 0.01) {
        failures.push(
          "error-rate-too-high"
        );
      }

      if (
        evidence.p95LatencyMs > 400
      ) {
        failures.push(
          "latency-too-high"
        );
      }

      return {
        conformant:
          failures.length === 0,
        failures,
      };
    },

    recovery: {
      rollbackOnConstraintViolation:
        true,
    },
  };

Now execution can be handled elsewhere.

For example:

interface DeploymentExecutor {
  execute(
    spec: typeof deploymentSpec
  ): Promise<DeploymentEvidence>;
}

That executor could be backed by:

Kubernetes
a cloud platform
a test harness
a local simulator
an AI agent

The specification remains the reference point.

A Practical Workflow

If you want to introduce this separation into an existing automation system, start with one operation.

1. Pick a Repeated Operation

For example:

deploy service
rotate certificate
scale worker pool
restore backup

2. Extract the Objective

Write down what the operation is trying to achieve. Avoid commands.

3. Extract Preconditions

Ask:

What must already be true before this operation can begin?

4. Extract Constraints

Ask:

What must remain true during or after execution?

5. Define Evidence

For every constraint, identify the observation required to evaluate it.

6. Define Recovery

Decide what should happen when evidence shows that a constraint was violated.

7. Leave Execution Separate

Let the current automation tool remain the executor. Don't rewrite everything at once.

8. Evaluate the Existing Executor

Ask whether the current script, pipeline, or agent satisfies the extracted specification.

This is useful because the separation can be introduced incrementally. You don't need a new operations platform to begin.

What This Separation Doesn't Solve

Separating intent from execution doesn't automatically make operations correct.

You can still have:

wrong objectives
bad thresholds
missing evidence
misleading metrics
conflicting constraints
unsafe executors
security bugs
incorrect recovery policies

The specification itself can be wrong. That matters.

A formal representation doesn't make an assumption true. It only makes the assumption easier to inspect and evaluate.

There's also a cost. More explicit operational intent means more artifacts to maintain.

If specifications aren't versioned and reviewed, they can become stale. If evidence definitions are weak, conformance results can become misleading. And some operational decisions remain difficult to formalize.

Human judgment doesn't disappear. The value comes from making more of that judgment explicit.

From Automation Logic to Operational Contracts

There's another way to think about this separation.

A mature operational specification starts to behave like a contract.

It says:

This operation may begin under these conditions.

It must preserve these constraints.

It must produce this evidence.

Its outcome will be evaluated using these rules.

If it fails, these recovery conditions apply.

That's much stronger than:

run this workflow

The workflow is an implementation. The operational contract describes what that implementation is responsible for achieving.

This gives us a structure like:

Intent
↓
Operational contract
↓
Execution plan
↓
Executor
↓
Evidence
↓
Evaluation

That separation creates room for something important:

multiple execution strategies
for the same operational intent

And once that's possible, another question appears:

Can two different executors satisfy the same operational specification?

That's the question I want to explore next.

Conclusion

Automation has made software operations faster and more repeatable.

But execution is only one part of an operation. We still need to know:

why the operation is allowed
what outcome is intended
what constraints must hold
what evidence is required
what happens when the constraints fail

When all of that logic lives inside a pipeline, script, or agent, the executor becomes the accidental owner of operational meaning.

That coupling makes systems harder to review, migrate, audit, and verify.

A better separation is:

Intent
↓
Operational specification
↓
Execution plan
↓
Executor
↓
Evidence
↓
Evaluation

The specification describes what success means. The executor decides how to achieve it.

That distinction becomes increasingly valuable as execution mechanisms become more dynamic. Especially when those executors are AI agents.

Because the more freedom we give a system to decide how work gets done, the more explicit we need to be about what the work is supposed to achieve.