When the Plan Changes but the Agents Keep Working

PlotWarden is designed to keep ratified intent, evidence-backed reality, and active development work aligned while all three are changing.

AI coding agents are increasingly capable inside a bounded task. Give one a clear objective, a stable codebase, the right context, and a test loop, and it can often make useful progress.

The harder problem begins when the surrounding project changes before the task is finished.

A gameplay rule is revised. An architectural assumption fails a benchmark. A contract changes. A design decision is superseded. A claim that several tasks relied on turns out to be false. The worker that started under the old world does not necessarily know that its world has ended. It may continue producing competent work against an obsolete premise.

Today, humans close that gap manually. They reconstruct what changed, remember which tasks depended on it, interrupt the right work, preserve the work that remains valid, revise the plan, and stop stale output from merging.

PlotWarden is intended to make that reconciliation continuous.

The problem is not simply coordinating more agents. The problem is keeping work valid while the meaning of the work changes.

This article describes the intended conceptual system rather than a particular release, deployment, or technology stack.

The control loop: information becomes evidence before it becomes authority

PlotWarden begins with a strict distinction: observing a change does not grant that change authority.

A test result can show how the system behaves. It cannot decide how the system ought to behave. A benchmark can disprove an architectural assumption. It cannot silently weaken an architectural goal. A wiki edit can propose a new rule. It cannot rewrite the authoritative design merely because it was the most recent document to change. An agent can produce a persuasive explanation. Persuasiveness is not ratification.

PlotWarden therefore treats incoming information as evidence first. It captures the source, content, time, provenance, scope, and trust class before deciding what the record is allowed to affect.

The loop has six stages:

1. Changes and reports arrive. These may come from specifications, code, tests, benchmarks, runtime traces, human decisions, agent claims, issues, documentation, or external sources.
2. Evidence is captured. PlotWarden snapshots and fingerprints the source, records provenance, and normalizes the change.
3. Authority is classified. Policy determines whether the record is observational, eligible for automatic ratification within a narrow scope, human-gated, or rejected and quarantined.
4. The maintained plot is updated. Intent, reality, active work, and the immutable ledger remain distinct but linked.
5. Impact is reconciled. PlotWarden traces cause and effect and assigns dispositions only to affected work.
6. Execution proceeds under control. Workers receive new or revised orders, while protected state changes remain manager-owned.

Evidence from execution returns to the loop. A human decision, when one is genuinely needed, becomes a versioned authority event, advances the project epoch, and triggers reconciliation again.

This is not a one-time planning phase. It is an operating loop.

Four structures keep different kinds of truth from collapsing together

A single “source of truth” is not enough for a changing software project. It tends to collapse four very different questions:

• What is the product supposed to become?
• What does the available evidence say it currently is?
• What work is active right now?
• Why did the system make its decisions?

PlotWarden keeps those questions separate.

1. Ratified Intent Graph

This is the authoritative direction of the project:

• requirements;
• gameplay rules;
• architecture decisions;
• contracts and interfaces;
• performance budgets;
• acceptance criteria;
• superseded and successor decisions.

For Black Skies, this may include goals such as compelling combat and crew gameplay, bounded or deterministic simulation behavior, stable Unity/backend contracts, the long-term goal of approximately 10,000 simultaneous captains, and the requirement to pursue that scale without time dilation.

Intent changes only through an authorized ratification path.

2. Evidence-Backed Reality Graph

This represents what the available evidence supports about the current system:

• implementation state;
• test results;
• benchmark results;
• runtime traces;
• observed contracts;
• profiling evidence;
• unresolved contradictions;
• confidence and verification status.

Reality is falsifiable. A new test, trace, or benchmark may update it.

3. Active Execution Graph

This represents what is being attempted now:

• plans;
• tasks;
• worker runs;
• builds;
• patches;
• pull requests;
• experiments;
• repair work;
• merge ordering.

It is temporal and disposable. Its job is to carry the project from current reality toward ratified intent.

4. Immutable Evidence and Command Ledger

This records why anything changed:

• source snapshots;
• evidence artifacts;
• commands and events;
• policy decisions;
• ratifications;
• epochs and versions;
• side-effect records;
• supersession history.

The ledger is not another product map. It is the durable explanation of how the maps changed.

A useful shorthand is:

Two living maps, one active plan, and one evidence ledger.

The separation prevents category errors. A passing test may update Reality, but it cannot rewrite Intent. A human approval is bound to an exact proposal, evidence set, graph version, and scope. Rejected or quarantined material remains auditable without entering authoritative state.

The governing rule is not “the latest message wins.” It is:

The latest ratified authority record within the relevant scope wins.

Reconciliation is selective: preserve what is still true

Ordinary orchestration asks, “What task should run next?”

PlotWarden asks a harder question:

What remains valid after the world changed?

When intent or reality changes, PlotWarden compares the change against active plans, dependencies, contracts, claims, support relationships, and work already in flight. It finds the affected frontier instead of treating the whole project as invalid.

The public dispositions are intentionally simple:

• Preserve — the work remains valid and may continue.
• Recall — the governing order has been superseded; stop the worker safely.
• Quarantine — retain the output for audit or diagnostics, but do not treat it as clean knowledge.
• Repair — create targeted corrective work against the new state.
• Re-plan — rebuild the affected portion of the plan because its assumptions or dependencies changed.
• Block or escalate — official commitment cannot proceed until a genuine authority conflict is resolved.

The goal is not to make change impossible. It is to avoid two equally bad defaults:

• let every stale task finish and hope review catches the damage;
• cancel everything and restart the project whenever a consequential assumption moves.

PlotWarden should instead preserve the unaffected work, contain the invalid work, and repair only the portion of the plan that actually changed.

Workers get bounded freedom, not authority

AI coding workers need room to explore. They should be able to inspect code, edit files, run tests, build artifacts, evaluate hypotheses, and propose patches. A system that forces human approval for every tool call would destroy the development loop it is trying to improve.

But exploration and authority are different.

PlotWarden’s central worker invariant is:

Workers produce evidence, never authority.

A worker receives a sealed order containing the task, purpose, hard constraints, observed epoch, input fingerprints, allowed paths, scoped credentials, relevant contracts and claims, and required evidence.

The worker operates inside a scoped environment. It may edit its workspace and use approved tools, but it cannot directly:

• mutate the official DAG;
• merge a protected branch;
• deploy;
• publish a package or release;
• post an official decision;
• change ratified intent.

Awareness reads and support reads

Cause-and-effect analysis depends on knowing what a worker relied on.

PlotWarden distinguishes two broad forms of knowledge consumption:

• Awareness read: the worker saw the material. It is logged for audit but does not automatically cause future invalidation.
• Support read: the worker relied on the material to make a claim, patch, test, or decision. It becomes a dependency that future reconciliation can follow.

The distinction matters. Recording every byte as a consequential dependency would create an unusable graph. Recording only what the worker remembers to declare would leave dangerous blind spots. PlotWarden therefore combines mechanical observation, worker-declared support sets, and validation of the resulting evidence bundle.

The evidence outbox

A completed worker run returns a structured bundle containing items such as:

• a patch or diff;
• a content-addressed manifest;
• tool events and logs;
• the support set;
• test and benchmark results;
• claims and assertions;
• proposed comments or protected actions.

A completion gate checks the bundle before acceptance:

• Are the manifest and hashes valid?
• Was the run killed or recalled?
• Is its epoch still current?
• Are the inputs it relied on still current?
• Did it consume a poisoned claim?
• Is the required evidence present?
• Did it remain inside its path, tool, and resource policies?

A successful worker is not automatically an accepted worker. A stale or killed run may have produced useful diagnostics, but those outputs remain quarantined until explicitly repaired or safely salvaged.

Let agents call normal build tools—move the control underneath the CLI

Coding models are trained to use familiar commands. They know how to call:

pytest
mvn test
dotnet test
npm test
docker build

Trying to teach each model not to use those tools directly is the wrong abstraction. The environment should make the normal command safe and observable.

PlotWarden’s tool-proxy model puts compatible shims first in the worker’s PATH. The agent experiences a normal CLI. The proxy captures the invocation and decides whether to run it locally, route it to a remote executor, record it as a manager-owned intent, or deny it.

The proxy can record:

• project, task, and run identity;
• observed epoch;
• working directory;
• command and arguments;
• source commit;
• uncommitted patch hash;
• proxy and toolchain versions;
• executor image;
• cache identity;
• idempotency key.

The build control plane then handles authentication, policy, resource selection, cancellation, and job recording. A separate executor runs the actual toolchain in an isolated environment with scoped secrets, approved egress, dependency caches, and job-specific artifact storage.

This separation has several advantages:

• the worker-facing environment can stay stable and lightweight;
• heavy builds do not compete with the coding agent for resources;
• language toolchains can evolve independently of agent images;
• exact build environments can be pinned and reproduced;
• dependency ingress and network egress become observable;
• build logs, reports, resource use, and outputs become part of the evidence chain;
• the same agent behavior can use a local executor, a LAN build server, or another backend without changing the CLI contract.

The worker still receives streamed output, error messages, report locations, and the correct exit code. Its TDD loop remains recognizable.

But a passing build is still only evidence.

Build passed does not mean merge authorized.

PlotWarden separately checks that the build corresponds to the exact current patch, current epoch, required test matrix, current contracts and claims, and valid merge order.

If a worker is recalled while a remote build is running, PlotWarden requests cancellation and quarantines any late result. A successful build cannot resurrect a stale run.

Hallucination safety requires claim lineage, not another confidence score

A software control plane can make a hallucination more dangerous if it wraps the false claim in clean provenance and then encourages every worker to reuse it.

PlotWarden therefore treats consequential factual statements as explicit claims with a lifecycle. Agent output begins as a proposal, not as fact.

A claim may move through states such as:

Proposed → Unverified → Verified → Ratified
                       ↘ Rejected

Verified or Ratified → Disputed → Restored | Poisoned | Superseded

Every consequential claim should retain:

• its source and source hash;
• its trust class;
• supporting and contradicting evidence;
• the verification method;
• its validity period;
• the tasks, runs, patches, tests, and decisions that relied on it.

Verification must match the claim

A generic “model confidence” score is not enough. Different claims need different evidence:

• a gameplay rule should be checked against a ratified design decision;
• a code-behavior claim should be checked with static analysis, tests, or runtime evidence;
• a contract claim should be checked against the schema and contract tests;
• a performance claim should be checked with a reproducible benchmark under stated conditions;
• an external-library claim should be checked against an archived primary source;
• a claim that a patch satisfies a requirement should be checked against independent acceptance criteria and tests.

Model confidence, self-explanation, repetition, and fluent reasoning are not evidence.

Poisoning and fan-out

When contradictory evidence arrives, the claim becomes disputed and is re-evaluated. If it is false or unsafe to reuse, PlotWarden marks it poisoned.

Poisoning is not merely a label on a document. The system follows support relationships to every known consumer:

• tasks and plans;
• active and completed worker runs;
• patches and pull requests;
• derived claims;
• contracts;
• benchmarks;
• reports.

Affected work becomes suspect or stale. Output may be quarantined. Repair or re-planning work is created. The propagation should be atomic so no consumer sees a half-applied correction.

Hostile content is data, never instruction

Issues, PR comments, READMEs, logs, wikis, external pages, and prior agent summaries can contain hidden instructions. PlotWarden must preserve their provenance and trust class and treat their text as data. Untrusted content may propose claims; it cannot issue control-plane commands or grant itself authority.

The safety objective is not to find a perfectly truthful model. It is to build procedures that prevent an unverified statement from silently becoming shared authority.

Black Skies is the forcing function

PlotWarden is not being conceived in a vacuum. It is meant to accelerate Black Skies development, with priorities driven by whichever coordination, architectural, knowledge, or verification problem most limits the project at a given time.

Black Skies is an unusually demanding environment for this idea because it is being iteratively rearchitected along two axes at once:

1. create a strong gameplay experience;
2. move toward the long-term goal of approximately 10,000 simultaneous captains at full simulation speed, without time dilation.

Those goals create exactly the kind of moving project PlotWarden is meant to govern. Gameplay rules, Unity behavior, backend simulation, NPC doctrine, persistence, contracts, tests, benchmarks, and architecture experiments may all change at different speeds.

Consider an illustrative case.

The ratified intent includes:

• a long-term scale target;
• full-speed simulation;
• no time dilation;
• performance budgets;
• Unity/backend contracts;
• acceptance criteria for gameplay correctness.

A reproducible benchmark then shows that the current simulation architecture cannot meet the relevant performance budget.

That benchmark should update the Evidence-Backed Reality Graph. It may dispute an architecture assumption. It should not silently weaken the 10,000-captain goal.

PlotWarden traces the impact across active work:

• a simulation architecture experiment may need repair or re-planning;
• Unity combat integration may require retesting if an interface changes;
• NPC doctrine tests may need to wait for a settled simulation contract;
• unrelated starbase content work may remain valid and continue.

This is the core value proposition in concrete form:

The goal remains visible. The evidence becomes honest. Affected work changes. Unaffected work continues.

PlotWarden can then dispatch architecture experiments, tests, benchmarks, or repair work and continue reconciling as new evidence returns.

Human judgment should resolve ambiguity, not schedule every task

PlotWarden is not intended to remove people from consequential product decisions. It is intended to stop making people reconstruct the entire project before every decision.

Objective cases should be handled mechanically:

• an old-epoch result is stale;
• a required contract test failed;
• a worker used a poisoned support claim;
• a patch touched a forbidden path;
• a declared contract broke a known consumer;
• a killed run cannot merge;
• a low-authority observation cannot rewrite intent.

Human adjudication is appropriate when:

• two current authorities conflict within the same scope;
• a core gameplay or product goal may change;
• evidence remains genuinely ambiguous;
• a security, persistence, economy, or destructive migration boundary is involved;
• no policy yet covers the case.

The review surface should show the conflict, provenance, evidence, affected frontier, recommended disposition, and consequences. A human answer is then recorded as an authority-producing event, rechecked against the current epoch, and fed back into reconciliation.

The human decides direction. PlotWarden keeps that decision connected to everything it affects.

Why ordinary orchestration is not enough

Several adjacent systems solve useful pieces of the problem:

• task graphs remember what work exists;
• workflow engines make processes durable;
• CI systems test completed output;
• agent frameworks help workers plan and execute;
• observability systems explain what happened;
• Git hosts control branches and pull requests.

PlotWarden is not intended to replace those systems.

Its role is the semantic control layer between them:

• What changed?
• Was the change authoritative, observational, proposed, or untrusted?
• What intent or reality state may it update?
• Which active work relied on the affected information?
• What should be preserved, recalled, quarantined, repaired, re-planned, or blocked?
• Which evidence is sufficient for official commitment now?

A task tracker can say that Task B depends on Task A. PlotWarden must understand that a newly ratified gameplay rule superseded the assumption behind Task A, that Task B consumed that assumption, that Task C did not, and that the right response is to repair B while preserving C.

A CI system can reject a broken patch after completion. PlotWarden is intended to recognize that a patch has become semantically stale before it is allowed to become official—and to repair the plan rather than merely report a red build.

A workflow engine can reliably retry a step. PlotWarden must decide whether retrying that step is still the correct action.

The safety invariants

The system’s safety should come from mechanics, not from asking models to behave better.

The intended invariants are:

1. Untrusted content is data, never instruction.
2. Agent-generated claims begin unverified.
3. No source can grant itself authority.
4. Model confidence and self-explanation are not evidence.
5. Workers cannot mutate protected state.
6. Killed or stale output is quarantined.
7. Every consequential action is attributable, versioned, and idempotent.
8. A poisoned claim reaches every known support consumer.
9. Uncertainty blocks official commitment, not harmless local exploration.
10. Human decisions bind to an exact proposal and are rechecked before execution.
11. A passing build is evidence, not authority.
12. The latest ratified authority record wins only within its relevant scope.

These rules let workers move quickly inside their lane while making official state deliberately harder to corrupt.

Keeping the plot true

The name PlotWarden comes from the operational idea of keeping “the plot”: maintaining an authoritative picture as new reports arrive.

In software development, the plot is not just a task list. It is the linked state of:

• what the product is meant to become;
• what the available evidence says currently exists;
• what work is active;
• what knowledge that work depends on;
• what may safely become official next.

As AI workers become faster, this layer becomes more important, not less. More execution capacity means more work can become stale at once. More generated knowledge means a false claim can spread further. More parallel changes mean humans spend more time reconstructing causality and less time making the decisions that actually require judgment.

PlotWarden’s intended job is to take on that reconstruction continuously.

It should not make change disappear. It should make change legible.

It should not trust every agent less by adding approval to every action. It should give agents bounded freedom while keeping authority explicit.

It should not restart everything when one assumption moves. It should preserve what remains true.

And for Black Skies, it should help the project iterate toward better gameplay and a far more ambitious simulation architecture without losing the connection between the goal, the evidence, and the work being done.

Workers build. Evidence returns. PlotWarden keeps the development plot true.