Bounded awakening: why per-query cost stays flat as the graph grows

The naive way to query a graph is to load it and traverse. At planetary scale — millions of nodes across four layers — that is not a query, it is a dump, and a dump is not tractable. Bounded awakening is the alternative: a query awakens a bounded neighborhood of the graph, sized by a budget, driven by the query and the graph structure together. The neighborhood is the part the answer depends on; everything outside stays dark and costs nothing. Per-query cost is bounded independent of total graph size — which is the tractability property.

The budget, not the universe

The budget is the attention window the model would have spent anyway, but spent on a neighborhood that bears on the question. A query about a bond awakens the bond (L1), the central bank that issued it (L2), the bank that holds it (L3), and the public-signal actors who moved it (L4) — a bounded neighborhood across the four layers. It does not awaken every bond, every central bank, every bank, every actor. The cost of the query is the cost of the neighborhood, not the cost of the graph. As the graph grows — more instruments, more governments, more companies, more actors — the cost of the query does not grow, because the neighborhood the query awakens does not grow.

A graph that has to load itself to answer a query cannot grow. Bounded awakening decouples per-query cost from graph size — the tractability property at planetary scale.

• Budgeted neighborhood: the query awakens what the answer depends on, not everything.
• Per-query cost flat in graph size: the graph can grow, the query stays affordable.
• Four-layer traversal: the neighborhood spans L1 to L4 as needed, bounded by the budget.

Why this is the tractability property

A system whose per-query cost grows with the graph is a system that becomes unaffordable as it becomes useful. Bounded awakening decouples the two: the graph can grow (more useful), the per-query cost stays flat (still affordable). That is the property that makes the oracle work at planetary scale, where a full dump is not just expensive, it is impossible. The PROJECTED token reduction — roughly 10x versus a full-recompute baseline — is a consequence of the same property: the model sees the neighborhood, not the graph, and the neighborhood is smaller than the graph by the budget factor. That number is PROJECTED, not measured; the mechanism is shipped.

What fidelity requires

Bounded awakening is only useful if the awakened neighborhood is the one the answer depends on. A naive filter that drops nodes the query needs makes the answer drift, and the cost saving is paid in correctness. deino-loom selection is driven by the query and the graph structure together, so the neighborhood it awakens is the one the answer depends on. Fidelity is measured the same way everything else is — against the realized timeline, via the calibration loop (Gate 1b). We do not claim the bounded-context answer is as good as the full one; we measure whether it is. The mechanism is shipped; the measurement is gated.

What the manifest records

The manifest records the exact NodeVersions deino-loom selected — the bounded neighborhood the model actually saw. That means the curation is part of the provenance: an auditor replaying the query awakens the same neighborhood, not a re-computed one. Curation and reproducibility are not in tension; the manifest records the slice, so the slice is the record. We are pre-revenue, building the POC; bounded awakening is built, the manifest records the slice, and the calibration that tells us the slice is enough is the loop behind Gate 1b.

The budget is the attention window the model would have spent anyway, spent on the neighborhood that matters. The rest of the graph is not wrong; it is irrelevant to this query, and irrelevance is free.

— bounded awakening note