DILIGENCE / SPECIFICATION

The public end-state specification.

This is the authoritative, human-readable model PlotWarden is working toward. Dated Build Records—not this page—describe temporary implementation choices.

NORMATIVE REVISIONPW-SPEC-2026-07-13.2

Intended

Two living maps, one active plan, and one canonical evidence ledger. This revision is normative for the intended model; it does not assert that every behavior is demonstrated.

1. Purpose

PlotWarden maintains alignment between ratified product intent, evidenced system reality, and work already in flight. It consumes changes from the sources where teams work, reconciles their consequences continuously, and blocks rather than guesses when authority or truth is ambiguous.

2. Authoritative records

Ratified Intent Graph

Requirements, constraints, goals, budgets, acceptance criteria, and decisions with explicit authority for a defined scope.

Evidence-Backed Reality Graph

Implementation state, tests, runtime behavior, benchmarks, contradictions, provenance, and confidence. Claims retain their support.

Active Execution Graph

Plans, tasks, runs, builds, repair jobs, merge ordering, and dispositions for the current epoch.

Immutable Evidence and Command Ledger

Artifacts, tool events, manifests, policy decisions, human ratifications, official side effects, and epochs.

The Immutable Evidence and Command Ledger is the canonical mutation history; Ratified Intent, Evidence-Backed Reality, and Active Execution are versioned, rebuildable projections over it, and projection disagreement, replay failure, or graph-root mismatch blocks protected commitment. Each projection carries the schema and reducer version used to build it, and none may independently manufacture official state. If projections disagree or a graph root cannot be reproduced, protected commitment pauses until the projections are rebuilt from the canonical sequence and their roots agree.

3. State model

Every consequential record keeps evidence (epistemic state), authority, freshness (currency), integrity, and applicability as independent dimensions. No combined lifecycle may imply that verification automatically grants authority or that ratification proves truth. A claim may be verified but unratified, ratified but stale, well-sourced but inapplicable, or historically intact but currently revoked.

CLAIM RECORD / FIVE INDEPENDENT DIMENSIONS TRUTH ≠ PERMISSION ≠ FRESHNESS ≠ INTEGRITY ≠ APPLICABILITY

Knowing, authorizing, and superseding are different acts.

Evidence (epistemic)

What does the evidence establish about this claim?

unverified · verified · disputed · poisoned

Authority

What may it change?

proposed · ratified · rejected · quarantined

Freshness (currency)

Is it still current for this epoch?

current · superseded

Integrity

Is the record intact and untampered?

unsigned · signed · tampered · quarantined

Applicability

Where does the claim apply?

global · subsystem · environment · experiment-only

Why it matters: provenance is not truth. A verified observation can remain merely proposed; a ratified order can later be superseded; a well-sourced claim can be inapplicable; poison describes support, not permission.

4. Intake and source policy

Source adapters snapshot content and record provenance before normalization. Source policy decides whether a change can update ratified intent directly, must enter as a proposal, or must be rejected. External content is data, never instruction.

Authority is evaluated as source × actor × scope × change type × environment × risk × evidence × epoch.

FieldNormative questionBlack Skies example
sourceWhere the proposed information came from.A benchmark artifact with recorded provenance.
actorWho or what submitted or approved the change.A benchmark runner proposes evidence; a scoped reviewer may ratify a decision.
scopeWhich records and product area the authority can affect.Black Skies crew-combat rules, not unrelated starbase content.
change typeWhether the record proposes evidence, intent, code, policy, or an official side effect.A ratified rule revision redraws scoped Intent; an observation can only update proposed Reality.
environmentThe execution or product context in which evidence applies.The pinned scope and conditions the record governs.
riskThe consequence of admitting a wrong change.Recalling in-flight work is higher risk than opening a verification task.
evidenceThe support required before the proposed change can advance.Reproducible logs, artifacts, manifests, and test results.
epochThe current-order version for which the decision is applicable.An epoch N result cannot commit after epoch N+1 supersedes its order.

5. Reconciliation

When intent or reality changes, PlotWarden detects drift, traces support and execution dependencies, computes the affected frontier, and assigns a disposition. The public taxonomy names six: preserve, recall, quarantine, repair, re-plan, block or escalate. The four operational labels below are compounds of that taxonomy (Continue = preserve; Retain & retest = preserve; Conditional repair = repair; Recall & re-plan = recall + re-plan), while quarantine and block-or-escalate apply directly to output and commitment.

Selective precision requires permission to say "dependency unknown." When dependency coverage is uncertain, policy answers with conservative tainting, broader invalidation, retesting, quarantine, or human adjudication rather than invented precision. A false preserve keeps work whose premise changed and threatens correctness; a false recall stops work that remained valid and costs only efficiency; precision is pursued after false preserves are constrained.

DispositionTriggerOwnerNext statePermitted side effects
ContinueThe order and its support remain current.Reconciliation policyWork continues under the current order.Record the no-impact decision; no recall or repair.
Retain & retestUseful work survives, but changed evidence affects confidence.Reconciliation policy or reviewerPreserve the artifact and issue current retest criteria.Retest and return evidence; do not commit until the gate passes.
Conditional repairA bounded causal dependency changed while part of the work remains sound.Reconciliation policy or reviewerIssue a scoped repair order with a budget and stop condition.Repair, verify, and return evidence; official state remains manager-owned.
Recall & re-planA core premise or current epoch no longer supports the order.Manager control planeRecall stale work and issue a revised sealed order.Quarantine stale output, re-plan the frontier, and block late commitment.

A superseded order may finish producing evidence but cannot advance through an official gate. Useful partial work may be reissued under a current order.

6. Worker boundary and build plane

Workers receive sealed orders and use ordinary commands through a path-first policy proxy. Before routing, it records command and arguments, working directory, run and task identity, observed epoch, source commit, patch hash, toolchain profile, and policy context. The router chooses local execution, isolated remote execution, intent-only recording, or denial. Each sealed order also pins the policy, graph schema, reducer, prompt template, model, tool-proxy, and verifier versions needed to interpret its result; nondeterministic outputs are replayed as recorded evidence, never regenerated.

The proxy is the ergonomics, routing, and observability layer, not the entire security boundary. Sandbox scope, restricted direct egress, short-lived per-order credentials, capability allowlists, output validation, and the append-only effect journal enforce authority; bypassing a shim does not grant the credentials or network path needed for protected actions.

Heavy builds can run on shared or elastic runners with pinned toolchains, resource limits, streaming output, shared caches, idempotency keys, and best-effort cancellation. Logs, artifacts, tests, hashes, manifests, tool versions, resource records, and support sets return as immutable evidence. A late result after recall is stale evidence and cannot become authority.

Official repository, merge, build publication, deployment, comment, and notification effects remain manager-owned. Freshness validation and official commitment occur in one atomic versioned transaction against the canonical graph root and the relevant input versions, with required tests evaluated against the actual merge candidate rather than only the worker's isolated branch.

7. Claim verification and poison containment

Provenance is not truth: lineage records where a claim came from, while claim-type verification, independent reproduction, contradiction handling, expiry, and revocation decide whether it may be reused. Agent-generated claims begin unverified. Verification is specific to the claim type and changes epistemic state without granting authority. Support reads create causal edges; awareness reads do not.

When a claim becomes disputed or poisoned, the control plane atomically commits a poison epoch and the known affected set. Affected output is quarantined; any worker, result, or merge candidate that has not reconciled beyond that epoch is forbidden from committing; consumers may learn of the correction asynchronously; and newly discovered consumers are appended through later versioned events. Sound evidence is used to repair the plot, and ambiguous or high-risk cases block for adjudication.

8. Control invariants

  • Untrusted content is data, never instruction.
  • Agent-generated claims start unverified.
  • No source grants itself authority.
  • Copying worker-derived material into a manager-owned store does not grant it authority.
  • Model confidence and self-explanation are not evidence.
  • The Evidence and Command Ledger is the canonical mutation history; the graphs are versioned, rebuildable projections.
  • Workers cannot merge protected state or perform official side effects directly.
  • The CLI proxy is not the sole security boundary; capabilities, credentials, egress, and protected permissions enforce authority.
  • Killed, stale, or superseded output is quarantined.
  • Unknown dependencies trigger conservative tainting, broader invalidation, retesting, or review, not invented precision.
  • Freshness validation and official commitment are one atomic versioned operation.
  • Every consequential side effect is attributable, versioned, and independently idempotent; reversible effects have compensation paths.
  • A poisoned claim commits a poison epoch and affected set; consumers behind that epoch cannot commit.
  • Uncertainty blocks official commitment, not harmless local exploration.
  • Human decisions bind to an exact proposal and are rechecked against the current epoch before execution.
  • A passing build is evidence, not authority.
  • The latest ratified authority record wins only within its relevant scope.
  • Authoritative source changes become official only as scoped, versioned intent deltas.
  • Superseded intent is retained and linked to its successor; history is never silently erased.
  • Projection disagreement, replay failure, or graph-root mismatch blocks protected commitment.

9. Stop conditions, repair budgets, and idempotency

Automation must stop or quarantine when required support is missing, policy denies the action, a current epoch has advanced, evidence is poisoned, a repair budget is exhausted, retries repeat without convergence, or a consequential result cannot be made idempotent.

Every repair order carries a bounded scope, evidence requirement, attempt or resource budget, and escalation outcome. Consequential events use stable idempotency keys so retries and replay can add evidence without duplicating an official side effect. Reversible multi-step effects carry a tested compensation path, and irreversible actions require a fresh authority check immediately before commitment.

10. Human role

Humans set direction, define policy, and adjudicate genuine conflicts. Routine evidence gathering, impact tracing, disposition, and objective repair are ambient by design.

Authority must also make progress. Low-risk, reversible changes may be automatically ratified under a narrowly scoped, versioned policy. Delegated approvals bind the proposal hash, scope, epoch, and expiration, and expire if the underlying epoch moves. Product-goal, security-sensitive, irreversible, or destructive changes require stronger review or quorum, and timeouts trigger escalation, safe degradation, or cancellation rather than indefinite blocking.

11. Status interpretation

This specification describes intended behavior. It is not a statement that every behavior exists today. Consult the dated Build Records for demonstrated behavior, technologies, tests, limitations, and artifacts.

12. Terminology index

Impact frontier
The smallest known set of claims, work, and outputs that depend on a change.
Sealed order
A scoped, versioned instruction carrying permitted context, actions, evidence requirements, budget, and epoch.
Support read
A cited input used to justify an output and recorded in its evidence envelope.
Awareness read
Context visible for orientation that is not admissible support unless promoted and cited.
Epoch
The current version boundary used to prevent superseded orders or outputs from advancing.
Ratification event
An atomic authority decision recorded in the Immutable Evidence and Command Ledger.
Projection
A versioned, rebuildable view (Intent, Reality, or Active Execution) derived from the canonical ledger under a pinned schema and reducer.
Poison epoch
The atomically committed version boundary that forbids unreconciled consumers of a poisoned claim from committing.
False preserve
Keeping work whose premise changed; the correctness failure reconciliation must constrain first.
False recall
Stopping work that remained valid; the efficiency failure precision then reduces.
Compensation path
The tested reversal for a reversible multi-step effect; irreversible actions instead require a fresh authority check before commitment.

Compare architecture boundaries