docs: surface bounded storage and scalable time-aware discovery on the README and landing page

README gains a "Bounded storage & scalable discovery" section, and the Pi
note now covers bounded on-disk history. The landing-page honest ledger and
FAQ describe fixed-budget storage (no more "storage that grows over time")
and add FAQs on storage growth and staying usable as the network changes.
Also fix the multi-resolution plan link in cli.md (moved to plan/done).

Author: levy

README.md

@@ -51,6 +51,30 @@ Start here depending on what you want:
   - **event bounds discovery** — the enclosing chain's endpoint timestamps `(lower, upper)`;
   - **event order discovery** — compare two events' intervals → `-1`, `+1`, or `0`.
 
+## Bounded storage & scalable discovery
+
+Two capabilities keep a node viable as a long-lived, always-on service.
+
+- **Bounded storage.** Each node keeps several independent clock chains at geometrically spaced
+  resolutions — fine-grained for recent events, progressively coarser for older ones — and
+  ring-prunes each to a fixed capacity, so total on-disk storage stays **flat at a configurable
+  budget** — tens of MB on a Pi, tens of GB on a server. No event is ever dropped: old events stay
+  provably orderable and only lose time-bound *precision*, gracefully, with age — recent events are
+  pinned to the second, a decade-old event to about a minute, with a horizon of centuries. `lotid`
+  runs a sensible default schedule; `loti db gc` re-asserts the prune and `loti db stat` reports the
+  chains and retention. See
+  [doc/theory.md](doc/theory.md#bounding-storage-multi-resolution-clock-chains) and
+  [doc/cli.md](doc/cli.md).
+
+- **Scalable, time-aware discovery.** A proof has to trace the overlay *as it was during the target
+  event's time range*, not the current topology — so forwarding is a **time-dependent, pluggable,
+  bounded** routing decision: directed where a routing table exists, degrading to a bounded flood
+  (width, hop-limit, visited-set) over the *historical* neighbor set where it does not, so lookups
+  scale and survive peer churn. Soundness stays free — every returned chain is re-validated by the
+  math, so heuristic routing can only cost completeness, never correctness. See
+  [doc/dynamic-discovery.md](doc/dynamic-discovery.md) and the design in
+  [plan/pending/scalable-pluggable-discovery.md](plan/pending/scalable-pluggable-discovery.md).
+
 ## Simulation model
 
 Each host runs three co-located application modules; one helper module builds the overlay.
@@ -172,8 +196,10 @@ a multi-node notary proof over real UDP).
 
 `lotid` is small and dependency-light enough to run always-on as a node on a **~$15 Raspberry
 Pi Zero**. The DAG is read through a page-cache-backed store, so a node's memory stays bounded
-as it grows. [doc/embedded.md](doc/embedded.md) is the full guide: cross-compiling for
-**aarch64** (Zero 2 W) and **ARMv6** (Zero / Zero W) with the toolchains in
+as it grows — and its on-disk history is bounded too (see
+[Bounded storage & scalable discovery](#bounded-storage--scalable-discovery)), so the node runs
+indefinitely without filling the card. [doc/embedded.md](doc/embedded.md) is the full guide:
+cross-compiling for **aarch64** (Zero 2 W) and **ARMv6** (Zero / Zero W) with the toolchains in
 [cmake/](cmake/) and [scripts/build-cross.sh](scripts/build-cross.sh), the recommended Pi flags
 (`--store-mapsize`, `--store-sync-interval` for SD-card wear), and the honest limits (the 32-bit
 DAG-lifetime ceiling, cold-read latency, microSD wear).

doc/cli.md

@@ -463,7 +463,7 @@ loti verify order.loti
 - ~~What is the exact retention policy that keeps proofs reconstructible years later without
   unbounded storage growth (~3–30 GB/year of clock events per the paper)?~~ **Answered** by
   multi-resolution clock chains (see [`db gc`](#storage--maintenance) above and
-  [plan/pending/multi-resolution-clock-chains.md](../plan/pending/multi-resolution-clock-chains.md)):
+  [plan/done/multi-resolution-clock-chains.md](../plan/done/multi-resolution-clock-chains.md)):
   `N` independent clock chains at geometrically spaced intervals, each ring-pruned to a fixed
   `keep`, bound total clock-event storage to ≈ `chains · keep` — old events are never dropped,
   they degrade from exact to ≈ `a/C` precision of their age (`C` = events kept per chain) once

index.html

@@ -595,8 +595,8 @@ <h2>What it costs, and what you get.</h2>
         <div class="panel cost">
           <h3>What it takes</h3>
           <ul>
-            <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>A node needs a little storage that grows over time, and a bit of bandwidth — like a modest background service.</span></li>
-            <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>Hardware is cheap: a node runs always-on, low-power, on a <strong>~$15 Raspberry Pi Zero</strong> — its memory stays bounded as it grows. <a href="https://github.com/levy/loti/tree/master/doc/embedded.md" target="_blank" rel="noopener">Embedded guide →</a></span></li>
+            <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>A node needs a bit of bandwidth and a slice of storage — <strong>capped at a budget you pick and flat forever</strong>, so it never outgrows its disk. Like a modest background service.</span></li>
+            <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>Hardware is cheap: a node runs always-on, low-power, on a <strong>~$15 Raspberry Pi Zero</strong> — both its memory and its on-disk history stay bounded, so it runs indefinitely without filling up. <a href="https://github.com/levy/loti/tree/master/doc/embedded.md" target="_blank" rel="noopener">Embedded guide →</a></span></li>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>Proofs pin an event to a <em>window</em> — think under a minute — not an exact instant.</span></li>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>It proves <em>time and order</em>. Pair it with a signature when you also need to prove <em>who</em>.</span></li>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"><path d="M5 12h14"/></svg><span>Like any network, its reach depends on participation — the more nodes, the tighter and more trusted the proofs.</span></li>
@@ -609,6 +609,7 @@ <h3>What you gain</h3>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"><path d="M4 12.5l5 5L20 6.5"/></svg><span>Proofs a third party can verify offline — no account, no platform, no trust in you.</span></li>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"><path d="M4 12.5l5 5L20 6.5"/></svg><span>Freedom from fees, gatekeepers, and single points of failure.</span></li>
             <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"><path d="M4 12.5l5 5L20 6.5"/></svg><span>Privacy — publish as much as you like; only fingerprints ever leave your machine.</span></li>
+            <li><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"><path d="M4 12.5l5 5L20 6.5"/></svg><span>Proofs that last — on a fixed storage budget a node keeps ordering events for centuries; recent ones stay pinned to the second, old ones fade in precision but never in order.</span></li>
           </ul>
         </div>
       </div>
@@ -691,7 +692,11 @@ <h2>The things people ask first.</h2>
         </details>
         <details>
           <summary>Does it cost money?<span class="plus"></span></summary>
-          <p>Publishing an event is effectively free. Running a node costs a little storage — which grows gradually over time — and a bit of bandwidth. There are no per-proof fees.</p>
+          <p>Publishing an event is effectively free. Running a node costs a bit of bandwidth and a fixed slice of storage — capped at a budget you choose and flat forever. There are no per-proof fees.</p>
+        </details>
+        <details>
+          <summary>Won't the storage grow forever?<span class="plus"></span></summary>
+          <p>No. Each node keeps its clock history at several resolutions at once — fine-grained for recent events, progressively coarser for older ones — and trims each down to a fixed size. Total storage is capped at a budget you set, from tens of megabytes on a Raspberry Pi to tens of gigabytes on a server, and stays flat. You never lose the ability to order an old event; only its time window widens gently with age — recent events pinned to the second, a decade-old event to about a minute, with a reach of centuries.</p>
         </details>
         <details>
           <summary>How precise is a proof?<span class="plus"></span></summary>
@@ -709,6 +714,10 @@ <h2>The things people ask first.</h2>
           <summary>Who runs the network?<span class="plus"></span></summary>
           <p>Anyone. People, companies, cities, courts, laboratories, even sensors and IoT devices. The more participants there are, the tighter and more widely trusted the proofs become.</p>
         </details>
+        <details>
+          <summary>Does it keep working as the network grows and changes?<span class="plus"></span></summary>
+          <p>A proof traces the network as it was when your event happened — not as it looks today — so peers coming and going never invalidates an old proof. To stay fast as the network grows, a lookup heads straight for its destination where the route is known and falls back to a bounded search where it isn't. However it's found, every proof is re-checked by the math, so a wrong turn can only make a lookup miss — never make it lie.</p>
+        </details>
       </div>
     </div>
   </section>