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. Some sources may be registered as authoritative within narrowly defined scopes, but that is not a bypass around the evidence path. Their changes still enter as versioned records and must be converted into scoped intent deltas before they can redraw desired state.

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. But the four structures are not four independently writable sources of truth. The Evidence and Command Ledger is the canonical mutation history. Ratified Intent, Evidence-Backed Reality, and Active Execution are versioned, rebuildable projections over that history.

If a projection disagrees with the ledger or with another projection, PlotWarden does not pick whichever view is newest. Official commitment pauses until the projections are rebuilt from the canonical sequence under pinned schema and reducer versions and their graph roots agree.

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 the canonical mutation history. It is the durable explanation of how the maps changed and the source from which their current graph roots can be reproduced. Each projection carries the schema and reducer version used to build it. The views may be optimized for different questions, but none may independently manufacture official state.

A useful shorthand is:

Two living maps, one active plan, and one canonical 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.

How authoritative knowledge sources redraw desired state

The distinction between evidence and authority does not mean that PlotWarden ignores authoritative knowledge sources. It means that authority must be explicit, scoped, versioned, and mechanically applied.

PlotWarden maintains an authority registry that answers a narrower question than “Is this source trusted?” It answers:

Which actor or source may define which part of desired state, for which kind of change, under which conditions?

Authority is therefore a policy over several dimensions:

source identity
× actor role
× product or specification scope
× change type
× environment
× risk class
× required evidence
× current epoch

A source may be authoritative for one subject and merely observational for another. A ratified gameplay-design repository may define combat and crew rules. An architecture decision record may govern a particular service boundary. An API schema repository may define the current interface contract. An approved performance specification may define the simulation budget. A benchmark can provide strong evidence about present performance, but it cannot lower the performance goal. A test can prove that the code behaved a certain way under stated conditions, but it cannot decide that the behavior is intended.

The source adapter may report where a change came from and suggest a change classification. It cannot grant the source authority over itself. PlotWarden’s current policy makes that decision.

The same rule prevents authority laundering after ingestion. Moving worker-derived material into a manager-owned database, graph, summary, or document does not grant it authority. A worker claim becomes Ratified Intent only through an explicit, policy-valid transition bound to the exact proposal, scope, evidence, and epoch.

From a source change to an intent-graph update

When an authoritative source changes, PlotWarden does not copy the new document wholesale into the Intent Graph. It performs a versioned intent-redrawing transaction:

1. Snapshot the source. Capture the exact source revision, content hash, actor, event time, ingestion time, and provenance.
2. Derive a normalized intent delta. Identify the atomic additions, removals, replacements, renames, constraint changes, and relationship changes represented by the source revision.
3. Resolve the governed scope. Determine the exact Intent Graph nodes and edges that this source is permitted to affect.
4. Compare against current ratified intent. Produce an explicit diff rather than treating the new source as an opaque replacement.
5. Evaluate authority and policy. Check source identity, actor role, scope, change type, risk class, evidence requirements, policy version, and current epoch.
6. Classify the delta. Route it as automatically ratifiable, human-gated, observational only, or rejected and quarantined.
7. Bind the decision. Bind automatic or human ratification to the exact source snapshot, normalized delta, affected graph slice, evidence hashes, policy version, and epoch.
8. Supersede rather than erase. Close the old records’ validity intervals and link them to successor records. Deletions become explicit supersession or withdrawal events; history is not destroyed.
9. Update atomically. Append the authority event, update the affected Intent Graph subgraph, and advance the project epoch as one consequential state transition.
10. Reconcile the consequences. Compare the revised desired state with Reality and Active Work, then preserve, recall, quarantine, repair, re-plan, or block only the affected work.

In compact form:

Authoritative source revision
→ versioned source snapshot
→ normalized, scoped intent delta
→ authority and epoch check
→ auto-ratification or human adjudication
→ supersession + atomic Intent Graph update
→ epoch advance
→ reconciliation of active work

The graph is “redrawn” only where the authority scope and the ratified delta require it. PlotWarden does not rebuild the whole desired state whenever one document changes, and it does not allow one source to overwrite an unrelated domain simply because its revision is newer.

Supersession is different from deletion

Desired state evolves. PlotWarden must retain that evolution rather than flatten it into a current document.

When a rule, contract, decision, or budget changes, the former record remains available with:

• its original source snapshot and hash;
• the epoch in which it became valid;
• the epoch in which it ceased to be current;
• the successor or withdrawal event;
• the reason for supersession;
• the workers, claims, tests, and artifacts that consumed it.

That lineage lets PlotWarden answer not only “What is the rule now?” but also:

• What rule was this worker given?
• Which source established it?
• When did it change?
• What work relied on the predecessor?
• Which output remains valid despite the change?
• Why was this task repaired rather than preserved?

Conflicting authoritative sources do not silently race

The newest raw edit does not automatically win. If two currently valid authority records conflict within overlapping scope, PlotWarden first applies explicit precedence policy where one exists. If policy cannot resolve the conflict, official commitment blocks and a human adjudication record is required.

The review should present:

• both source revisions;
• their authority scopes;
• the current ratified state;
• the proposed intent diff;
• supporting and contradictory evidence;
• the affected frontier of work;
• the consequences of each resolution.

The human decision then becomes a new ratified authority event. PlotWarden rechecks it against the current epoch before applying it, because a correct answer to an old graph may be wrong by the time the operator responds.

Black Skies example: a gameplay source changes desired state

Suppose the ratified Crew Combat Rules source currently states:

Morale affects card availability only after combat.

A new authorized revision changes the rule to:

Morale affects card availability during combat.

PlotWarden should:

1. capture the exact source revision and actor;
2. confirm that the source governs crew-combat behavior;
3. derive the changed rule and affected specification scope;
4. bind automatic or human ratification to that revision and graph slice;
5. supersede the previous rule node without deleting it;
6. update the affected Intent Graph subgraph;
7. advance the epoch;
8. trace consumers such as backend combat validation, Unity action-menu behavior, NPC doctrine, tutorials, and relevant tests;
9. preserve unrelated starbase, art, or content-pipeline work;
10. create targeted repair and retest orders.

The desired state changed because an authorized source changed inside its governed scope, not because a model summarized the revision confidently or because the newest file happened to arrive last.

Black Skies example: a benchmark changes reality, not the goal

Now consider a hypothetical case of the opposite kind.

The Ratified Intent Graph contains:

Approximately 10,000 simultaneous captains at full simulation speed, without time dilation.

Suppose a reproducible benchmark showed that a candidate architecture revision could not meet the corresponding performance budget.

The benchmark would be authoritative evidence about the tested revision under the recorded conditions. It should update the Evidence-Backed Reality Graph, dispute the candidate's assumption, and trigger impact analysis across the plans and experiments that depend on it.

It should not redraw the scale target.

Changing that target would require a separate, authorized intent decision. PlotWarden’s value lies partly in preventing an implementation limitation from being laundered into a product decision merely because the limitation is real.

The distinction is:

Authoritative design revision
→ may redraw the governed portion of Intent after ratification

Test, benchmark, trace, or worker report
→ may redraw Reality and trigger reconciliation
→ cannot silently redefine Intent

This scoped authority mechanism is what allows PlotWarden to consume changing knowledge without collapsing “what we have observed” into “what we have decided.”

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.

Precision requires permission to say “dependency unknown”

Selective reconciliation is safe only when PlotWarden has enough dependency evidence to justify the frontier it computed. Software dependencies are not limited to declared imports. They may be semantic, environmental, dynamic, cyclic, side-effecting, or discovered only while a worker runs.

When coverage is uncertain, PlotWarden must not fabricate a precise answer. Dependency unknown is a valid control-plane result. Policy may then choose broader tainting, quarantine, retesting, conservative invalidation, or human adjudication according to risk.

This creates an explicit asymmetry:

• a false preserve keeps work whose premise changed and threatens correctness;
• a false recall stops work that remained valid and threatens efficiency.

PlotWarden should pursue precision only after constraining false preserves below the acceptable risk threshold. 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. It also pins the policy, graph schema, reducer, prompt template, model, tool-proxy, and verifier versions needed to interpret the result. Nondeterministic model and tool outputs are recorded as evidence; they are not regenerated during history reconstruction.

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?

Acceptance is an atomic versioned commit

The completion gate cannot check freshness and then commit in a separate step. PlotWarden compares the sealed order’s expected graph root and relevant input versions with the current canonical head inside the same official mutation transaction that records acceptance.

If they match, PlotWarden appends the acceptance event and advances protected state atomically. If they do not match, the result is classified for rebase, retest, repair, stale quarantine, or rejection. Required tests are evaluated against the actual merge candidate, not only the worker’s isolated branch.

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.

The proxy is the ergonomics, routing, and observability layer, not the entire security boundary. Mechanical authority also depends on the scoped sandbox, restricted direct egress, short-lived per-order credentials, allowlisted capabilities, output validation, and an append-only effect journal. A worker that bypasses a normal CLI shim must still lack the credentials and network path needed to perform protected actions.

Worker-triggerable builds, tests, benchmarks, linters, and static analysis remain mediated evidence-producing actions. Merge, deploy, publish, protected-state mutation, and official decisions remain manager-only actions. Every effectful operation receives its own idempotency key; reversible multi-step effects require a tested compensation path, and irreversible actions require a fresh authority check immediately before commitment.

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 lineage and independent verification

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.

Provenance is not truth. It explains where a claim came from, who or what produced it, and which evidence was attached. Truth still requires claim-type-specific validation, independent reproduction where appropriate, source-quality policy, contradiction handling, expiry, and revocation.

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

A claim may move through a simplified public lifecycle such as:

Proposed → Unverified → Verified → Ratified
                       ↘ Rejected

Verified or Ratified → Disputed → Restored | Poisoned | Superseded

Internally, those labels are not one linear truth score. PlotWarden tracks several dimensions independently:

A claim may therefore be verified but unratified, ratified but stale, well-sourced but inapplicable, or historically intact but currently revoked.

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.

PlotWarden does not pretend it can instantaneously rewrite every distributed consumer. Instead, the control plane atomically commits a poison epoch and the known affected set. Any worker, result, or merge candidate that has not reconciled beyond that epoch is forbidden from committing. Consumers may learn of the correction asynchronously, while the commitment fence preserves the safety property. Newly discovered consumers are appended to the affected set through later versioned events.

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.

Suppose a reproducible benchmark then showed that a candidate simulation-architecture revision could not meet the relevant performance budget.

That benchmark should update the Evidence-Backed Reality Graph. It may dispute the candidate's 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.

Authority must also make progress. Low-risk, reversible changes may be automatically ratified under a narrowly scoped, versioned policy. Medium-risk changes may be delegated to a named owner and expire if the underlying epoch moves. Product-goal, security-sensitive, irreversible, or destructive changes may require stronger review or quorum. Every approval binds the proposal hash, scope, epoch, verifier results, budget where relevant, and expiration. Timeouts trigger escalation, safe degradation, or cancellation rather than indefinite fleet-wide blocking.

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?
• Which source or actor governs the affected desired-state scope?
• 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. Copying worker-derived material into a manager-owned store does not grant it authority.
5. Model confidence and self-explanation are not evidence.
6. The Evidence and Command Ledger is the canonical mutation history; graphs are versioned, rebuildable projections.
7. Workers cannot mutate protected state.
8. The CLI proxy is not the sole security boundary; capabilities, credentials, egress, and protected permissions enforce authority.
9. Killed or stale output is quarantined.
10. Unknown dependencies trigger conservative tainting, broader invalidation, retesting, or review, not invented precision.
11. Freshness validation and official commitment are one atomic versioned operation.
12. Every consequential side effect is attributable, versioned, and independently idempotent; reversible effects have compensation paths.
13. A poisoned claim commits a poison epoch and affected set; consumers behind that epoch cannot commit.
14. Uncertainty blocks official commitment, not harmless local exploration.
15. Human decisions bind to an exact proposal and are rechecked before execution.
16. A passing build is evidence, not authority.
17. The latest ratified authority record wins only within its relevant scope.
18. Authoritative source changes become official only as scoped, versioned intent deltas.
19. Superseded intent is retained and linked to its successor; history is never silently erased.
20. Projection disagreement, replay failure, or graph-root mismatch blocks protected commitment.

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.