UDST: V1 1 Logical Economics

Logical 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 economic structure becomes visible that the global economy has not yet priced.

The first move is to identify the actual valuable output.

The 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.

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 current time") is disposable.

The economic primitive that proof artifacts make legible is logical density.

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:

Surety = Correctness × Auditability × Reproducibility × Adversarial Survival.

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.

In 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.

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.

The compressed form is the economic primitive:

Logical Density = Surety / Logical Energy.

This 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.

But 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.

Task-Adjusted Logical Density is the form that governs real decisions:

Task-Adjusted Logical Density = Expected Verified Decision Value / Total Lifecycle Logical Cost.

Where 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.

In 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.

Three implications follow.

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.

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.

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.

Two market consequences are predictable.

The 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.

The 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.

---

Corpus map

• Previous: UDST: V1 1 Capability And Obligation
• Next: UDST: V1 1 Llm As Os
• Series start: UDST v1.1 — The Claim
• Kin: Book V — The Machine Plane · Total Structure