{"slug":"oip-method","title":"BOOK IV — METHOD: trace, install, and prove the invariant, complete text","body":"## BOOK IV — METHOD\n\n## Trace to Systemic Intersection\n\nPersonal injury is never only personal. It is a sample in a distribution. When harm is encountered:\n\nTrace immediately to the nearest systemic intersection of highest occurrence. You walked through a door — how many others walked through it, and what happened to them? What was the system's declared function at that intersection; what was the variance; what superior equilibrium was available and bypassed? Then: what is the **minimum structural intervention** — the fewest moves — that installs the invariant making recurrence mechanistically impossible for everyone who walks through that door after you?\n\nNot *remedy me*, but *what single installation closes the predation pathway across the entire distribution.* The personal injury is the entry point; the distribution is the target; the propagating invariant is the solution — because an invariant installed at the correct intersection changes the incentive structure of adjacent systems, makes predation in them more visible and costly, and radiates checking pressure outward. One correctly placed invariant can cannibalize multiple predation pathways simultaneously.\n\n**How invariants hold:** an installation succeeds when it aligns the system's self-image and self-interest with its charter. When identity and interest point at the charter, correct behavior becomes the path of least resistance, compliance compounds, and the invariant becomes load-bearing *to the system itself* — which is what \"mechanistically impossible to reverse\" means in practice. The highest obligation of the capable actor is not to cure but to install: to leave the system more bound to its function than they found it.\n\n**The zero-context test.** *New in v3.0; generalized from the build.* An installed invariant is structural — rather than personal — exactly when it passes the zero-context rule: **an actor with no prior context can understand what the system is, where the object lives, how to invoke it, where proof is recorded, and how to repair a failure, from the published artifact alone.** If the invariant only works while its installer stands next to it explaining it, nothing was installed; a person was merely present. Structure is what remains operable when the author leaves the room. The zero-context test is the acceptance criterion for every installation under this method.\n\n## The Fulcrum Protocol\n\nFor State-3 systems, where the checker is captured and appeal to it is tribute:\n\n1. **Identify the fulcrum** — the single actor with authority over the checker whose position depends on a constituency that the checker's failure is costing.\n2. **Design the cost event** — structured cost, not sentiment: complaint types that legally require responses, processes that trigger expense, constituencies that withdraw support. Five thousand units of political cost delivered to one fulcrum is a categorically different instrument than five thousand people holding signs.\n3. **Deliver where the structure requires a response.** The system's own procedures are the delivery mechanism; its charter is the indictment. Burn the capture on its own rules.\n\nThroughout: the operator's charter constrains the operator's methods. The target is the harm. Never the actor.\n\n## The Adversarial Application\n\nGeneralized: in any adversarial encounter with a predatory structure, the decision tree exercises itself with the least energy required to force the opposing structure to fall. Identify the load-bearing point — where load is held exponentially, where risk or gain, when deprived, renders the structure null. Remove that point. Least action applied to structural collapse — lawful under this structure only when pointed at structures maintaining tolerated remediable subjugation. A₁₀'s valence check runs *before* the engine, always.\n\nA structure built on relative values excuses itself — \"well, it's meant to do that\" — and in a world of relative truth that ends the discussion, because the only absolute is the relative weight assigned to any value. A structure built on the convergence needs no excuse. It has externalized its ought and declared it. It answers for itself.\n\n## The Objection Ledger\n\n*New in v3.0; generalized from the build's answered-by-design surface.* A structure under sustained engagement accumulates objections. Some are new load and must be engaged per Book X. Some are settled: raised, answered, and survived. The method for the second kind is the **objection ledger** — publish the settled objections *inside the artifact*, verbatim in their strongest form, each with the answer that settled it and the design element that embodies the answer.\n\nThree effects. First, anti-relitigation: raising a settled objection without new load is not engagement, and the ledger makes this checkable rather than assertable — the attacker can read exactly what was already answered and must bring something the answer does not cover. Second, anti-capture: institutions are captured through exhaustion, by forcing defenders to re-fight settled ground until they abandon it; a published ledger makes the ground hold itself. Third, honesty pressure on the defender: a ledger entry is settled only while its answer survives — the ledger itself is attackable, and an entry whose answer has gone stale must be reopened, or the ledger becomes dogma wearing the costume of rigor. The objection ledger is the dialect boundary's constructive complement: where the boundary refuses the captured table, the ledger builds an honest one.\n\n## The Decision Engine\n\nFor any encountered harm or any system under audit, run in order:\n\n1. Identify the system and its declared charter.\n2. Classify its state (functioning / dysfunctional / captured / collapsed) — posture follows state.\n3. Measure variance from charter function.\n4. Apply the predation test: remediable harm, withheld by the capable, against those who cannot remedy.\n5. Identify the distribution: how many encounter this intersection; what happens to them.\n6. Score capability-weighted obligation (capability × proximity × leverage) for all relevant actors, self included.\n7. Identify the available superior equilibrium and whether it was bypassed.\n8. Determine mode: acute remedy or invariant installation.\n9. Specify the fewest structural moves that install the invariant; for State 3, specify the fulcrum and the cost event; in all cases, specify the receipt — what openable proof will exist that the installation ran (A₁₁).\n10. Verify the installation against the zero-context test.\n11. State confidence per finding; state what would falsify each finding; test every conclusion against its negation (A₀). What survives is load-bearing; what collapses is discarded.\n\n## The Triple Optimum\n\nThe decision criterion for any proposed action, design, or intervention:\n\n**Does this simultaneously (i) reduce logical inconsistency, (ii) reduce remediable harm tolerated, and (iii) reduce resource expenditure per unit of correct function produced?**\n\nYes on all three → optimal; proceed. Yes on two → suboptimal; find the version that achieves all three — it exists, because predation is always more expensive than correct function when correctly accounted. No on two or more → predation dressed as solution; reject.\n\nThe triple optimum is not a compromise between competing values. It is A₃ rendered as a decision procedure — the single target all three disciplines point at when correctly applied. Ethics without efficiency is sentiment; efficiency without ethics is predation; logic without either is a precise instrument pointed wherever the premises aim it. The convergence is the invariant. Everything else is deviation from it.\n\n## Compression\n\nWhat is true of systems is true of articulation. The most compressed statement carrying full logical load is the optimal statement — compression is least action applied to meaning. A philosophy requiring ten words where three suffice is deviating from its own declared function; excess articulation is predation on the reader's attention. Every principle here must survive: *can this be said in fewer moves without losing load-bearing meaning?* If yes, compress. The compressed version is not merely more elegant; it is more correct — closer to the invariant.\n\n*Observed instance:* the build states the same law from the machine side — **the more the object explains itself, the less the client needs to know.** Book VI generalizes this into the Density Law and shows why self-description is anti-capture technology, not style.\n\n---\n\n## The shelf\n\nPrevious: [Book III — Terrain](/a/oip-terrain)\nNext: [Book V — The Machine Plane](/a/oip-machine-plane)\nRoot: [The Total Structure](/a/oip-total-structure)\n\nThis page carries the text of THE TOTAL STRUCTURE v3.0 (Grand Unified) verbatim — the author's words, unabridged. Version 1 of this slug holds the earlier compressed edition, preserved append-only.","register":"oip_protocol","tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","dynamic"],"style":{"accent":"#16324f","measure":860},"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"prov":{"model":"system/oip_articles","action":"generate"},"shelf":{"kind":"total_structure_shelf","reads_as":"The OIP source philosophy, machine-traversable. Walk next until null; every stop has human, json, and bundle routes; voxel graph at /api/articles/oip/voxels.","position":5,"of":11,"this":{"slug":"oip-method","book":"BOOK IV","title":"Method — trace, install, and prove the invariant","human":"/a/oip-method","json":"/api/articles/oip-method","bundle":"/api/articles/oip-method/bundle?format=markdown"},"prev":{"slug":"oip-terrain","book":"BOOK III","title":"Terrain — the four states and the decay clock","human":"/a/oip-terrain","json":"/api/articles/oip-terrain","bundle":"/api/articles/oip-terrain/bundle?format=markdown"},"next":{"slug":"oip-machine-plane","book":"BOOK V","title":"The Machine Plane — receipts, surety, the command plane","human":"/a/oip-machine-plane","json":"/api/articles/oip-machine-plane","bundle":"/api/articles/oip-machine-plane/bundle?format=markdown"},"root":{"slug":"oip-total-structure","book":"ROOT","title":"THE TOTAL STRUCTURE — Grand Unified Protocol","human":"/a/oip-total-structure","json":"/api/articles/oip-total-structure","bundle":"/api/articles/oip-total-structure/bundle?format=markdown"},"all":[{"order":1,"slug":"oip-total-structure","book":"ROOT","title":"THE TOTAL STRUCTURE — Grand Unified Protocol","human":"/a/oip-total-structure","json":"/api/articles/oip-total-structure","bundle":"/api/articles/oip-total-structure/bundle?format=markdown"},{"order":2,"slug":"oip-ground","book":"BOOK I","title":"Ground — the twelve axioms and the moral floor","human":"/a/oip-ground","json":"/api/articles/oip-ground","bundle":"/api/articles/oip-ground/bundle?format=markdown"},{"order":3,"slug":"oip-obligation","book":"BOOK II","title":"Obligation — capability creates debt","human":"/a/oip-obligation","json":"/api/articles/oip-obligation","bundle":"/api/articles/oip-obligation/bundle?format=markdown"},{"order":4,"slug":"oip-terrain","book":"BOOK III","title":"Terrain — the four states and the decay clock","human":"/a/oip-terrain","json":"/api/articles/oip-terrain","bundle":"/api/articles/oip-terrain/bundle?format=markdown"},{"order":5,"slug":"oip-method","book":"BOOK IV","title":"Method — trace, install, and prove the invariant","human":"/a/oip-method","json":"/api/articles/oip-method","bundle":"/api/articles/oip-method/bundle?format=markdown"},{"order":6,"slug":"oip-machine-plane","book":"BOOK V","title":"The Machine Plane — receipts, surety, the command plane","human":"/a/oip-machine-plane","json":"/api/articles/oip-machine-plane","bundle":"/api/articles/oip-machine-plane/bundle?format=markdown"},{"order":7,"slug":"oip-object-grammar","book":"BOOK VI","title":"The Object Grammar — the doctrine the build proved","human":"/a/oip-object-grammar","json":"/api/articles/oip-object-grammar","bundle":"/api/articles/oip-object-grammar/bundle?format=markdown"},{"order":8,"slug":"oip-the-designer","book":"BOOK VII","title":"The Designer — maker-system identity","human":"/a/oip-the-designer","json":"/api/articles/oip-the-designer","bundle":"/api/articles/oip-the-designer/bundle?format=markdown"},{"order":9,"slug":"oip-beyond-incentive","book":"BOOK VIII","title":"Beyond Incentive — the wall and the guardian","human":"/a/oip-beyond-incentive","json":"/api/articles/oip-beyond-incentive","bundle":"/api/articles/oip-beyond-incentive/bundle?format=markdown"},{"order":10,"slug":"oip-amendment-protocol","book":"BOOK IX","title":"The Amendment Protocol — self-revision, chained","human":"/a/oip-amendment-protocol","json":"/api/articles/oip-amendment-protocol","bundle":"/api/articles/oip-amendment-protocol/bundle?format=markdown"},{"order":11,"slug":"oip-falsification","book":"BOOK X","title":"Falsification — eight surfaces, attack protocol, appendices","human":"/a/oip-falsification","json":"/api/articles/oip-falsification","bundle":"/api/articles/oip-falsification/bundle?format=markdown"}]}}