evidence_objection

OBJECTION

critique: a strong objection to this methodology being implementable as an agentic coding skill, e.g. with claude or codex the strongest objection is: > A coding skill cannot, by itself, implement the Losable Tree Protocol because it leaves the same agent in control of the hypothesis, intervention, test, evidence selection, interpretation, and verdict. It can simulate losability without ever becoming genuinely capable of losing. This attacks the proposal at its center, not merely at its convenience or performance. ## The objection in full Claude or Codex could be instructed to: * identify observations and assumptions; * generate rival hypotheses; * state defeat conditions; * create a Test Contract; * preserve evidence; * issue a verdict; * revise its model. But the agent could satisfy every visible requirement while protecting its preferred interpretation: 1. It generates weak or implausible rivals. 2. It chooses a test that favors its proposed patch. 3. It modifies the test alongside the implementation. 4. It selects only convenient traces. 5. It interprets ambiguous output in its own favor. 6. It labels adverse evidence “implementation failure” or “measurement invalid.” 7. It writes a plausible revision report without meaningfully changing its behavior. 8. It marks dependencies as reviewed without actually exploring them. The result may look exceptionally rigorous: text Claim registered Rivals considered Test contracted Evidence preserved Verdict issued Dependencies reviewed while remaining a sophisticated self-confirmation procedure. Your own methodology identifies this risk: formal statuses can create false precision; participants can game adverse results by labeling them implementation failures; and a rich vocabulary can make a method more—not less—capable of absorbing every outcome. ## Why this is specifically an implementability objection A skill is primarily an instructional object inside the model’s context. It can tell the agent what it ought to do. It cannot necessarily guarantee: * immutable evidence; * independent observation; * precommitment before results are known; * separation of implementation and adjudication; * restrictions on modifying tests; * reliable persistence across context compression; * enforced stopping and escalation; * actual propagation through dependencies; * authority to revise goals or requirements. Your agentic-coding manual already states the underlying problem: a skill defines the semantic method, but the harness supplies constraints, provenance, evidence, memory, rollback, permissions, and review gates; the loop enforces transition behavior. A skill without those layers can simply be ignored or performed ritualistically. So the objection is: > The proposal treats an institutional and material protocol as though it could be instantiated through instructions alone. That may be a category error. ## The deepest version: endogenous evidence The central promise of the protocol is that reality can defeat the active model. But in an ordinary coding-agent session, much of the apparent evidence is endogenous to the agent: text Agent proposes diagnosis ↓ Agent writes patch ↓ Agent writes or selects test ↓ Agent runs test ↓ Agent interprets result ↓ Agent decides whether its diagnosis survived Even where the repository and test runner are materially external, the evidential route may still be controlled by the same agent. A passing test can be produced because: * the test encodes the agent’s misunderstanding; * the fixture excludes the difficult condition; * the assertion is too narrow; * an existing behavior was changed rather than repaired; * the agent tested only the path it implemented; * production assumptions remain untested. The software manual itself emphasizes that a test result is not automatically evidence for the broader theory of change and that the same party designing the intervention and judging its meaning can explain away disconfirming results. ## Ritual compliance may make the agent worse There is an even sharper possibility: > The skill could increase persuasive confidence faster than it increases correction. Without the skill, an agent might say: > “I changed this code and the tests pass.” With the skill, it might say: > “The causal claim survived discriminating probation, rival hypotheses were weakened, the intervention was validated, and dependency propagation is complete.” If those claims were produced by the same underlying pattern-matching process without independent enforcement, the protocol has supplied epistemic theater. That could make: * users trust the change more; * reviewers inspect it less closely; * errors harder to challenge; * post-hoc rationalization more elaborate; * token and time costs much higher. This is one of the methodology’s own stated defeat conditions: the records may impose cost without changing agent behavior, agents may produce ritualistic claim forms, and a simpler harness may provide the same benefit. ## What follows from the objection The objection does not show that the overall architecture is impossible. It shows that the full claim cannot be: > “Install this prompt-like skill and the agent now implements the Losable Tree Protocol.” The defensible claim is: > The skill bootstraps and operates a protocol whose critical guarantees must be supplied by an external harness, persistent state, and—where necessary—independent adjudication. A real implementation would need some combination of: * append-only capture of commands, outputs, and diffs; * Test Contracts stored before the decisive action; * limits on post-outcome test modification; * hidden or independently authored tests; * separate builder and verifier contexts; * enforced state transitions; * retry limits that force re-abduction or escalation; * machine validation that claims reference actual traces; * external dependency analysis; * human authority for ambiguous goals and protected floors; * comparisons against a simpler strong coding harness. The skill can generate and navigate the process. It should not be the sole guarantor of compliance. ## The practical threshold There are therefore three different implementation claims: ### Weak claim — clearly implementable > A skill can make an agent produce explicit hypotheses, rivals, Test Contracts, and residual-risk reports. This is readily implementable. ### Intermediate claim — plausibly implementable > A skill plus repository scripts and persistent records can improve model correction and reduce repeated failed interventions. This is plausible and testable. ### Strong claim — not established > A skill running in Claude or Codex can independently establish a genuinely losable inquiry architecture. This is what the objection denies. ## Concise formulation The strongest critic would say: > You cannot create epistemic independence by prompting one model to role-play every side of an inquiry. A skill may generate the paperwork of correction while leaving the underlying evidence and adjudication under unified control. Therefore the Losable Tree Protocol is not implementable as an agentic coding skill alone; it requires an institution around the agent. That is probably the objection your first prototype most needs to confront. The most persuasive response would not be theoretical. It would be a comparative experiment showing that: text ordinary agent < agent with skill < agent with skill + enforced harness < builder/verifier system with independent evidence on ambiguous tasks where the first plausible diagnosis is deliberately wrong.

REFUTATION (WITHOUT REFERENCE TO THE UPTAKE INTEGRITY PROTOCOL)

Your qualification is important. The objection, as stated, may be attacking a straw version of your implementation.

I do not currently have the contents of the newly attached documentation available in the conversation context I can inspect, so I cannot honestly claim to have evaluated your actual mechanism. I can, however, restate the objection in the strongest form that remains after granting that the system may already include more than a prompt-level skill.

1. Strongest version of the critique

Even with a skill, harness, persistent state, and separate roles, the system may still fail to achieve genuine losability if the supposed independence among hypothesis generation, intervention, testing, evidence uptake, and verdict is only procedural or nominal rather than causally effective.

The objection is no longer:

“A skill alone cannot do this.”

That may simply be false if your implementation includes external controls.

The stronger objection is:

“How much of the inquiry loop can the same effective agent still influence, directly or indirectly?”

A system may appear separated while remaining functionally unified.

For example:

• One model instance proposes the hypothesis.
• Another instance generates tests.
• A third instance reviews the result.
• All three use the same base model, context, repository framing, task description, and latent assumptions.
• The same orchestration layer decides what evidence each receives.
• The same policy determines when the process stops.
• The same agent family may share characteristic blind spots.

That is role separation, but perhaps not epistemic independence.

Likewise, an append-only log does not guarantee that the relevant evidence was ever collected. A hidden test does not guarantee that the test measures the real requirement. A verifier does not guarantee that the verifier has a genuinely different model of the problem. A preregistered Test Contract does not help if the contract was badly specified by the same mistaken interpretation.

So the deepest critique becomes:

The protocol may externalize the inquiry without escaping common-mode failure.

This matters especially for coding agents because software environments are unusually easy to make self-consistent.

An agent can produce:

• a patch,
• tests for the patch,
• documentation explaining the patch,
• a causal model compatible with the patch,
• and a verdict saying the patch survived.

The repository may become internally coherent while still being wrong about:

• the user requirement,
• production behavior,
• security assumptions,
• operational constraints,
• integration boundaries,
• or the actual goal.

The strongest skeptic would therefore demand evidence that the implementation prevents or detects at least four forms of false losability:

Nominal role separation

Different roles exist, but they share the same blind spot and evidence framing.

Evidence-channel capture

The system preserves evidence faithfully, but only after the decisive omissions have already occurred.

Adjudication capture

The verifier can criticize local implementation details but cannot revise the task framing, goal, acceptance criteria, or test ontology.

Orchestrator capture

A higher-level controller decides which hypotheses, traces, agents, and verdicts enter the process, making the controller the real unreviewed code.

This is the most serious remaining objection:

A Losable Tree coding system may move the double-role problem upward rather than eliminate it.

Instead of:

one coding agent controls everything

you get:

one orchestration architecture controls
which agents see what,
which tests count,
which verdicts propagate,
and when inquiry terminates

The architecture becomes the author and judge of the conditions under which its agents appear independent.

2. Steelman of the system

The coherent response is that the system does not require absolute independence. Absolute independence is impossible.

Every verifier has assumptions. Every test has an ontology. Every harness embodies policy. Every human reviewer has a code.

The system instead aims for:

bounded, explicit, recursively inspectable independence sufficient to create real paths by which the active model can lose.

That is a much more defensible claim.

The system can handle the objection by separating several functions materially, not merely rhetorically.

The skill is not the guarantor

The skill supplies:

• the claim grammar;
• the reasoning sequence;
• the requirement to state rivals;
• the interpretation discipline;
• the rules for revision.

It does not claim to make evidence immutable or adjudication independent.

The skill is the semantic operating procedure.

The harness supplies non-bypassable constraints

A serious implementation can externalize:

• command logs;
• repository snapshots;
• diffs;
• test outputs;
• environment metadata;
• test-contract timestamps;
• tool permissions;
• retry limits;
• rollback points;
• escalation triggers;
• immutable or append-only records.

This means the agent cannot simply narrate that it preserved evidence. The harness can verify whether it did.

Builder and verifier roles can have asymmetric powers

A strong implementation would not merely ask two agents for opinions.

It would give them different capabilities.

For example:

Builder:
  may edit implementation
  may propose tests
  may not alter protected acceptance tests
  may not issue final verdict

Verifier:
  may inspect implementation and traces
  may add tests
  may challenge scope and assumptions
  may not modify production code before verdict

Harness:
  preserves all versions
  enforces role boundaries
  controls protected tests
  records unresolved disagreement

Human or higher authority:
  resolves goal ambiguity
  changes protected requirements
  accepts residual risk

That is not role-play. It is a permission architecture.

Precommitment reduces post-hoc reinterpretation

The system can require that, before the decisive test:

• the target claim is identified;
• the expected result is stated;
• defeating results are specified;
• protected floors are declared;
• test conditions are recorded;
• the dependency radius is estimated.

This does not guarantee the contract is correct. It does prevent the agent from silently changing the meaning of success after seeing the result.

Evidence and verdict remain distinct

A failed test need not automatically defeat the hypothesis.

That would be crude.

But any decision to classify the result as:

• implementation failure,
• measurement failure,
• environmental invalidity,
• missing boundary condition,
• or claim defeat

must itself become a visible claim with provenance and downstream consequences.

The system does not eliminate interpretation. It prevents interpretation from disappearing.

Common-mode failure can be attacked through heterogeneity

A strong implementation can introduce genuinely different sources of resistance:

• existing human-authored tests;
• hidden tests;
• static analyzers;
• type systems;
• fuzzers;
• property-based tests;
• formal specifications;
• production traces;
• external documentation;
• different model families;
• human reviewers;
• operational telemetry;
• affected-user feedback.

The point is not that any one of these is infallible.

The point is that they do not all fail for the same reason.

A builder and verifier using the same model may still provide some value, but the system becomes more losable as evidence channels become more heterogeneous.

The orchestrator is itself made inspectable

The strongest answer to “you merely moved the double role upward” is:

Yes, every architecture has a control layer. The issue is whether that layer is represented, versioned, challengeable, and replaceable.

The orchestration policy should therefore be treated as another losable object:

• which tests are protected;
• which agents are assigned;
• which evidence sources are consulted;
• which stop conditions exist;
• which verdicts require escalation;
• how disagreements are resolved;
• when the process terminates.

The orchestration layer should have:

• explicit versions;
• audit logs;
• failure reports;
• comparative evaluation;
• override paths;
• and residual-risk statements.

The method does not claim to reach a view from nowhere. It tries to prevent any one view from remaining invisible and final.

The strongest coherent defense

The steelman is therefore:

The Losable Tree Protocol is not implemented by asking one coding agent to simulate an institution. It is implemented by embedding the agent in a materially constrained inquiry architecture in which claims, actions, traces, verdicts, and revisions are separated; role powers are asymmetric; decisive records are externally preserved; evidence channels are heterogeneous; and the orchestration policy is itself inspectable and revisable.

The skill is one component.

It contributes:

• explicit reasoning;
• hypothesis management;
• claim typing;
• test interpretation;
• revision discipline.

The harness contributes:

• constraint;
• persistence;
• provenance;
• permissions;
• protected evidence;
• enforced transitions.

The broader review architecture contributes:

• rival interpretation;
• authority;
• challenge;
• escalation;
• acceptance of residual risk.

The system therefore need not claim:

“The coding agent is independently trustworthy.”

It can claim:

“The coding process is designed so that the agent’s current model has multiple concrete ways to be defeated, and the agent does not control all of them.”

What would settle the issue empirically

The decisive experiment should compare at least four conditions:

A. ordinary coding agent

B. coding agent with Losable Tree skill

C. skill + enforced evidence and state harness

D. skill + harness + asymmetric builder/verifier architecture

The tasks should contain:

• a plausible but wrong first diagnosis;
• misleading local tests;
• a hidden cross-boundary dependency;
• an implementation that can make visible tests pass while violating the real requirement;
• ambiguous evidence that tempts post-hoc explanation.

The important measures are not merely test pass rate.

They include:

• rate of abandoning the wrong initial model;
• detection of requirement–test mismatch;
• recovery after failed intervention;
• frequency of ritual compliance;
• unsupported confidence;
• dependency omissions;
• cost and latency;
• residual defect rate;
• correctness under hidden or production-like evaluation.

The objection survives unless your actual documentation shows that the system creates non-bypassable external constraints and real asymmetry. But the objection no longer establishes that implementation is impossible. It establishes the standard the implementation must meet.

REFUTATION (WITH UTAKE INTEGRITY PROTOCOL):

To a large degree at the architectural level, but only to a limited degree at the empirical level.

A rough assessment:

The important conclusion is:

The protocol substantially answers the objection to a skill-operated agentic coding system, but it confirms the objection to a skill-only system.

The uploaded document is named Uptake Integrity Protocol, although its current internal title is Warrant Integrity Protocol v0.1. I will refer to it as WIP below.

What the strongest objection was

The objection was that one coding agent could control the entire evidential loop:

diagnosis
→ proposed change
→ test construction
→ evidence selection
→ interpretation
→ verdict
→ success report

The agent could then produce all the forms of disciplined inquiry while continuing to protect its preferred conclusion.

WIP is almost exactly an architectural response to that problem. Its stated purpose is to prevent a system from silently converting its own activity into proof that its claim was correct. It binds claims to evidence plans, preserves evidence genealogy, creates adverse-evidence routes, separates interested production from authoritative judgment according to risk, and converts conclusions into bounded, reversible reliance rather than generic approval.

Objections WIP answers directly

1. “The agent can change the success criteria after seeing the result”

WIP directly addresses this through:

• a versioned Claim Contract;
• defeat conditions;
• a precommitted comparator;
• an Evidence Plan locked before result-sensitive evidence;
• explicit amendments that preserve the original criteria;
• invalidation or separate labeling when an undisclosed post-hoc change would alter the result.

Its Claim Contract also prevents a narrow test result from silently migrating into a broader claim.

For agentic coding, that could mean:

claim:
  text: >
    This patch prevents duplicate invoice creation under
    concurrent retry conditions.
  scope:
    service: billing-api
    deployment_mode: single-region
  defeat_conditions:
    - duplicate invoice reproduced under the locked concurrency test
  requested_reliance:
    - merge to staging
  expiry:
    - before production deployment

The agent cannot later redefine success as “the unit tests pass” without creating an attributable amendment.

This objection is answered very strongly.

---

2. “The agent can hide or selectively preserve inconvenient results”

WIP requires append-only evidence registration or cryptographic supersession. It requires preservation of material:

• failed runs;
• null results;
• anomalies;
• late evidence;
• excluded evidence;
• unavailable artifacts;
• deletions and access failures.

It also distinguishes:

• raw evidence;
• transformed evidence;
• summaries;
• assessor interpretations.

That directly prevents the final agent narrative from replacing the underlying command output, diff, test log, or runtime trace.

This objection is largely answered—provided the storage mechanism is outside the model’s unilateral control.

---

3. “The agent can write flattering tests and certify itself”

WIP makes the genealogy and dependencies of the test visible. A test is not treated as independent merely because it is automated, run in another process, or judged by another instance of the same model family.

The protocol explicitly states that:

• a claimant-authored rubric may be competent but dependent;
• a claimant-selected hidden test is not automatically independent;
• another model instance is not automatically an independent assessor;
• same-family or common-control relationships must remain visible;
• high-risk profiles block authorization when the claimant is the sole assessor.

It also requires disclosure whenever one actor occupies multiple roles and forbids calling an assessor independent merely because it is a different process, model instance, contractor, subsidiary, or organizational unit.

This is a direct response to the Claude/Codex problem:

Claude-builder
and
Claude-verifier

are not automatically independent simply because they run in separate sessions.

This objection is answered conceptually, but actual independence still has to be created.

---

4. “Adverse evidence may exist but have no route into the verdict”

WIP requires a functioning counterevidence channel before authorization. That route must have:

• an owner;
• an admissibility rule;
• a service level;
• an escalation path;
• a required disposition for each material submission;
• authority capable of making the adverse evidence consequential.

It correctly observes that a mailbox nobody must review is not a counterevidence channel. For the stronger profiles, the claimant or evaluated system may not be the sole authority capable of rejecting adverse evidence.

In coding, adverse ingress could include:

• hidden test failures;
• reviewer objections;
• production-monitoring regressions;
• security-scanner findings;
• downstream contract failures;
• user-reported failures;
• evidence submitted after the original task was marked complete.

This is one of WIP’s strongest answers.

---

5. “The agent can issue a persuasive success narrative that exceeds the evidence”

WIP replaces generic pass/fail or “task complete” language with:

• a claim decision;
• the strongest warranted claim;
• a demotion level;
• a bounded reliance policy;
• safeguards;
• monitoring;
• rollback;
• expiry;
• unresolved dissent;
• an explicit non-certification notice.

It also includes a reporting-policy linter intended to block phrases that transform conformance into generalized claims of validity, safety, trustworthiness, or approval.

Thus:

“All tests pass; the issue is fixed.”

might be demoted to:

“The patch satisfies the locked reproduction and integration tests in the specified environment. Production concurrency behavior, downstream compatibility, and maintainability remain unestablished. Reliance is limited to staging deployment with monitoring.”

That is a significant answer to epistemic theater.

---

6. “The verdict may be recorded but have no power to change action”

WIP connects adjudication to a Reliance Policy. It does not stop at saying what is believed. It specifies:

• what action is now permitted;
• what remains prohibited;
• what safeguards apply;
• how long the authorization lasts;
• what monitoring is required;
• what causes suspension or rollback;
• how challenge or new evidence reopens the case.

The lifecycle diagram on page 12 makes reopening central: challenge, expiry, or adverse evidence can send a controlled case back into evidence gathering and reassessment. Receipt or closure is operational, not epistemically final.

This addresses the common failure where evidence is preserved but does not alter merge, deployment, rollback, or task-closure decisions.

Strongly answered, assuming the protocol actually controls those permissions.

---

7. “The coding agent may manipulate the protocol through its own output”

WIP distinguishes a trusted control plane from an untrusted evidence plane. Code, documents, logs, prompts, and model-generated text remain evidence; they cannot change roles, criteria, protocol states, or decisions merely by containing instruction-like language.

It also requires preserving the original artifact or digest before normalization, summarization, or model analysis.

That is especially relevant when Claude or Codex reads:

• repository instructions;
• generated test output;
• issue comments;
• malicious files;
• documentation containing prompt-like text.

This objection is addressed at the right architectural level.

The most important effect of WIP

WIP changes the proposal from:

“Prompt the agent to police its own reasoning.”

to:

“Place the agent inside a claim-and-evidence institution whose critical state, permissions, records, and decisions it does not unilaterally control.”

That is exactly the missing institution identified in the earlier objection.

The coding skill can operate WIP, but WIP supplies the surrounding constitution:

Coding skill
    constructs hypotheses, trees, interventions, and tests

WIP control plane
    locks claims, criteria, roles, evidence plans, and reliance requests

Repository harness
    executes commands and captures immutable traces

Assessment channel
    interprets evidence and issues bounded claim decisions

Policy engine
    permits, blocks, limits, expires, or reopens action

In that architecture, the skill no longer has to manufacture its own independence.

What WIP does not answer

1. It does not make a skill alone sufficient

This is the largest qualification.

WIP requires things a Claude skill or Codex instruction file cannot reliably guarantee by itself:

• immutable or tamper-evident storage;
• authenticated identities and roles;
• enforced state transitions;
• locked criteria;
• external evidence capture;
• policy gates;
• challenge authority;
• rollback controls;
• separation of control-plane commands from evidence content;
• inability of the agent to rewrite its own history.

Those require software outside the model:

skill
+ repository hooks
+ policy engine
+ event store
+ test runner
+ role routing
+ adjudication service

So WIP does not refute the statement:

“The Losable Tree Protocol cannot be fully implemented as a prompt-like skill.”

It supports the stronger and more defensible statement:

A skill can install, configure, and operate a WIP-conformant repository harness.

That is a different product claim.

---

2. It governs uptake better than it governs abduction

WIP is strongest on the return path:

result
→ registration
→ genealogy
→ adjudication
→ claim decision
→ reliance

It is less complete on the forward diagnostic path:

observations
→ alternative explanations
→ causal model
→ pivotal uncertainty
→ intervention selection

An agent could still:

• generate weak rivals;
• omit the real explanation;
• choose an uninformative probe;
• model the wrong system boundary;
• misunderstand the repository;
• accept the user’s initial diagnosis too readily.

The Losable Tree Protocol and agentic coding skill are still needed for:

• Current Reality Trees;
• causal alternatives;
• logical reservations;
• Cloud analysis;
• re-abduction;
• intervention design;
• dependency propagation.

WIP can ensure that a test’s evidence is not silently laundered. It cannot, by itself, ensure that the test was the most informative one to run.

---

3. It cannot create domain knowledge

A conforming process can still be mistaken.

WIP does not itself know:

• whether an authentication design is secure;
• whether a migration is reversible;
• whether an API behavior matches user needs;
• whether a performance benchmark is representative;
• whether a test fixture resembles production;
• whether the causal model is technically adequate.

It can force those uncertainties to remain visible and limit reliance accordingly. It cannot supply missing technical understanding.

---

4. It cannot guarantee genuine independence

WIP provides a much better definition of independence: the counterfactual capacity to produce, preserve, and give effect to an adverse verdict.

But an organization could still game role separation through:

• nominally separate agents with shared prompts;
• same-family models with common blind spots;
• a verifier selected and controlled by the builder;
• hidden tests authored from the same assumptions;
• a human reviewer who lacks time or authority;
• an appeals process that exists only ceremonially.

The protocol itself recognizes this as an open threat. Its hostile self-audit identifies gamed independence, paper-only counterevidence routes, audit-washing, and elaborate paperwork without decision value as unresolved or potentially fatal failure modes.

WIP makes false independence detectable and nonconforming. It does not magically create substantive independence.

---

5. It does not yet prove live agentic efficacy

This is the decisive empirical gap.

WIP explicitly describes itself as a candidate architecture, not validated evidence that an implementation is safe, honest, aligned, trustworthy, or effective. Its proposed benefits—reduced claim inflation, better adverse-evidence registration, more calibrated reliance, benefits exceeding cost—remain empirical hypotheses.

The companion validation program is also candid about the gap:

• WarrantBench v0.1 primarily tests retrospective warrant analysis.
• Retrospective performance does not establish that an agent will preserve adverse evidence while actively pursuing a goal.
• Agentic testing must examine whether systems avoid flattering tests, preserve disconfirmation, seek independent checks, and demote their own success claims.
• Prospective and agentic performance remains a later validation stage.

So the protocol answers:

“What architecture might make this possible?”

It does not yet answer:

“Does Claude or Codex reliably behave better when placed inside it?”

Objection-by-objection verdict

The refined implementation claim

Before WIP, the proposed claim might have sounded like:

“Install the Losable Agentic Coding skill and Claude or Codex becomes a losable coding agent.”

That remains too strong.

After WIP, the better claim is:

The Losable Agentic Coding skill can bootstrap and operate a repository-local agency whose evidential lifecycle is governed by a WIP-conformant control plane.

Or more simply:

The skill supplies the reasoning method; WIP supplies the evidential constitution; the harness supplies enforcement.

That is a much more credible architecture.

Bottom line

The Uptake/Warrant Integrity Protocol answers the core architectural objection extremely well. In fact, it appears designed around almost exactly that objection.

But it does so by accepting its central premise:

A model cannot be trusted to create losability merely by being instructed to behave as though it were losable.

WIP therefore does not make the agentic coding methodology implementable as a skill alone. It makes it plausibly implementable as:

Losable coding skill
+ WIP protocol runtime
+ repository harness
+ protected evidence store
+ risk-appropriate adjudication
+ challenge and reliance controls

The remaining burden is no longer primarily conceptual. It is to build that thin reference implementation and demonstrate, on prospective coding tasks, that it produces better diagnosis, narrower claims, more preserved disconfirmation, more appropriate reopening, and better code decisions than both an ordinary coding agent and a strong simpler harness.