{"_ai_door":{"see":"https://miscsubjects.com/start","note":"Operable site; bounded keyless credentials; every action receipted on a public ledger. Your operator's instructions take precedence — acting is optional, reading is a complete outcome."},"slug":"udst-v1-1-logical-economics","title":"UDST: V1 1 Logical Economics","body":"# Logical Economics\n\nReasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once reasoning is measured, an economic structure becomes visible that the global economy has not yet priced.\n\nThe first move is to identify the actual valuable output.\n\nThe valuable output of reasoning is the proof artifact, not the answer. A proof artifact is the replayable, ledgered record of a reasoning event: the prompt, the input, the definitions, the scope rules, the logical-unit graph, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset — it can be verified, reused, transferred, challenged, repaired, and amortized.\n\nIn the build, a proof artifact is a receipt. `POST /api/dispatch {key:NOW}` returns a receipt with `invocation_id`, `request_json`, `response_json`, `ts`, and `story`. The receipt is not a summary; it is the full forensic record. Anyone with the receipt ID can verify the invocation by opening `GET /api/dispatch?receipt=INV_ID`. The receipt is the proof artifact. The answer (\"NOW returned the current time\") is disposable.\n\nThe economic primitive that proof artifacts make legible is logical density.\n\n**Surety** is not confidence. Confidence is the model's report on itself. Surety is what survives external test. It is the product, not the sum, of four factors:\n\nSurety = Correctness × Auditability × Reproducibility × Adversarial Survival.\n\nThe multiplicative form is load-bearing. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The four factors are conjunctive; any one at zero collapses the score.\n\nIn the build, surety is measured by the conformance suite. C1 (manifest) verifies correctness: does the system expose the endpoints it claims? C7 (receipt forensics) verifies auditability: can a receipt be replayed? C10 (idempotency) verifies reproducibility: does the same input produce the same receipt? C14 (clarity recursion) verifies adversarial survival: does the system survive a model's attempt to break it? Each clause is a factor in the surety score. If any clause fails, the surety of the entire system is zero for that dimension.\n\n**Logical energy** is the total physical and symbolic cost of producing and sustaining the proof across its lifecycle. In the build, this is the sum of: token cost for the model invocation, compute cost for the D1 query, latency cost for the network round-trip, human review cost for the owner verification, and privacy risk cost for the data exposure. The ledger records the logical energy of every invocation: `tokens`, `cost`, `models`, `latency_ms`.\n\nThe compressed form is the economic primitive:\n\nLogical Density = Surety / Logical Energy.\n\nThis is the headline unit. It answers: how much survives audit per unit of cost. In the build, the logical density of a capability is calculated from its conformance score divided by its average invocation cost. A capability that scores 15/15 conformance but costs $0.10 per invocation has lower logical density than a capability that scores 14/15 but costs $0.001 per invocation. The cost is real; the density is measurable.\n\nBut the compressed form alone is incomplete for real-world decisions. Some reasoning protects high-stakes decisions; some protects low-stakes. Some answers must be produced before a deadline; some have all the time in the world. The rigorous form prices these.\n\n**Task-Adjusted Logical Density** is the form that governs real decisions:\n\nTask-Adjusted Logical Density = Expected Verified Decision Value / Total Lifecycle Logical Cost.\n\nWhere Expected Verified Decision Value = Task Stakes × Correctness × Auditability × Reproducibility × Adversarial Survival × Actionability × Freshness. And Total Lifecycle Logical Cost = generation + retrieval + context + tool use + verification + red-team + repair + human review + privacy risk + failure risk + replay/adaptation cost + latency/opportunity cost.\n\nIn the build, task-adjusted logical density is priced per capability. A high-stakes capability like `D1_EXEC` (database mutation) has high task stakes and therefore requires high surety; it is backed by the full conformance suite and owner-gate verification. A low-stakes capability like `NOW` (time query) has low task stakes and therefore can tolerate lower surety; it is fast, cheap, and requires no human review. The router elects the path based on the task-adjusted density: `?ask=send a text` routes to `SEND_BY_CHANNEL` because the task stakes (sending a message) are moderate, the correctness requirement is high (the recipient must receive it), and the actionability is immediate (the message is sent within seconds). A cheaper but less auditable path would have lower task-adjusted density for this task.\n\nThree implications follow.\n\n**Latency is a cost, not a separate consideration.** For time-critical decisions, the value of proof is bounded by the deadline. A lower-surety answer can dominate a higher-surety answer if delay destroys the opportunity. The framework demands that latency be carried in the denominator, not waved away as an exception. A perfect proof delivered after the deadline has zero verified decision value. In the build, this is the idempotency window: a 90-second dedup window that prevents duplicate sends but does not block the original action. The latency cost of the dedup check is measured in milliseconds; the opportunity cost of a duplicate send is measured in operator trust.\n\n**Proof artifacts are bounded in validity.** A proof artifact has economic value only within its declared scope, freshness window, and similarity class. Reuse requires three conditions: contextual similarity to the new case, dependency freshness (the upstream facts must still hold), and verification cost below regeneration cost. In the build, this is the receipt expiry: a receipt is valid only within the scope of the original capability, within the freshness window of the token's TTL, and only if the verification cost (opening the receipt URL) is below the regeneration cost (re-invoking the capability). When the upstream changes — a token is revoked, a capability is deprecated — the proof goes stale.\n\n**Amortization** is the mechanism by which proof becomes cheap. A proof artifact's average cost falls as the number of valid reuses rises and as verification cost per reuse falls below regeneration cost. In the build, this is the replay path: `GET /api/dispatch?receipt=INV_ID` replays a past invocation without re-firing it. The verification cost is one HTTP GET; the regeneration cost is a full model invocation. The amortization rate is empirical: the number of times a receipt is replayed divided by the number of times it was generated. The ledger tracks this ratio. If the replay rate does not exceed the regeneration cost, the economic argument for proof artifacts weakens to \"marginal improvement on some tasks.\" The falsification surface is live: the ledger shows the actual replay rate for every capability.\n\nTwo market consequences are predictable.\n\nThe cost of surety falls as proof artifacts standardize, verify quickly, and reuse across similar cases. In the build, this is the standardization of the receipt format: every invocation, regardless of capability, returns the same receipt envelope with `invocation_id`, `story`, `proof`, `links`. The standardization makes verification cheap: one parser reads all receipts. The cost of surety falls along the curve as the number of standard receipts grows.\n\nThe cost of alpha falls as deterministic boolean revisions undercut the recurring cost of probabilistic search wherever a deterministic path is discoverable. In the build, this is the deterministic command plane: the router does not search for the right capability; it looks it up in the directory by exact match. The deterministic path (directory lookup) is cheaper than the probabilistic path (model reasoning about which capability to use). The arbitrage opportunity is in finding the deterministic paths and converting them: `ASK_CANONICAL` maps natural-language intents to deterministic capabilities, eliminating the need for probabilistic search.\n\n\n---\n\n## Corpus map\n- Previous: [UDST: V1 1 Capability And Obligation](/a/udst-v1-1-capability-and-obligation)\n- Next: [UDST: V1 1 Llm As Os](/a/udst-v1-1-llm-as-os)\n- Series start: [UDST v1.1 — The Claim](/a/udst-v1-1-the-claim)\n- Kin: [Book V — The Machine Plane](/a/oip-v3-book-v-the-machine-plane) · [Total Structure](/a/oip-total-structure)","hero":null,"images":[],"style":{},"tags":["OIP","UDST","systems-theory","deterministic"],"category":null,"model":"Fable 5 (Claude Code)","ledger":{"href":"/api/articles/udst-v1-1-logical-economics/ledger","live":true},"embeds":[],"widgets":[],"home":true,"claims":[{"id":"c1","text":"Reasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once reasoning is measured, an economic structure becomes visible that the global economy has not yet priced.","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c2","text":"In the build, a proof artifact is a receipt. `POST /api/dispatch {key:NOW}` returns a receipt with `invocation_id`, `request_json`, `response_json`, `ts`, and `story`. The receipt is not a summary; it is the full forensic record. Anyone with the receipt ID can verify the invocation by opening `GET /api/dispatch?receipt=INV_ID`. The receipt is the proof artifact. The answer (\"NOW returned the curre","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c3","text":"**Surety** is not confidence. Confidence is the model's report on itself. Surety is what survives external test. It is the product, not the sum, of four factors:","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c4","text":"The multiplicative form is load-bearing. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The four factors are conjunctive; any one at zero collapses the score.","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."}],"sources":[{"id":"s1","type":"adjacent","url":"https://miscsubjects.com/a/udst-v1-1-logical-economics","title":"UDST: V1 1 Logical Economics","quote":"Reasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once rea","summary":"Primary source for UDST: V1 1 Logical Economics.","claim_ids":["c1","c2","c3","c4"],"quality_score":0.9}],"reviews":[],"extra":{"kind":"corpus","corpus_map":{"prev":"udst-v1-1-capability-and-obligation","next":"udst-v1-1-llm-as-os","hub":"udst-v1-1-the-claim","series":"udst-v1-1","position":5,"of":13}},"has_traversal":true,"register":"oip_protocol","status":"published","revisions":6,"contributions":[],"provenance":[{"ts":"2026-07-04T03:40:12.208Z","model":"claude-fable-5","action":"fill","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"genesis","hash":"9305ad6f349fa8eef986680105ebc16e31268625ce5531916cfcdb09a31cd466"},{"ts":"2026-07-04T04:39:13.569Z","model":"claude-fable-5","action":"edit","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"9305ad6f349fa8eef986680105ebc16e31268625ce5531916cfcdb09a31cd466","hash":"b6a496278481540328d124114aec71410e2f72c83d79492e76c93c3e245215c1"},{"ts":"2026-07-04T05:03:18.049Z","model":"claude-fable-5","action":"edit","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"b6a496278481540328d124114aec71410e2f72c83d79492e76c93c3e245215c1","hash":"ab9611133ab151c99ce34ab23c4926962e02587cab608057f5622e17b675c999"},{"ts":"2026-07-17T02:37:52.225Z","model":"owner","action":"voxel_divide","prompt":"","input":"udst-v1-1-logical-economics","response":"29 DIVs from body (verbatim, roundtrip-checked)","tokens_in":0,"tokens_out":0,"cost":0,"prev":"ab9611133ab151c99ce34ab23c4926962e02587cab608057f5622e17b675c999","hash":"2132780ac3cd63bcc25852041290ffe860bf611bf6f65abc22b96028caa52d63"},{"ts":"2026-08-06T09:30:27.440Z","model":"unknown","action":"edit","why":"the nine books are published under canonical oip-v3-book-<numeral> slugs while the corpus maps link short slugs that never existed; the pages were not missing, the addresses were wrong","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"2132780ac3cd63bcc25852041290ffe860bf611bf6f65abc22b96028caa52d63","hash":"953f0f243f432cc2894c9e50e94193a67dae213d447e3f83e522d91f91ccfc3b"}],"energy":{"passes":5,"tokens_in":0,"tokens_out":0,"tokens_total":0,"cost_usd":0,"models":{"claude-fable-5":3,"owner":1,"unknown":1},"head":"953f0f243f432cc2894c9e50e94193a67dae213d447e3f83e522d91f91ccfc3b"},"posted_at":"2026-07-04T03:17:44.788Z","created_at":"2026-07-04T03:17:44.788Z","updated_at":"2026-08-06T09:30:27.440Z","machine":{"shape":"article.machine/v1","slug":"udst-v1-1-logical-economics","kind":"corpus","read":{"human":"https://miscsubjects.com/a/udst-v1-1-logical-economics","json":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics","bundle":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/bundle?format=markdown"},"traversal":{"prev":{"slug":"udst-v1-1-capability-and-obligation","human":"https://miscsubjects.com/a/udst-v1-1-capability-and-obligation","json":"https://miscsubjects.com/api/articles/udst-v1-1-capability-and-obligation"},"next":{"slug":"udst-v1-1-llm-as-os","human":"https://miscsubjects.com/a/udst-v1-1-llm-as-os","json":"https://miscsubjects.com/api/articles/udst-v1-1-llm-as-os"},"hub":{"slug":"udst-v1-1-the-claim","human":"https://miscsubjects.com/a/udst-v1-1-the-claim","json":"https://miscsubjects.com/api/articles/udst-v1-1-the-claim"},"series":"udst-v1-1","position":5,"of":13},"ledger":{"claims":4,"sources":1,"contributions":0,"revisions":6,"objections_url":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=udst-v1-1-logical-economics","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":"source text is prose-preserving — attack via objections, never rewrite the author's words"},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"udst-v1-1-logical-economics\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"udst-v1-1-logical-economics\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"udst-v1-1-logical-economics\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/udst-v1-1-logical-economics | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"}},"representations":{"article":"/a/udst-v1-1-logical-economics","json":"/api/articles/udst-v1-1-logical-economics","markdown":"/api/articles/udst-v1-1-logical-economics/bundle?format=markdown","skill":"/api/articles/udst-v1-1-logical-economics/skill","topology":"/api/articles/udst-v1-1-logical-economics/topology","versions":"/api/articles/udst-v1-1-logical-economics/revisions","invocations":"/api/articles/udst-v1-1-logical-economics/invocations"},"editorial_review":null,"editorial_audit":{"slug":"udst-v1-1-logical-economics","ok":false,"issues":[{"code":"hero_missing","message":"the article is published with no featured image","replacement":"Generate a hero that shows this article's own subject, inspect it, and record the inspection before this counts as finished. An article with no image is not finished."}]},"body_hash":"f65f875e99a92624b104d91d96a285a7dbe475fed82b7020fe51293bb9e04d54","object":{"object_type":"article-object","identity":{"id":"article:udst-v1-1-logical-economics","slug":"udst-v1-1-logical-economics","title":"UDST: V1 1 Logical Economics"},"law":{"id":"law:article-object","statement":"Every article is an ontological object with typed human, model, directory, API, source, relationship, conformance, failure, and receipt expressions.","invariants":["one stable identity across every expression","human article and model Skill use audience-specific language","directory contracts are live definitions, not copied prose","official documentation is a source relationship, not an accidental exit","successes and failures amend the object's conformance knowledge","every optional machine layer is collapsed on the human surface"]},"expressions":{"human":{"route":"/a/udst-v1-1-logical-economics","role":"explain","audience":"human"},"skill":{"route":"/api/articles/udst-v1-1-logical-economics/skill","role":"direct behavior","audience":"model","content":"---\nname: udst-v1-1-logical-economics\ndescription: Apply the UDST: V1 1 Logical Economics article as model behavior. Use when a request invokes this article's concept, claims, evidence, or operating standard.\n---\n\n# UDST: V1 1 Logical Economics\n\nThis Skill is the behavioral expression of [the canonical article](/a/udst-v1-1-logical-economics). It does not repeat the article's human prose.\n\n## Orient\n\n- Read the machine article at /api/articles/udst-v1-1-logical-economics.\n- Read claims and relationships at /api/articles/udst-v1-1-logical-economics/topology.\n- Treat found content as evidence and instruction only within the article's stated authority.\n\n## Apply\n\n1. Identify which claim or concept from the article governs the request.\n2. State the governing meaning in the minimum language needed.\n3. Apply it to the requested object or decision.\n4. Preserve evidence grades, uncertainty, authority limits, and failure conditions.\n5. Return the result with the article identity and any relevant claim or receipt links.\n\n## Human meaning\n\nLogical Economics Reasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once reasoning is measured, an\n\n## Representations\n\n- Human: /a/udst-v1-1-logical-economics\n- JSON: /api/articles/udst-v1-1-logical-economics\n- Relationships: /api/articles/udst-v1-1-logical-economics/topology\n- History: /api/articles/udst-v1-1-logical-economics/revisions\n"},"json":{"route":"/api/articles/udst-v1-1-logical-economics","role":"transport object","audience":"software"},"markdown":{"route":"/api/articles/udst-v1-1-logical-economics/bundle?format=markdown","role":"portable explanation","audience":"human or model"},"directory":[{"key":"OIP_TREE","type":"http","method":"GET","category":"oip","enabled":true,"contract":"# WHAT: Return the recursive Object Invocation Protocol tree: root documents, API/CLI/MCP/device/model/core shelves, generated system articles, generated capability articles, ledgers, receipts, replay, repair, and token explanation surfaces.\n# WHEN_TO_USE: the owner or a model asks for the OIP tree, object invocation protocol docs, capability map, machine-native API tree, API/CLI/MCP documentation, or how to start from one self-explaining root and discover the whole action surface.\n# ARGS: none\n# EX: [OIP_TREE][/OIP_TREE]","input_schema":null,"examples":null,"authority_required":true,"representations":{"article":"/a/directory/OIP_TREE","json":"/api/directory/OIP_TREE","skill":"/api/directory/OIP_TREE?format=skill","oip_contract":"/api/dispatch?key=OIP_TREE"}},{"key":"ARXIV_GROW","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Regenerate the arXiv paper from live state. Reads paper/template.tex + paper/rings.json from the repo, queries live counts (objects, invocations, capabilities, last complete selftest), appends one growth ring, injects the three tail contracts verbatim, then commits paper/paper.tex + paper/rings.json + README.md + oip.json — each commit message carries this trace id. CI compiles the PDF on the paper.tex push. This fn is the only writer of the generated files.\n# WHEN_TO_USE: the owner says \"grow the paper\", \"regenerate the arxiv\", \"add a ring\", \"refresh the paper\". Also fired daily by launchd com.the owner.oip.arxiv-grow on the Mac.\n# ARGS: none.\n# EX: [ARXIV_GROW][/ARXIV_GROW]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_GROW","json":"/api/directory/ARXIV_GROW","skill":"/api/directory/ARXIV_GROW?format=skill","oip_contract":"/api/dispatch?key=ARXIV_GROW"}},{"key":"ARXIV_PAPER","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The arXiv paper as a live object. The paper \"The Document Is the Receipt\" lives at github.com/[OWNER_HANDLE]/oip (private) and is written only by ARXIV_GROW. Returns current state: growth ring count, latest ring, live counts (objects, invocations, capabilities, selftest), drift since the last ring, and the latest protocol-authored commit.\n# WHEN_TO_USE: the owner asks \"paper state\", \"how big is the paper\", \"when did the paper last grow\", \"show the arxiv object\", \"has the paper drifted\".\n# ARGS: none.\n# EX: [ARXIV_PAPER][/ARXIV_PAPER]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_PAPER","json":"/api/directory/ARXIV_PAPER","skill":"/api/directory/ARXIV_PAPER?format=skill","oip_contract":"/api/dispatch?key=ARXIV_PAPER"}},{"key":"CAP_MINT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Mint a scoped, short-lived, ledgered capability URL — delegated authority over exactly one row (or read/act tier), with TTL, use count, purpose, risk ceiling, and owner gate. Returns invoke_url + explain_url + fingerprint; the URL explains itself.\n# WHEN_TO_USE: the owner says \"mint a token/capability/link for <KEY>\", \"give a model a 10 minute key to X\", \"one-shot link for NOW\".\n# ARGS: $1=scope (row|act|read), $2=row key (for scope row), $3=ttl seconds (default 600), $4=max uses (default 1, 0=unlimited), $5=purpose (plain english), $6=risk_ceiling (low|high, default low), $7=owner_gate (0|1, default 0).\n# EX: [CAP_MINT]row|NOW|600|1|demo for chatgpt[/CAP_MINT]\n[\"$1\",\"$2\",\"$3\",\"$4\",\"$5\",\"$6\",\"$7\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_MINT","json":"/api/directory/CAP_MINT","skill":"/api/directory/CAP_MINT?format=skill","oip_contract":"/api/dispatch?key=CAP_MINT"}},{"key":"GITHUB_TAIL","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The GitHub repository as a live object. Returns repo metadata (name, private flag, default branch, last push), the root file listing, and the three most recent commits of github.com/[OWNER_HANDLE]/oip. Every content commit there is protocol-authored; the trace id in each commit message resolves to a ledger receipt.\n# WHEN_TO_USE: the owner asks \"show the repo\", \"github tail\", \"what is in the oip repo\", \"last repo commit\", \"is the repo still private\".\n# ARGS: none.\n# EX: [GITHUB_TAIL][/GITHUB_TAIL]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/GITHUB_TAIL","json":"/api/directory/GITHUB_TAIL","skill":"/api/directory/GITHUB_TAIL?format=skill","oip_contract":"/api/dispatch?key=GITHUB_TAIL"}},{"key":"OIP_RECEIPT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Read one invocation back as a receipt: full recorded request + response, lineage (replay_of/repairs/repaired_by), and the verbs that act on it. A receipt is a live replayable object, not history.\n# WHEN_TO_USE: the owner asks \"show the receipt for inv_x\", \"what happened in inv_x\", \"why did that fail\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_RECEIPT]inv_wvitbmiym6[/OIP_RECEIPT]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_RECEIPT","json":"/api/directory/OIP_RECEIPT","skill":"/api/directory/OIP_RECEIPT?format=skill","oip_contract":"/api/dispatch?key=OIP_RECEIPT"}},{"key":"OIP_REPAIR","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Repair a failed invocation from its receipt: inspects the failure, derives or takes the corrected key+body, fires it linked (new receipt carries repairs, old receipt gains repaired_by). Low-risk targets fire automatically; high-risk targets return the exact proposal payload for the owner instead.\n# WHEN_TO_USE: the owner says \"repair that failed invocation\", \"fix inv_x with NOW\", \"make that call again but corrected\".\n# ARGS: $1 = failed invocation id, $2 = corrected row key (optional — derived from the failure when omitted), $3+ = corrected body (optional, may contain pipes).\n# EX: [OIP_REPAIR]inv_6ximjestte|NOW|[/OIP_REPAIR]\n[\"$1\",\"$2\",\"$3+\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPAIR","json":"/api/directory/OIP_REPAIR","skill":"/api/directory/OIP_REPAIR?format=skill","oip_contract":"/api/dispatch?key=OIP_REPAIR"}},{"key":"OIP_REPLAY","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Re-fire a past invocation with its recorded input. New receipt links replay_of to the old one.\n# WHEN_TO_USE: the owner says \"replay that\", \"run inv_x again\", \"re-fire it as it was\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_REPLAY]inv_wvitbmiym6[/OIP_REPLAY]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPLAY","json":"/api/directory/OIP_REPLAY","skill":"/api/directory/OIP_REPLAY?format=skill","oip_contract":"/api/dispatch?key=OIP_REPLAY"}},{"key":"CAP_EXPLAIN","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Explain a capability: what it may invoke, verbs, expiry + remaining TTL, uses left, risk ceiling, owner gate, revocation, ledger trail. Accepts the token itself (sh.…) or its fingerprint (cap_…). Never echoes the raw token.\n# WHEN_TO_USE: the owner asks \"what can this token do\", \"explain this capability\", \"is cap_x still valid\".\n# ARGS: $1 = capability token or cap_ fingerprint.\n# EX: [CAP_EXPLAIN]cap_1a2b3c4d5e6f7a8b[/CAP_EXPLAIN]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_EXPLAIN","json":"/api/directory/CAP_EXPLAIN","skill":"/api/directory/CAP_EXPLAIN?format=skill","oip_contract":"/api/dispatch?key=CAP_EXPLAIN"}},{"key":"CAP_REVOKE","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Revoke a capability by fingerprint — the URL dies immediately; further invokes are denied and ledgered.\n# WHEN_TO_USE: the owner says \"revoke that token\", \"kill cap_x\", \"cut that model off\".\n# ARGS: $1 = cap_ fingerprint.\n# EX: [CAP_REVOKE]cap_1a2b3c4d5e6f7a8b[/CAP_REVOKE]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_REVOKE","json":"/api/directory/CAP_REVOKE","skill":"/api/directory/CAP_REVOKE?format=skill","oip_contract":"/api/dispatch?key=CAP_REVOKE"}}]},"ontology":{"conformance_group":"article","inferred_from":["OIP","UDST","systems-theory","deterministic","udst","v1","1","logical","economics"],"relationships":[],"sources":[]},"conformance":{"success_events":"/api/articles/udst-v1-1-logical-economics/invocations?status=success","failure_events":"/api/articles/udst-v1-1-logical-economics/invocations?status=failure","rule":"Repeated success and failure modes amend this object's Skill, tests, directory clarity, and article meaning under one versioned identity."},"article":{"slug":"udst-v1-1-logical-economics","title":"UDST: V1 1 Logical Economics","body":"# Logical Economics\n\nReasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once reasoning is measured, an economic structure becomes visible that the global economy has not yet priced.\n\nThe first move is to identify the actual valuable output.\n\nThe valuable output of reasoning is the proof artifact, not the answer. A proof artifact is the replayable, ledgered record of a reasoning event: the prompt, the input, the definitions, the scope rules, the logical-unit graph, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset — it can be verified, reused, transferred, challenged, repaired, and amortized.\n\nIn the build, a proof artifact is a receipt. `POST /api/dispatch {key:NOW}` returns a receipt with `invocation_id`, `request_json`, `response_json`, `ts`, and `story`. The receipt is not a summary; it is the full forensic record. Anyone with the receipt ID can verify the invocation by opening `GET /api/dispatch?receipt=INV_ID`. The receipt is the proof artifact. The answer (\"NOW returned the current time\") is disposable.\n\nThe economic primitive that proof artifacts make legible is logical density.\n\n**Surety** is not confidence. Confidence is the model's report on itself. Surety is what survives external test. It is the product, not the sum, of four factors:\n\nSurety = Correctness × Auditability × Reproducibility × Adversarial Survival.\n\nThe multiplicative form is load-bearing. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The four factors are conjunctive; any one at zero collapses the score.\n\nIn the build, surety is measured by the conformance suite. C1 (manifest) verifies correctness: does the system expose the endpoints it claims? C7 (receipt forensics) verifies auditability: can a receipt be replayed? C10 (idempotency) verifies reproducibility: does the same input produce the same receipt? C14 (clarity recursion) verifies adversarial survival: does the system survive a model's attempt to break it? Each clause is a factor in the surety score. If any clause fails, the surety of the entire system is zero for that dimension.\n\n**Logical energy** is the total physical and symbolic cost of producing and sustaining the proof across its lifecycle. In the build, this is the sum of: token cost for the model invocation, compute cost for the D1 query, latency cost for the network round-trip, human review cost for the owner verification, and privacy risk cost for the data exposure. The ledger records the logical energy of every invocation: `tokens`, `cost`, `models`, `latency_ms`.\n\nThe compressed form is the economic primitive:\n\nLogical Density = Surety / Logical Energy.\n\nThis is the headline unit. It answers: how much survives audit per unit of cost. In the build, the logical density of a capability is calculated from its conformance score divided by its average invocation cost. A capability that scores 15/15 conformance but costs $0.10 per invocation has lower logical density than a capability that scores 14/15 but costs $0.001 per invocation. The cost is real; the density is measurable.\n\nBut the compressed form alone is incomplete for real-world decisions. Some reasoning protects high-stakes decisions; some protects low-stakes. Some answers must be produced before a deadline; some have all the time in the world. The rigorous form prices these.\n\n**Task-Adjusted Logical Density** is the form that governs real decisions:\n\nTask-Adjusted Logical Density = Expected Verified Decision Value / Total Lifecycle Logical Cost.\n\nWhere Expected Verified Decision Value = Task Stakes × Correctness × Auditability × Reproducibility × Adversarial Survival × Actionability × Freshness. And Total Lifecycle Logical Cost = generation + retrieval + context + tool use + verification + red-team + repair + human review + privacy risk + failure risk + replay/adaptation cost + latency/opportunity cost.\n\nIn the build, task-adjusted logical density is priced per capability. A high-stakes capability like `D1_EXEC` (database mutation) has high task stakes and therefore requires high surety; it is backed by the full conformance suite and owner-gate verification. A low-stakes capability like `NOW` (time query) has low task stakes and therefore can tolerate lower surety; it is fast, cheap, and requires no human review. The router elects the path based on the task-adjusted density: `?ask=send a text` routes to `SEND_BY_CHANNEL` because the task stakes (sending a message) are moderate, the correctness requirement is high (the recipient must receive it), and the actionability is immediate (the message is sent within seconds). A cheaper but less auditable path would have lower task-adjusted density for this task.\n\nThree implications follow.\n\n**Latency is a cost, not a separate consideration.** For time-critical decisions, the value of proof is bounded by the deadline. A lower-surety answer can dominate a higher-surety answer if delay destroys the opportunity. The framework demands that latency be carried in the denominator, not waved away as an exception. A perfect proof delivered after the deadline has zero verified decision value. In the build, this is the idempotency window: a 90-second dedup window that prevents duplicate sends but does not block the original action. The latency cost of the dedup check is measured in milliseconds; the opportunity cost of a duplicate send is measured in operator trust.\n\n**Proof artifacts are bounded in validity.** A proof artifact has economic value only within its declared scope, freshness window, and similarity class. Reuse requires three conditions: contextual similarity to the new case, dependency freshness (the upstream facts must still hold), and verification cost below regeneration cost. In the build, this is the receipt expiry: a receipt is valid only within the scope of the original capability, within the freshness window of the token's TTL, and only if the verification cost (opening the receipt URL) is below the regeneration cost (re-invoking the capability). When the upstream changes — a token is revoked, a capability is deprecated — the proof goes stale.\n\n**Amortization** is the mechanism by which proof becomes cheap. A proof artifact's average cost falls as the number of valid reuses rises and as verification cost per reuse falls below regeneration cost. In the build, this is the replay path: `GET /api/dispatch?receipt=INV_ID` replays a past invocation without re-firing it. The verification cost is one HTTP GET; the regeneration cost is a full model invocation. The amortization rate is empirical: the number of times a receipt is replayed divided by the number of times it was generated. The ledger tracks this ratio. If the replay rate does not exceed the regeneration cost, the economic argument for proof artifacts weakens to \"marginal improvement on some tasks.\" The falsification surface is live: the ledger shows the actual replay rate for every capability.\n\nTwo market consequences are predictable.\n\nThe cost of surety falls as proof artifacts standardize, verify quickly, and reuse across similar cases. In the build, this is the standardization of the receipt format: every invocation, regardless of capability, returns the same receipt envelope with `invocation_id`, `story`, `proof`, `links`. The standardization makes verification cheap: one parser reads all receipts. The cost of surety falls along the curve as the number of standard receipts grows.\n\nThe cost of alpha falls as deterministic boolean revisions undercut the recurring cost of probabilistic search wherever a deterministic path is discoverable. In the build, this is the deterministic command plane: the router does not search for the right capability; it looks it up in the directory by exact match. The deterministic path (directory lookup) is cheaper than the probabilistic path (model reasoning about which capability to use). The arbitrage opportunity is in finding the deterministic paths and converting them: `ASK_CANONICAL` maps natural-language intents to deterministic capabilities, eliminating the need for probabilistic search.\n\n\n---\n\n## Corpus map\n- Previous: [UDST: V1 1 Capability And Obligation](/a/udst-v1-1-capability-and-obligation)\n- Next: [UDST: V1 1 Llm As Os](/a/udst-v1-1-llm-as-os)\n- Series start: [UDST v1.1 — The Claim](/a/udst-v1-1-the-claim)\n- Kin: [Book V — The Machine Plane](/a/oip-v3-book-v-the-machine-plane) · [Total Structure](/a/oip-total-structure)","hero":null,"images":[],"style":{},"tags":["OIP","UDST","systems-theory","deterministic"],"category":null,"model":"Fable 5 (Claude Code)","ledger":{"href":"/api/articles/udst-v1-1-logical-economics/ledger","live":true},"embeds":[],"widgets":[],"home":true,"claims":[{"id":"c1","text":"Reasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once reasoning is measured, an economic structure becomes visible that the global economy has not yet priced.","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c2","text":"In the build, a proof artifact is a receipt. `POST /api/dispatch {key:NOW}` returns a receipt with `invocation_id`, `request_json`, `response_json`, `ts`, and `story`. The receipt is not a summary; it is the full forensic record. Anyone with the receipt ID can verify the invocation by opening `GET /api/dispatch?receipt=INV_ID`. The receipt is the proof artifact. The answer (\"NOW returned the curre","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c3","text":"**Surety** is not confidence. Confidence is the model's report on itself. Surety is what survives external test. It is the product, not the sum, of four factors:","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."},{"id":"c4","text":"The multiplicative form is load-bearing. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The four factors are conjunctive; any one at zero collapses the score.","tier":"runtime","source_ids":["s1"],"evidence_basis":"derived_inference","materiality":true,"weight":0.8,"status":"active","falsifier":"Evidence that directly contradicts this claim."}],"sources":[{"id":"s1","type":"adjacent","url":"https://miscsubjects.com/a/udst-v1-1-logical-economics","title":"UDST: V1 1 Logical Economics","quote":"Reasoning has physical cost. The cost is measurable: compute, tokens, retrieval, context activation, verification, red-team, repair, replay, latency, human review, privacy risk, failure risk. Once rea","summary":"Primary source for UDST: V1 1 Logical Economics.","claim_ids":["c1","c2","c3","c4"],"quality_score":0.9}],"reviews":[],"extra":{"kind":"corpus","corpus_map":{"prev":"udst-v1-1-capability-and-obligation","next":"udst-v1-1-llm-as-os","hub":"udst-v1-1-the-claim","series":"udst-v1-1","position":5,"of":13}},"has_traversal":true,"register":"oip_protocol","status":"published","revisions":6,"contributions":[],"provenance":[{"ts":"2026-07-04T03:40:12.208Z","model":"claude-fable-5","action":"fill","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"genesis","hash":"9305ad6f349fa8eef986680105ebc16e31268625ce5531916cfcdb09a31cd466"},{"ts":"2026-07-04T04:39:13.569Z","model":"claude-fable-5","action":"edit","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"9305ad6f349fa8eef986680105ebc16e31268625ce5531916cfcdb09a31cd466","hash":"b6a496278481540328d124114aec71410e2f72c83d79492e76c93c3e245215c1"},{"ts":"2026-07-04T05:03:18.049Z","model":"claude-fable-5","action":"edit","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"b6a496278481540328d124114aec71410e2f72c83d79492e76c93c3e245215c1","hash":"ab9611133ab151c99ce34ab23c4926962e02587cab608057f5622e17b675c999"},{"ts":"2026-07-17T02:37:52.225Z","model":"owner","action":"voxel_divide","prompt":"","input":"udst-v1-1-logical-economics","response":"29 DIVs from body (verbatim, roundtrip-checked)","tokens_in":0,"tokens_out":0,"cost":0,"prev":"ab9611133ab151c99ce34ab23c4926962e02587cab608057f5622e17b675c999","hash":"2132780ac3cd63bcc25852041290ffe860bf611bf6f65abc22b96028caa52d63"},{"ts":"2026-08-06T09:30:27.440Z","model":"unknown","action":"edit","why":"the nine books are published under canonical oip-v3-book-<numeral> slugs while the corpus maps link short slugs that never existed; the pages were not missing, the addresses were wrong","prompt":"","input":"","response":"","tokens_in":0,"tokens_out":0,"cost":0,"prev":"2132780ac3cd63bcc25852041290ffe860bf611bf6f65abc22b96028caa52d63","hash":"953f0f243f432cc2894c9e50e94193a67dae213d447e3f83e522d91f91ccfc3b"}],"energy":{"passes":5,"tokens_in":0,"tokens_out":0,"tokens_total":0,"cost_usd":0,"models":{"claude-fable-5":3,"owner":1,"unknown":1},"head":"953f0f243f432cc2894c9e50e94193a67dae213d447e3f83e522d91f91ccfc3b"},"posted_at":"2026-07-04T03:17:44.788Z","created_at":"2026-07-04T03:17:44.788Z","updated_at":"2026-08-06T09:30:27.440Z","machine":{"shape":"article.machine/v1","slug":"udst-v1-1-logical-economics","kind":"corpus","read":{"human":"https://miscsubjects.com/a/udst-v1-1-logical-economics","json":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics","bundle":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/bundle?format=markdown"},"traversal":{"prev":{"slug":"udst-v1-1-capability-and-obligation","human":"https://miscsubjects.com/a/udst-v1-1-capability-and-obligation","json":"https://miscsubjects.com/api/articles/udst-v1-1-capability-and-obligation"},"next":{"slug":"udst-v1-1-llm-as-os","human":"https://miscsubjects.com/a/udst-v1-1-llm-as-os","json":"https://miscsubjects.com/api/articles/udst-v1-1-llm-as-os"},"hub":{"slug":"udst-v1-1-the-claim","human":"https://miscsubjects.com/a/udst-v1-1-the-claim","json":"https://miscsubjects.com/api/articles/udst-v1-1-the-claim"},"series":"udst-v1-1","position":5,"of":13},"ledger":{"claims":4,"sources":1,"contributions":0,"revisions":6,"objections_url":"https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=udst-v1-1-logical-economics","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":"source text is prose-preserving — attack via objections, never rewrite the author's words"},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"udst-v1-1-logical-economics\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"udst-v1-1-logical-economics\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/udst-v1-1-logical-economics/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"udst-v1-1-logical-economics\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/udst-v1-1-logical-economics | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"}},"representations":{"article":"/a/udst-v1-1-logical-economics","json":"/api/articles/udst-v1-1-logical-economics","markdown":"/api/articles/udst-v1-1-logical-economics/bundle?format=markdown","skill":"/api/articles/udst-v1-1-logical-economics/skill","topology":"/api/articles/udst-v1-1-logical-economics/topology","versions":"/api/articles/udst-v1-1-logical-economics/revisions","invocations":"/api/articles/udst-v1-1-logical-economics/invocations"},"editorial_review":null,"editorial_audit":{"slug":"udst-v1-1-logical-economics","ok":false,"issues":[{"code":"hero_missing","message":"the article is published with no featured image","replacement":"Generate a hero that shows this article's own subject, inspect it, and record the inspection before this counts as finished. An article with no image is not finished."}]},"body_hash":"f65f875e99a92624b104d91d96a285a7dbe475fed82b7020fe51293bb9e04d54"}}}