The Coherence Requirement: Why local truth must compose into global consistency

Marco Polo describes a bridge, stone by stone. "But which is the stone that supports the bridge?" Kublai Khan asks. "The bridge is not supported by one stone or another," Marco answers, "but by the line of the arch that they form." Kublai Khan remains silent, reflecting. Then he adds: "Why do you speak to me of the stones? It is only the arch that matters to me." Polo answers: "Without stones there is no arch."

This chapter states the coherence requirement (A5): the preformal specification that local predicate invention must admit overlap reconciliation and invariant satisfaction. A5 is deliberately incomplete — it names what Parts II and III must deliver formally. The reader who wants the historical argument for why the gap between strings and tables is structural, not technical, should read Vol I, Chapters 5–6 (The Empire of Tables and Evidence Without Custody).

The Gap

The string empire can produce any sentence. The relational empire can enforce any constraint. Neither can do what systems increasingly require: invent a predicate in one context and have that predicate remain coherent when it encounters another context that partially overlaps.

The gap appears whenever locally invented meaning crosses an overlap.

It is not a capability that training will close. It is not a defect that schema design will patch. It is a structural absence—a missing class of object that neither empire was built to produce.

The preceding chapters diagnosed four failures:

• Commitment (A1): Plausibility engines produce sentences without tracking the obligations those sentences create. Contradictions accumulate silently.
• Provenance (A2): Retrieval grounds claims in evidence but drops the witnesses when evidence enters generation. Downstream stages cannot tell whether two claims conflict because they have lost the join keys.
• Vocabulary (A3): Relational systems certify what they can speak but cannot extend their language on demand. New predicates require governance events that the schema layer does not model.
• Epistemic status (A4): Even with fixed vocabulary and typed provenance, sources differ on what absence means. Merging views conflates completeness profiles that determine whether missing data is evidence of negation or merely silence.

Each failure is distinct, with its own formal object at its core. But they share a common shape: local operations produce global incoherence because neither empire contains machinery to reconcile overlapping views in a checkable way.

If meaning can be invented locally, coherence is not optional; it becomes the system's primary invariant. Because any downstream invariant that consumes the predicate assumes a single extension on overlaps; without that, invariants are underspecified.

The gap is not "AI cannot reason" or "databases are rigid." The gap is: neither empire supports contextual predicate invention under invariants—the operation that would let a system define a concept locally and then compose that concept coherently with concepts defined elsewhere.

Local truth is cheap; global coherence is expensive.

---

Views and Overlaps

Coherence fails at boundaries; so we name the boundary objects.

A view is a locally coherent theory-plus-data slice: a signature (types and predicates), constraints (invariants that must hold), a provenance regime (what counts as evidence), and the subset of entities or records the view purports to cover. In the fashion catalog, Supplier A's feed is a view. Supplier C's feed is a different view. The merged catalog is a candidate view: it is the result of attempting to glue views, and the question is whether that gluing is justified under an explicit coherence discipline.

Two views overlap when they make claims about common referents—the same entities, the same events, or entities identified as the same under a stated equivalence. Supplier A and Supplier C overlap on every SKU they both sell. The CI team's definition of "production-ready" and the Release team's definition overlap on every build artifact that passes through both pipelines.

Overlap is where coherence is tested. If two views never touch the same referents, they cannot disagree. The moment they do, they might. And when they disagree, the system must have a response—agreement, reconciliation, or explicit fork. Silent collision is the failure mode we are diagnosing.

From here on, the question is not whether a claim is fluent or grounded, but whether it is composable.

Imagine a city covered by overlapping maps. Each map is accurate within its boundaries, but the boundaries overlap. For the maps to form an atlas, they must agree where they overlap. If one map places a street running north and another places it running east, no amount of local accuracy in either map will produce a coherent city.

This is the structure we need: local views with local truths, overlaps where truths are tested, and a gluing discipline that produces global coherence from local pieces—or else surfaces the obstruction.

In the catalog, a view might be Supplier A's item feed; the overlap is the set of SKUs that both A and C sell; agreement means that when both define a predicate like sustainable, they either coincide on those SKUs or else produce a witnessed reconciliation artifact—a scope restriction, a fork, a preference ordering—that downstream queries can respect.

An atlas is a document about a city. A catalog is a document about products. A schema is a document about documents. What we are missing is a document about agreement: a witnessed object with checkable obligations, recording how one view's meanings are allowed to meet another's. Without that, our systems can store facts, but they cannot store the terms under which facts cohere.

The atlas is not merely a metaphor. It names the structure: local data, overlap conditions, gluing to global. Mathematically, this structure is a sheaf(Lane 1992, ch. I–II)Saunders Mac Lane, Sheaves in Geometry and Logic: A First Introduction to Topos Theory (New York: Springer-Verlag, 1992), ch. I–II.View in bibliography.

---

The Capability Table

Before stating the requirement formally, consider what the two empires can and cannot do. The table below is not a scorecard. It is a requirements trace: each row names a capability that at least one touchstone demands, and the final column cites which touchstones exercise it.

Capability	String	Retrieval	Typed/Relational	Required	Triggered by
Induce candidate predicates from unstructured input	✓	✓	✗	✓	T6, T8
Enforce declared invariants	✗	✗	✓	✓	T1, T4
Dynamic predicate invention	✗	✗	✗	✓	T6, T9
Context-dependent equivalence	✗	✗	✗	✓	T2, T7
Compositional generalization	✗	✗	Partial	✓	T3
Explicit epistemic status	✗	Partial	Partial (3VL)	✓	T5
N-ary event unity	Partial	Partial	✓ (non-default)	✓	T10
Typed provenance	✗	Partial	✓	✓	T2, T5

Every row in the "Required" column is ✓. Every row has at least one ✗ in the String or Retrieval columns, or the Typed/Relational column, or both. The table does not say "AI bad, databases good" or vice versa. It says: neither empire, alone or in obvious combination, covers the requirement space that the touchstones define.

(Note: "Enforce declared invariants" means declared constraints are enforced—not that the system proves all domain truths. The relational empire enforces what it can speak; it does not speak everything.)

The gap is in the last two columns. What a Third Mode system must do is clear. How to build one is not.

The table is abstract. The next two examples show what it means in motion.

---

Two Toy Models

Toy Model A: Two Definitions of "Puffy"

Shopper A defines "puffy" as a volume-to-body ratio: a dress is puffy if it occupies visual space disproportionate to the wearer's silhouette. This is a geometric criterion.

Shopper B defines "puffy" as fabric behavior: a dress is puffy if the material holds air or structure rather than draping. This is a material criterion.

On a catalog of 100 dresses:

• 20 are puffy by both definitions
• 15 are puffy by A's criterion only (large volume, but drapy fabric)
• 10 are puffy by B's criterion only (structured but slim silhouette)
• 55 are not puffy by either

If the system asks "is this dress puffy?" and both definitions have contributed, the answer depends on which definition. Without parametrization or reconciliation, the predicate is incoherent—not because people disagree about aesthetics, but because unreconciled definitions propagate into systems that assume a single predicate.

Consider: the catalog's fulfillment logic uses puffy to estimate shipping volume. puffy → shipping_volume_estimate → warehouse_allocation. If "puffy" varies by context, the derived invariant breaks. A dress that is puffy-by-volume but not puffy-by-fabric gets the wrong box size. The error is not philosophical. It is operational.

What coherence requires:

• If A's and B's definitions are different contexts, overlap agreement demands a decision: either the definitions carve the same boundary (prove it), or they don't (fork the predicate with explicit scope).
• If the catalog asserts an invariant—"puffy ⊆ non-fitted"—then both definitions must respect it.
• If A and B disagree on the 25 dresses in the symmetric difference, the system must produce a reconciliation artifact with provenance and justification—not silently prefer one.

Toy Model B: "Production-Ready" in Build Systems

The CI team declares a build "production-ready" if all tests pass and coverage exceeds 80%.

The Release team declares a build "production-ready" if it has passed security audit, performance benchmarks, and stakeholder sign-off.

A build can be:

• CI-ready but not release-ready (tests pass, no audit yet)
• Release-ready but CI-failing (manual override, stakeholder approved)
• Both ready
• Neither ready

Downstream automation triggers on "production-ready" without knowing which definition. A CI-ready build gets deployed to production without security audit. The failure is not conceptual ambiguity. It is a system with two overlapping views that lacked a reconciliation discipline.

What coherence requires: "production-ready" is fibered over team or scope. Where CI and Release contexts overlap—the set of builds that both teams touch—the system either proves the definitions coincide, or forks them, or establishes a preference ordering ("deploy requires both"). The invariant "deployed builds must be both CI-ready and Release-ready" is a constraint that any coherent gluing must satisfy.

---

The Coherence Requirement

We can now state what a Third Mode system must satisfy.

By "well-defined" we mean: the predicate comes with a signature, a domain of applicability, and a method of evaluation (measurement, proof rule, or oracle) sufficient to make its outputs checkable.

The rule compresses: On overlaps, agree with proof, fork with scope, or reconcile with witness. Silent collapse is never permitted.

---

The Touchstone Battery

The preceding chapters introduced specific failures. We now collect them into a battery—ten cases that any Third Mode system must handle. They are not exhaustive; they are representative. If a system passes all ten, it is likely coherent. If it fails any one, it is not.

ID	Name	Failure Mode	Required Artifact	Resolved In
T1	Contradiction	Produces candidates for empty queries	Unsat witness + derivation	Ch 25
T2	Reference	Conflates/separates without witness	Scoped equivalence with transport	Ch 26
T3	Compositionality	Interpolates without systematic rule	Predicate composition from grammar	Ch 18
T4	Exactness	Approximates discrete quantities	Exact trace with provenance	Ch 16
T5	Negation/Absence	Wrong inference from missingness	Logic-indexed epistemic status	Ch 13
T6	Predicate Invention	Schema rigidity	Predicate dossier with tests/invariants	Ch 27
T7	Contextual Equivalence	Context-free matching	Scoped equivalence with scope annotation	Ch 28
T8	Uncertainty/Value	Treats non-factual as factual	Fibered predicate over context	Ch 12
T9	Schema Evolution	Breaking change without migration	Conservative extension or compatibility witness	Ch 24
T10	Higher-Arity Events	Loses structure under binarization	N-ary event object with typed projections	Ch 29

Each touchstone has a required artifact—the formal object that resolves it. These artifacts are what the rest of the book constructs.

The touchstones are not random. They pressure different parts of the Coherence Requirement:

• T6 (Predicate Invention) and T9 (Schema Evolution) press local definability—can the system mint and evolve predicates at all?
• T2 (Reference), T7 (Contextual Equivalence), and T10 (Higher-Arity Events) press overlap agreement—can the system recognize when different views are talking about the same thing, and reconcile their claims? (For higher-arity events, "classification" includes role structure, not merely membership.)
• T1 (Contradiction), T4 (Exactness), and T5 (Negation/Absence) press invariant preservation and epistemic discipline—can the system refuse contradictions, compute exactly, and track inference regimes?
• T8 (Uncertainty/Value) forces fiber/context dependence—can the system handle predicates whose truth varies with context?
• T3 (Compositionality) tests the entire pipeline—can predicates compose systematically rather than by interpolation?

Ten cases. Ten failures. Each with a required artifact. The artifacts are what we build.

---

The Diagram

The coherence problem is geometric: two views overlap, and the overlap must agree.

The views define sustainable under incompatible assumptions. On the overlap $U_1 \cap U_2$, the system must either:

• Reconcile: find a common interpretation that both views accept
• Obstruct: produce a witness explaining why reconciliation fails

This is the sheaf condition (A13) in miniature. Coherence is tested on overlaps; the formal criterion is deferred to Parts II–III.

---

The Fashion Catalog with Vocabulary Conflict

The fashion catalog now carries four layers of diagnostic:

1. Commitment (Ch 1): String retrieval matched "flowy" without tracking that the evidence was a negation.
2. Provenance (Ch 2): Supplier A said "100% silk"; Supplier C said "70% silk / 30% polyester." The merge lost the source.
3. Vocabulary (Ch 3): User asked for "puffy dresses." No column exists. Escape hatches surrender certification.
4. Epistemic status (Ch 4): Supplier A's NULL means "not sustainable." Supplier C's NULL means "unknown." The merge conflated them.

Add now a fifth layer: vocabulary conflict.

The Marketing team has invented "statement piece"—items with bold visual presence suitable for editorial features. The Merchandising team has invented "bold item"—items with bright colors or unusual patterns that stand out in grid view.

Are these the same predicate? The overlap is significant but not total:

• Some items are "statement piece" in Marketing but not "bold" in Merchandising (architecturally dramatic, muted color)
• Some items are "bold" in Merchandising but not "statement piece" in Marketing (neon print, conventional cut)

This is Toy Model A with different clothes: two locally valid predicates with a nontrivial symmetric difference.

Without explicit reconciliation, downstream systems that consume both predicates will produce incoherent results. A recommendation engine trained on "bold" will surface items that Marketing would never feature. A homepage editorial built on "statement piece" will omit items that Merchandising considers standouts.

A5 requires: either these are distinct predicates (fork with scope), or they are the same predicate (prove overlap agreement), or they are related predicates with explicit transport (is "statement_piece" a subset of "bold"? a superset? neither?). The system must produce a witness for whichever answer it gives.

---

Consequence

The diagnosis is complete.

The string empire produces fluent incoherence. The schema empire enforces rigid coherence. Neither supports contextual predicate invention under invariants—the operation the touchstones require.

What would it take to build a system that does?

The answer is not "more training" or "better schemas." The answer is mathematical: we need formal objects that describe how local truths compose into global coherence, how equivalence carries transport obligations, how predicates can be invented within invariant-respecting boundaries.

Those objects already exist. They were developed by mathematicians working on entirely different problems—geometry, topology, logic, type theory. The next part of The Proofs is a recovery mission: finding the structures we need in places we were not taught to look.

Why equivalence first? Because without a theory of "same," no amount of truth values can glue. Two views that disagree on whether X and Y are the same entity will never agree on predicates over X and Y—regardless of how carefully they track truth. Equivalence is prior.

Part II: Equivalence Before Truth.

---

Litmus Cases

Case	Name	Chapter 5 Status
T1	Contradiction	Named in battery; presses invariant preservation
T2	Reference	Named in battery; presses overlap agreement
T3	Compositionality	Named in battery; tests entire pipeline
T4	Exactness	Named in battery; presses invariant preservation
T5	Negation/Absence	Named in battery; presses epistemic discipline
T6	Predicate Invention	Named in battery; presses local definability
T7	Contextual Equivalence	Named in battery; presses overlap agreement
T8	Uncertainty/Value	Named in battery; forces fiber dependence
T9	Schema Evolution	Named in battery; presses local definability
T10	Higher-Arity Events	Named in battery; presses overlap agreement

All ten touchstones are now collected. The failures have names, the names have required artifacts, and the artifacts point toward Part II.

---

Figure 1: Touchstone Resolution Map

Each touchstone (failure mode) maps to the anchors (formal machinery) that resolve it. The Primary column names the anchor that directly addresses the failure; Supporting names machinery that is necessary but insufficient alone.

Touchstone	Primary	Supporting
T1: Contradiction	A27 (Refusal Obligation)	A1, A18
T2: Reference	A30 (Scoped Equivalence)	A6, A10, A23, A28
T3: Compositionality	A20 (Predicate Search)	A5
T4: Exactness	A2c (Witness Class)	A1, A18
T5: Negation	A15 (Logic Selection)	A4
T6: Predicate Invention	A24 (Predicate Package)	A3, A17, A29
T7: Contextual Equivalence	A30 (Scoped Equivalence)	A7, A10, A16
T8: Uncertainty	A14 (Fibration)	A4, A18, A25
T9: Schema Evolution	A17b (Conservative Extension)	A3, A11, A26
T10: N-ary Events	A31 (Event Object)	A21, A26

Each row answers: why should I care about this anchor? A system that implements all primary anchors passes the touchstone test suite. Parts II–V construct these anchors; Part VI verifies the constructions discharge the obligations.

---