Uptake Integrity Protocol

A constitution for constructing, testing, revising, and retiring LTP claims

Version: 0.1 Status: Proposed method; suitable for pilot use, criticism, and revision Primary purpose: To make Logical Thinking Process artifacts function as versioned, empirically answerable models rather than persuasive diagrams

---

1. Purpose

The Logical Thinking Process produces structured claims about:

• why a current reality persists;
• which conflict or assumption is pivotal;
• what intervention may dissolve it;
• what future effects should follow;
• what obstacles must be overcome;
• and what sequence of actions should be taken.

These claims are often hypotheses, even when they are displayed identically to observations or settled conclusions.

The Uptake Integrity Protocol, or UIP, gives those claims an explicit lifecycle:

Conjecture → logical challenge → probation → evidential uptake → verdict → revision → retention

The protocol is designed so that:

1. every pivotal claim can be challenged;
2. there is some possible evidence that could count against it;
3. disconfirming consequences can survive the route from observation to record;
4. criticism can alter the tree;
5. revisions propagate through dependent trees;
6. the goal or ideal can itself be reviewed;
7. the protocol’s own usefulness remains testable.

The protocol builds on the distinction between consequences and evidence, the four-stage account of evidential uptake, and the definition of losability as a complete route from representable alternative to implementable revision.

---

Part I — Foundations

2. The basic commitment

An LTP tree is not reality.

It is a provisional model containing different kinds of claims, with different levels of support, connected by explicit logical relationships.

A tree is healthy when it can:

• represent relevant resistance;
• generate serious alternatives;
• expose its claims to discriminating consequences;
• preserve those consequences through uptake;
• allow them to count against incumbent claims;
• revise the affected structure;
• retain warranted revisions over time.

A tree is not made losable merely by declaring that it is revisable.

It is losable only when its actual operating arrangements make revision possible.

---

3. The two crossings

The protocol distinguishes two crossings.

3.1 The descent

A model of reality leads to an intervention:

Interpretation → proposed action → action → consequence

The main danger on the descent is abductive closure:

• only one explanation is considered;
• assumptions are treated as facts;
• the favored injection is selected before rivals are articulated;
• the tree is used to justify an intended action.

3.2 The ascent

Consequences return and become evidence:

Consequence → selection → classification → attribution → registration → verdict

The main danger on the ascent is uptake closure:

• relevant consequences are not observed;
• observations are classified only in categories favorable to the model;
• results are attributed away;
• records are lost, rewritten, or stripped of provenance;
• evidence is preserved but not allowed to affect the tree.

The two crossings meet at surprise.

A consequence that the current tree cannot adequately explain should not merely be patched into an existing branch. It should be capable of reopening the hypothesis space.

The theory of ideal-directed conduct describes change as a recurrent relationship among an ideal orientation, a model of the current loop, an admissible action, and an uptake-and-revision architecture.

---

4. Losability

A claim is losable when there exists an admissible course of inquiry under which:

1. an alternative can be represented;
2. a probe or observation can distinguish the incumbent claim from a rival;
3. the distinction survives evidential uptake;
4. the evidence may count against the incumbent;
5. an authorized revision can alter the tree;
6. dependent claims are reconsidered;
7. the revision can persist.

For a pivotal claim ( \theta ), define the losability profile:

[ L_\theta = \langle V_\theta, A_\theta, D^X_\theta, D^E_\theta, C_\theta, R_\theta, K_\theta, G_\theta \rangle ]

where:

If a necessary element is zero, the claim cannot lose through that route.

More feedback elsewhere does not repair a severed link.

---

Part II — Objects Governed by the Protocol

5. The Losable Tree System

A Losable Tree System consists of eight linked records:

1. Ideal Charter
2. Tree Set
3. Claim Registry
4. Dependency Graph
5. Test Contracts
6. Evidence Ledger
7. Decision and Revision Log
8. Retention Register

The visible trees remain important, but they are no longer the whole model.

---

6. The Ideal Charter

Before diagnosing the current system, the team records the orientation under which “improvement” is being judged.

The Ideal Charter contains:

6.1 Direction

What would count as movement toward a better form of reality?

This may be expressed through:

• a goal;
• necessary conditions;
• critical success factors;
• qualities of conduct;
• a viable region rather than a fixed target.

6.2 Protected floors

What may not be sacrificed through an ordinary improvement step?

Examples include:

• safety;
• dignity;
• autonomy;
• legal rights;
• environmental limits;
• non-deception;
• continuity of essential service;
• protected stakeholder needs.

6.3 Standing

Who may:

• contribute observations;
• challenge the goal;
• reject an interpretation;
• propose a rival ideal;
• stop a probe;
• appeal a verdict?

6.4 Revision procedure

What evidence or criticism may cause the ideal itself to be:

• clarified;
• broadened;
• reordered;
• narrowed;
• or rejected?

The Goal Tree is treated as a provisional representation of the ideal, not as an infallible statement of it. The ideal-directed theory explicitly includes a procedure by which the orientation itself may be criticized and revised.

---

7. Claim types

Every entity, arrow, connector, assumption, injection, and objective must be assigned a claim type.

7.1 Observation claim

Condition E exists, occurred, or recurs.

Examples:

• Orders are frequently delivered late.
• Users abandon the process at the verification step.
• Managers withhold incident information.

Required support:

• operational definition;
• observation method;
• source;
• time range;
• affected scope;
• uncertainty.

---

7.2 Classification claim

Observation X is properly described as category C.

Example:

These events are instances of avoidable rework.

Classification claims are distinct from observation claims because the event may be real while the category is disputed.

---

7.3 Causal contribution claim

A contributes causally to B under conditions C.

This is weaker than sufficiency.

Example:

Frequent priority changes contribute to delayed completion.

---

7.4 Sufficiency claim

A, or A together with stated co-conditions, is sufficient to produce B within the defined scope.

Example:

When all required data are available and the approval rule is clear, automated validation is sufficient to prevent this class of incomplete submission.

---

7.5 Necessity claim

B cannot be achieved or sustained without A.

Example:

Reliable release decisions require current production-state visibility.

Necessity should not be inferred merely because A is one known route to B.

---

7.6 Additional-cause claim

B may also arise through D independently of A.

This claim protects against over-attribution.

---

7.7 Conflict claim

D and D′ cannot both be performed or sustained under current conditions.

The apparent incompatibility must be tested, not presumed.

---

7.8 Need claim

B or C is genuinely necessary for the common objective A.

Cloud needs are treated as claims, not protected automatically from challenge.

---

7.9 Assumption claim

Relationship R holds because assumption H is believed to be true.

An assumption may function as:

• a forecast;
• a classification;
• a valuation;
• an authorization rule;
• a feasibility belief;
• a protected interest;
• an institutional doctrine.

The conduct theory treats an LTP assumption as a candidate representation of a component of an operative code, rather than identifying every assumption with one underlying psychological mechanism.

---

7.10 Intervention claim

Introducing I will alter a pivotal condition or invalidate assumption H.

An injection is not evidence.

It is a proposed intervention that may have:

• steering value;
• inquiry value;
• both;
• or neither.

---

7.11 Transition claim

Given current condition S, action X should produce expected intermediate effect Y.

Transition claims are suitable for direct probation.

---

7.12 Risk claim

Intervention I may produce undesirable consequence N.

Negative branches are hypotheses and require monitoring, not merely diagrammatic consideration.

---

7.13 Measurement claim

Indicator M validly represents entity E.

A tree can appear to fail when its measure fails, and appear to succeed when a proxy is gamed.

Measurement claims therefore receive their own records.

---

7.14 Normative claim

State or trajectory X is preferable, permissible, required, or forbidden.

Normative claims are not empirically falsified in the same way as causal claims.

They require:

• reasons;
• standing;
• consistency with protected floors;
• examination of affected consequences;
• legitimate review.

---

8. Epistemic statuses

Each claim receives one status.

No claim becomes “proven” under this protocol.

---

Part III — The Claim Record

9. Mandatory Claim Record

Every pivotal claim must have the following fields.

Claim ID:
Tree and location:
Claim text:
Claim type:
Owner:
Date introduced:
Current status:

Operational meaning:
Scope:
Boundary conditions:
Time horizon:
Affected groups or scales:

Supporting assumptions:
Dependent claims:
Known rivals:
Known alternative causes:

Predicted consequences:
Possible defeating consequences:
Measurement claims relied upon:

Current evidence:
Confidence rationale:
Open reservations:

Revision authority:
Next review date:

A claim is pivotal when one or more of the following is true:

• an injection depends upon it;
• it supports multiple downstream entities;
• it identifies a root cause;
• it expresses a Cloud necessity relationship;
• it determines the interpretation of the ideal;
• failure would materially alter the project;
• it carries substantial negative-branch risk.

---

10. Claim-writing discipline

Claims should be written so that they can fail.

Weak:

Better communication improves performance.

Stronger:

For teams that share work dependencies but lack a common priority view, introducing a daily shared priority review will reduce the number of tasks blocked by conflicting priority instructions within four weeks, provided that decision authority is present.

The stronger form identifies:

• population;
• condition;
• intervention;
• predicted effect;
• time;
• co-condition.

A causal arrow should ordinarily be readable as:

Given C, A is expected to contribute to or produce B within T.

---

Part IV — Logical Probation

11. Pre-empirical logical challenge

Before a claim enters empirical probation, it must be reviewed using relevant Categories of Legitimate Reservation.

The review asks:

11.1 Clarity

Are the cause and effect unambiguous?

11.2 Entity existence

Is there current reason to believe the stated entities exist?

11.3 Causality existence

Is there a defensible mechanism or causal basis?

11.4 Cause insufficiency

What other condition is required?

11.5 Additional cause

What else could produce the effect?

11.6 Cause–effect reversal

Could the supposed effect produce the supposed cause?

11.7 Predicted effect

What else should be observed if the relationship is true?

11.8 Tautology

Are cause and effect merely restatements?

11.9 Boundary failure

Under what conditions should the relationship not hold?

11.10 Scale displacement

Could the apparent improvement move harm elsewhere?

Logical admissibility does not establish empirical truth.

It establishes that the claim is coherent enough to deserve probation.

---

12. Rival requirement

A pivotal claim may not enter probation without at least one live rival, except where no credible rival can yet be formulated and that deficiency is explicitly recorded.

Rivals may include:

• another cause;
• another mechanism;
• a measurement explanation;
• a scope qualification;
• a material constraint;
• no meaningful relationship;
• a different ideal interpretation.

Example:

H₁: Delays are primarily caused by unstable prioritization. H₂: Delays are primarily caused by overloaded specialist capacity. H₃: The delay measure combines fundamentally different delay types. H₄: Both causes matter, but under different project conditions.

Rivals prevent a failed preferred hypothesis from being treated as if no alternative understanding were possible.

---

Part V — The Test Interface

13. Definition

A Test is any disciplined procedure that exposes a claim to a possible evidential loss.

Implementations include:

• observation;
• field experiment;
• controlled experiment;
• natural experiment;
• simulation;
• audit;
• software test;
• prototype;
• pilot;
• counterexample search;
• predicted-effect check;
• comparative case;
• historical analysis;
• structured stakeholder challenge.

A valid Test must specify both:

1. how the claim might receive support;
2. how it might be weakened, qualified, or defeated.

A procedure that can only confirm the claim is not a sufficient test.

---

14. Test Contract

Every test of a pivotal claim uses the following contract.

TEST CONTRACT

Test ID:
Target claim:
Claim type:
Test owner:
Decision owner:
Independent reviewer, if any:

Question:
Incumbent hypothesis:
Rival hypotheses:

Preconditions:
Boundary conditions:
Protected needs and safeguards:
Stop conditions:

Probe or observation:
Why this test discriminates:
Expected trace under incumbent:
Expected trace under rivals:

Raw traces to preserve:
Sampling plan:
Measurement method:
Time horizon:

Pre-specified uptake:
    Selection rule:
    Classification rule:
    Attribution rule:
    Registration rule:

Possible verdicts:
Defeat criteria:
Qualification criteria:
Inconclusive criteria:

Revision required for each verdict:
Dependent claims to reopen:
Appeal procedure:

---

15. Admissibility of a test

A proposed test is admissible only when:

1. it addresses a specific claim;
2. materially different results are possible;
3. at least one result could count against the incumbent;
4. relevant traces can be observed or preserved;
5. the probe does not violate protected floors;
6. risks are bounded or explicitly accepted through legitimate authority;
7. the result can reach an authorized revision process.

An injection may be useful as an improvement action while being a poor test.

A test may be informative while not immediately improving the focal outcome.

The protocol allows actions to possess both steering value and inquiry value.

---

Part VI — Evidential Uptake

16. Consequence is not evidence

A consequence becomes evidence only through uptake.

The Evidence Ledger must preserve the four stations separately.

16.1 Selection

What was:

• observed;
• sampled;
• measured;
• omitted;
• inaccessible;
• noticed only informally?

16.2 Classification

Under what description did each observation enter?

Example:

The same event may be classified as:

• non-compliance;
• inability;
• refusal;
• misunderstanding;
• system failure;
• rational resistance.

16.3 Attribution

What was the observation taken to indicate?

Possible attribution errors include:

• treating a co-produced effect as a pre-existing trait;
• explaining away disconfirmation;
• crediting the injection for a change caused elsewhere;
• blaming implementation whenever the theory fails;
• ignoring delay or interaction effects.

16.4 Registration

How was the evidence preserved?

The record should include:

• raw or minimally processed trace;
• time;
• source;
• method;
• transformation history;
• classification;
• attribution;
• dissenting interpretation;
• responsible parties.

The four-stage uptake model is essential because materially different traces can be erased or collapsed before criticism occurs.

---

17. Evidence Ledger

EVIDENCE LEDGER ENTRY

Evidence ID:
Related Test ID:
Related Claim IDs:

Raw trace:
Source:
Timestamp:
Collection conditions:
Missing data:

Selection decision:
Selected by:
Selection rationale:
Known exclusions:

Classification:
Alternative classifications:
Classifier:
Disagreement:

Attribution:
Alternative attributions:
Known confounders:
Causal warrant:

Registration location:
Version:
Provenance chain:
Access restrictions:

Affected-party observations:
Reviewer comments:

The Evidence Ledger is append-only.

Corrections are entered as new versions rather than silent replacement.

---

Part VII — Verdicts

18. Permitted verdicts

A test does not simply pass or fail.

The permitted verdicts are:

“Implementation failure” must not automatically preserve the original claim.

It generates a new testable claim:

The intervention was not implemented sufficiently to expose the target hypothesis.

---

19. Evidence strength

Evidence strength is assessed through:

• relevance to the precise claim;
• discrimination among rivals;
• severity of possible defeat;
• measurement validity;
• preserved provenance;
• repeatability or convergence;
• independence of assessment;
• scope;
• known confounding;
• risk of self-generated confirmation.

A claim should not be promoted merely because rivals were eliminated.

Promotion requires surviving an outcome it positively predicted and could have failed.

---

Part VIII — Revision Calculus

20. Revision principle

A failed or surprising result does not dictate one automatic edit.

The revision process asks:

Which component of the claim-and-test system best explains the mismatch?

The following revision operators are permitted.

---

21. Claim-level revision operators

21.1 Retain

No change beyond evidence registration.

Use when the claim survives a severe and valid probation.

21.2 Lower warrant

Keep the claim but reduce reliance.

Use when the evidence is adverse but not decisive.

21.3 Add a boundary condition

Change:

A causes B

to:

A causes B when C is present.

21.4 Add a co-condition

Change:

A is sufficient for B

to:

A and C together are sufficient for B.

21.5 Add an alternative cause

Add:

D can also produce B.

21.6 Split the entity

Change a broad entity into more precise subtypes.

Example:

“Delay” becomes “queue delay,” “approval delay,” and “rework delay.”

21.7 Change the time relation

Add:

• delay;
• duration;
• decay;
• threshold;
• sequence.

21.8 Change scope

Restrict or differentiate:

• population;
• context;
• scale;
• system state;
• operating regime.

21.9 Revise measurement

Preserve the underlying claim while replacing or qualifying its indicator.

21.10 Reverse causality

Replace:

A causes B

with:

B contributes to A,

or introduce a reinforcing loop.

21.11 Remove the arrow

Use when the causal connection is no longer warranted.

21.12 Remove the entity

Use when the entity does not exist, has no operational meaning, or adds no explanatory value.

21.13 Replace the mechanism

Preserve a high-level relationship while revising why it is believed to hold.

21.14 Reopen abduction

Use when no live hypothesis explains the evidence.

This is mandatory after a confirmed second-order surprise.

21.15 Revise the injection

Use when the diagnosis remains warranted but the intervention does not reach the pivotal condition.

21.16 Revise the ideal

Use when:

• improvement under the existing ideal causes protected harm;
• affected parties expose a missing necessary condition;
• the goal becomes incoherent;
• success would make an illegitimate system more effective.

---

22. Revision decision tree

When evidence conflicts with a claim, proceed in this order:

Step 1 — Did the target condition occur?

If no:

• classify as implementation or exposure failure;
• test whether the intended action was instantiated;
• do not treat the original causal claim as tested.

Step 2 — Were relevant consequences physically distinguishable?

If no:

• the probe was suppressive or non-discriminating;
• redesign the probe.

Step 3 — Did uptake preserve the distinction?

If no:

• repair selection, classification, attribution, or registration;
• reacquire evidence where possible.

Step 4 — Was the measurement valid?

If no:

• revise the measurement claim;
• withhold verdict on the causal claim.

Step 5 — Did the evidence differ from the incumbent prediction?

If no:

• assess whether it also differed from rivals;
• distinguish strong support from mere compatibility.

Step 6 — Can a missing condition explain the mismatch?

If yes:

• add or test the candidate condition;
• avoid ad hoc protection by requiring independent probation.

Step 7 — Does a rival explain the evidence better?

If yes:

• favor the rival provisionally;
• revise the affected branch.

Step 8 — Does no live hypothesis explain the evidence?

If yes:

• register second-order surprise;
• reopen abduction.

Step 9 — Does the result challenge the goal or protected floors?

If yes:

• initiate Ideal Review before continuing implementation.

---

Part IX — Dependency-Aware Updating

23. Dependency Graph

Every claim records its dependencies.

A dependency exists when:

• one claim is used to infer another;
• an injection is justified by an assumption;
• an intermediate objective is justified by an obstacle;
• a Transition Tree action relies on an FRT prediction;
• a metric operationalizes an entity;
• a branch supports the selected constraint or core problem;
• a normative condition justifies a desired effect.

The dependency graph spans the entire tree set.

---

24. Impact levels

When a claim changes, all dependents receive an impact status.

---

25. Propagation rules

25.1 Observation revision

If a foundational UDE is withdrawn or split:

• review its causal ancestors;
• review common-cause claims inferred partly from it;
• review whether it remains relevant to the Goal Tree.

25.2 Root-cause revision

If a CRT root cause is weakened or defeated:

• suspend injections chosen primarily to remove it;
• reopen the related Cloud;
• review the FRT branch;
• review PRT obstacles and Transition Tree actions tied to it.

25.3 Cloud-assumption revision

If an assumption is invalidated:

• review whether the conflict evaporates;
• assess whether D or D′ remains necessary;
• generate alternative actions;
• revise the FRT.

25.4 Injection revision

If an injection is defeated:

• retain the diagnosis unless separately challenged;
• reopen solution generation;
• suspend implementation branches dependent upon it.

25.5 FRT-arrow revision

If an FRT arrow is weakened:

• suspend all downstream desired-effect claims whose only support passes through that arrow;
• review negative branches that may now dominate;
• revise measurements and transition actions.

25.6 Ideal revision

If the ideal changes:

• review all desired and undesirable labels;
• review the Goal Tree;
• reassess core-problem relevance;
• reclassify negative branches;
• reconsider project continuation.

---

Part X — Governance

26. Roles

A minimally governed Losable Tree process distinguishes the following roles.

26.1 Model builder

Constructs and maintains the tree.

26.2 Claim owner

Responsible for the clarity and status of a claim.

26.3 Test designer

Designs the probe or observation.

26.4 Trace custodian

Preserves raw consequences and provenance.

26.5 Uptake reviewer

Reviews selection, classification, attribution, and registration.

26.6 Adjudicator

Issues the verdict.

26.7 Revision authority

Has power and resources to alter the model or conduct.

26.8 Affected-party representative

Brings consequences, categories, and ideal challenges from those who bear effects.

26.9 Protocol auditor

Examines whether the process itself remained losable.

One person may hold multiple roles in low-risk work, but role concentration must be declared.

---

27. Double-role controls

The same effective code should not silently control:

• the intervention;
• the measurement;
• the classification;
• the attribution;
• the verdict;
• and the revision.

Where full separation is impractical, use:

• pre-registration;
• preserved raw traces;
• rival interpretations;
• append-only records;
• explicit appeal;
• external review;
• rotating adjudication;
• independent sampling;
• affected-party standing.

The objective is not perfect independence.

It is sufficient structural separation that the model can receive an unwelcome answer.

---

28. Appeal

Any substantive participant may appeal a verdict on one or more grounds:

• relevant evidence was excluded;
• classification was contestable;
• attribution exceeded the evidence;
• a rival was not considered;
• the test violated its contract;
• the decision rule changed after the outcome;
• the revision did not propagate;
• protected floors were violated;
• the ideal lacked legitimate standing.

Appeals are themselves entered in the Evidence and Decision Ledgers.

---

Part XI — The Workflow

29. Phase 1: Charter

Produce:

• Ideal Charter;
• protected floors;
• standing and governance;
• project scope;
• initial stop conditions.

---

30. Phase 2: Construct

Build the relevant:

• Goal Tree;
• CRT;
• Cloud;
• FRT;
• PRT;
• Transition Tree.

At this stage, visually distinguish:

• observations;
• conjectures;
• assumptions;
• measurements;
• normative entities;
• tested claims.

---

31. Phase 3: Register

Create Claim Records for pivotal entities and connections.

Assign:

• type;
• status;
• owner;
• dependencies;
• rivals;
• open reservations.

---

32. Phase 4: Challenge

Apply logical reservations.

A claim that fails clarity or logical admissibility is revised before empirical testing.

---

33. Phase 5: Select pivotal claims

Prioritize claims by:

[ P = \frac{ \text{systemic leverage} \times \text{uncertainty} \times \text{consequence of error} \times \text{testability} }{ \text{cost} \times \text{risk} } ]

This is a decision aid, not a universal scalar.

Claims that are highly consequential and weakly supported should normally be tested earlier.

---

34. Phase 6: Contract the test

Complete the Test Contract before observing the decisive result where feasible.

---

35. Phase 7: Act and acquire traces

Execute the probe or observation.

Preserve:

• deviations;
• implementation fidelity;
• contextual changes;
• adverse events;
• excluded data;
• unexpected effects.

---

36. Phase 8: Perform uptake

Complete the four uptake stations explicitly.

Do not collapse raw consequence into verdict.

---

37. Phase 9: Adjudicate

Compare:

• incumbent prediction;
• rival predictions;
• actual evidence;
• boundary conditions;
• measurement validity;
• negative branches;
• affected-party reports.

Issue one permitted verdict.

---

38. Phase 10: Revise

Apply the revision calculus.

Record:

• old claim;
• new claim;
• reason;
• evidence IDs;
• responsible authority;
• affected dependencies.

---

39. Phase 11: Propagate

Run the dependency review.

No revised claim is considered fully processed until dependent claims have been:

• confirmed;
• revised;
• suspended;
• or invalidated.

---

40. Phase 12: Retain

Update:

• procedures;
• training;
• system configuration;
• incentives;
• ownership;
• recurring review;
• memory;
• governance.

A changed diagram without changed conduct is not a completed revision.

---

41. Phase 13: Review the ideal

Ask:

• Did the intervention produce improvement under the intended ideal?
• Were protected floors preserved?
• Did affected parties reveal omitted consequences?
• Did the meaning of success change?
• Did the project improve the wrong thing?
• Should the Goal Tree be revised?

---

Part XII — Tree-Specific Use

42. Current Reality Tree

The CRT is treated as an abductive causal model.

Required additions:

• evidence record for every UDE;
• explicit distinction between observed entities and inferred causes;
• rivals for root-cause claims;
• predicted effects not used to construct the tree;
• scope and boundary conditions;
• additional-cause analysis.

A strong CRT test asks:

What else should be observed if this root cause truly explains the UDE pattern?

---

43. Evaporating Cloud

Every arrow receives assumptions.

The protocol tests separately:

• Is B necessary for A?
• Is C necessary for A?
• Is D necessary for B?
• Is D′ necessary for C?
• Are D and D′ genuinely incompatible?
• Does the proposed injection invalidate an assumption?
• Does it preserve both needs?

A Cloud is considered evaporated only when the conflict changes in conduct, not merely when an assumption is verbally challenged.

---

44. Future Reality Tree

The FRT is treated as a prospective causal simulation.

Every major arrow records:

• co-conditions;
• predicted timing;
• observable effects;
• defeating evidence;
• negative branches;
• measurement claims.

The FRT does not prove that an injection will work.

It identifies what should be observed if the theory of change is adequate.

---

45. Prerequisite Tree

Each obstacle is a claim:

Obstacle O prevents objective X.

Each intermediate objective is also a claim:

Achieving IO is sufficient to remove or bypass O.

The protocol asks:

• Is the obstacle real?
• Is it material, interpretive, political, or capability-based?
• Does the IO actually remove it?
• Does another obstacle become binding?
• Who has authority and resources to act?

---

46. Transition Tree

Each transition step is expressed as:

Given need N and current condition S, action A should produce expected effect E because rationale R holds.

The expected effect becomes an immediate test target.

A Transition Tree step is not complete when the action is performed.

It is complete when:

• the expected effect is observed;
• uptake is valid;
• the next condition is available;
• adverse consequences remain within bounds.

---

Part XIII — Closure Audit

47. Closure modes

At each review, examine the following.

---

48. The closure question

Every pivotal claim review ends with:

Under what possible registered consequences would this claim change?

If the honest answer is:

None that this process permits, recognizes, or acts upon,

the claim is not currently losable.

---

Part XIV — Minimal Operational Artifacts

49. Minimal packet

For lightweight use, maintain five pages or records:

Page 1 — Ideal Charter

• direction;
• necessary conditions;
• protected floors;
• standing;
• end-revision rule.

Page 2 — Pivotal Claim Register

• claim;
• type;
• status;
• rivals;
• dependencies.

Page 3 — Test Contract

• prediction;
• defeating result;
• probe;
• uptake;
• decision rule.

Page 4 — Evidence and Verdict

• trace;
• uptake;
• rival interpretations;
• verdict.

Page 5 — Revision Delta

• old tree;
• changed claims;
• propagated impact;
• retained conduct change.

---

50. Visual notation

Recommended markings:

The notation should reveal epistemic differences that ordinary trees often hide.

---

Part XV — Protocol Metrics

51. Process measures

The protocol may be evaluated through:

• proportion of pivotal claims with rivals;
• proportion with explicit defeat conditions;
• proportion with valid Test Contracts;
• percentage of evidence entries preserving raw traces;
• number of uptake disagreements surfaced;
• time from disconfirming evidence to tree revision;
• percentage of revisions propagated through dependencies;
• number of second-order surprises registered;
• rate of reversion after revision;
• number of ideal revisions;
• proportion of affected-party challenges receiving formal disposition.

---

52. Outcome measures

Potential outcome measures include:

• predictive accuracy of FRT branches;
• reduction in repeated diagnostic failure;
• proportion of injections that reach their pivotal assumptions;
• earlier detection of negative branches;
• improvement persistence;
• decision quality under changed conditions;
• reduction in post hoc explanation;
• appropriate narrowing of claims;
• reduced reliance on unsupported root causes;
• protected-floor compliance.

More revision is not automatically better.

The objective is more warranted revision.

---

Part XVI — Making the Protocol Itself Losable

53. Meta-hypothesis

The protocol’s central empirical contention is:

LTP practiced through the Uptake Integrity Protocol will produce more accurate, corrigible, transparent, and durable change models than competent conventional LTP or simpler evidence extensions, without imposing disproportionate cost or harming legitimate action.

This contention remains in probation.

---

54. Rivals

The research portfolio includes:

M₁ — Conventional sufficiency

Competent conventional LTP already provides adequate correction.

M₂ — Minimal extension

LTP needs only explicit evidence and version-control records, not the full protocol.

M₃ — Rival integration

Another framework provides a better basis for empirical revision.

M₄ — Domain restriction

The protocol adds value only in reflexive human systems and not in primarily technical systems.

M₅ — Complexity harm

The protocol reduces practical effectiveness through administrative burden.

M₆ — Sophisticated closure

The vocabulary gives practitioners additional means to explain away failure.

---

55. Protocol defeat conditions

The foundational claim should be narrowed, demoted, or rejected if repeated comparative use shows that:

• the protocol does not improve detection of incorrect pivotal claims;
• revisions are more frequent but not more accurate;
• a simpler evidence record produces equivalent gains;
• users cannot reliably distinguish claim types;
• uptake stages do not yield practically distinct diagnoses;
• independent review adds no corrective value;
• dependency propagation creates cost without preventing error;
• the method systematically delays low-risk action;
• affected-party standing becomes symbolic rather than consequential;
• the protocol increases post hoc rationalization;
• benefits occur only under unusually expert facilitation;
• conventional LTP or a rival method performs better;
• the method strengthens harmful systems by improving their learning without adequate normative correction.

---

56. Comparative pilot design

A pilot should compare:

Cases should vary by:

• technical versus reflexive;
• individual versus organizational;
• single-scale versus multi-scale;
• low versus high uncertainty;
• reversible versus high-risk intervention.

Assessment should include:

• independent review;
• pre-specified criteria;
• preserved case records;
• prediction scoring;
• revision appropriateness;
• implementation burden;
• durability;
• legitimacy.

---

Part XVII — Worked Example

57. Initial FRT claim

C-104: Giving users a real-time status dashboard will reduce support requests.

Type: Causal contribution claim Status: Proposed

Supporting assumptions

• users know the dashboard exists;
• users trust its data;
• the dashboard answers the questions that trigger support contact;
• using the dashboard is easier than contacting support;
• support requests are mainly information-seeking.

Rivals

• R1: requests are driven by anxiety rather than missing information;
• R2: users need action, not visibility;
• R3: the status categories are too coarse;
• R4: dashboard users are a different population from callers;
• R5: support requests are caused by process failures upstream.

---

58. Test Contract

Probe: Release the dashboard to a bounded user cohort.

Incumbent prediction:

• dashboard usage increases;
• information-seeking support contacts decrease;
• total support contacts decrease within six weeks.

Defeating result:

• dashboard usage is substantial;
• data are current;
• information-seeking calls do not decrease;
• users report that the dashboard does not answer the question relevant to their job.

Raw traces:

• dashboard events;
• support-contact reason;
• contact transcripts;
• user interviews;
• system status;
• cohort characteristics.

Pre-specified classification:

Support contacts are classified as:

• information request;
• exception resolution;
• reassurance;
• dispute;
• action request;
• technical failure.

---

59. Result

The dashboard is used frequently.

Information requests fall slightly, but total support contacts do not fall because users contact support to obtain action on exceptions.

---

60. Verdict

Qualified and rival favored.

The claim:

Real-time status visibility reduces support requests

is replaced by:

Real-time status visibility reduces information-seeking contacts when the displayed categories answer the user’s decision question, but it does not reduce contacts requiring intervention.

Rival R2 is favored.

---

61. Tree revision

Old branch

Dashboard exists → users know status → support requests decrease → support load decreases

Revised branch

Dashboard exists AND status categories answer decision questions → information-seeking contacts decrease

Separately:

Exceptions remain unresolved → action-seeking contacts remain high

New injection candidate

Provide a bounded self-service exception-resolution path.

Dependency impact

• original support-capacity projection suspended;
• staffing transition plan reviewed;
• negative branch concerning unauthorized user action added;
• Goal Tree condition refined from “users can see status” to “users can determine and perform the next legitimate action.”

The failed broad claim produces a more precise model rather than a cosmetic box rearrangement.

---

Part XVIII — Practitioner Checklists

62. Before accepting a pivotal claim

Ask:

1. What type of claim is this?
2. What exactly does it mean?
3. What observations support it?
4. What rivals exist?
5. What would we expect if it were true?
6. What would count against it?
7. Can those consequences occur under current conduct?
8. Can we observe and preserve them?
9. Who determines what they mean?
10. Who can revise the tree?

---

63. Before performing an injection

Ask:

1. Which claim does the injection expose?
2. Does it steer, discriminate, or both?
3. Could materially different outcomes occur?
4. What protected needs must remain satisfied?
5. What negative branches require monitoring?
6. What traces must be preserved?
7. What verdicts are possible?
8. What revision follows each verdict?
9. Can the intervention be stopped or reversed?
10. Does authority exist to act on the result?

---

64. After surprising evidence

Ask:

1. Did the target condition actually occur?
2. Was the result measured validly?
3. Was relevant evidence excluded?
4. Was it classified appropriately?
5. Was it attributed away?
6. Did a boundary condition fail?
7. Is another cause active?
8. Does a rival explain the result?
9. Is the hypothesis space exhausted?
10. Does the ideal need review?

---

Conclusion

The Uptake Integrity Protocol treats the Logical Thinking Process as a disciplined system of provisional claims.

Its core constitution is:

No pivotal claim may govern consequential action unless its type, warrant, rivals, possible defeat, evidence path, revision authority, and dependencies are visible.

The protocol separates:

• observation from classification;
• causal logic from empirical warrant;
• consequence from evidence;
• evidence from verdict;
• verdict from revision;
• revision from retention;
• improvement from legitimacy.

It gives each LTP claim a lifecycle:

Proposed → clarified → challenged → placed in probation → exposed to consequences → taken up as evidence → adjudicated → revised or retained

And it imposes one final requirement on the method itself:

The protocol must be operated under conditions in which evidence can show that it is unnecessary, inadequate, too costly, too narrow, or inferior to a rival.

That is what converts the LTP from a collection of persuasive logical trees into a maintained system of inquiry capable of losing—and therefore capable of learning.