Design 25's bus module is unhealthy only on a verdict left unanswered; design 55 keeps its sent events in a state of its own

03-DESIGN/01-to-be/25-the-bus-on-nats.md

@@ -697,8 +697,8 @@ modules' names meet.
   check and at take-in (ADR 0578; ADR 0595 §8).
 - **The bus module has a process of its own** beside its tool bundle, with a declared health check. Its credential
   creates streams and buckets under modules' names only, and deletes only through `drop` and `recreate`. Its health
-turns unhealthy, naming the cause, when its last pass over the verdicts or over fill is more than three minutes
-old, so the only guard against a store filling never stops without a sound; another module's entry at 75 percent
+turns unhealthy, naming the cause, when an accepted verdict has waited on its durable consumer, unanswered, for
+more than three minutes, or when its last pass over fill, which runs every minute, is more than three minutes old, so the only guard against a store filling never stops without a sound; another module's entry at 75 percent
 raises that module's condition and leaves the bus module healthy.
 - **The binding travels on `created`** (ADR 0595 §1, §7). The grants part, which issues every membership, hears it
   on a durable consumer and writes the binding (the names on the bus) into the module's membership, kept in its own
@@ -707,7 +707,8 @@ raises that module's condition and leaves the bus module healthy.
   create hands no binding. **A refused or overdue creation is loud**: overdue means no `created` or `refused` within
   five minutes of an accepted verdict that asks for the entry. The condition is raised by the watchman, which already
   hears the judge's verdicts, never by the bus module, which cannot raise it while it is down; it names the module
-  and the entry, and a later `created` clears it.
+  and the entry; a later `created` clears it, and so does a later accepted verdict of that module that no longer asks
+  for the entry.
 - **Only the owner reaches it** (ADR 0596 §2). The membership grants the owner's account its own entries and no
   other module's: the new form has no readers. What another module needs of that data it asks through the owner's
   tools or seat verbs, and what the owner lets others hear is its declared events, subscribed to through

03-DESIGN/01-to-be/55-the-knowledge-base.md

@@ -78,6 +78,7 @@ and the knowledge base works out each design's state (ADR 0423, ADR 0424).
    │                         digest and the sequence of their write-section
    │   state     asked       one key per part asked of the judge and not yet answered: ticket, node, when
    │   state     findings    the whole-set findings standing now, and the told marks (told.<topic>)
+   │   state     sent        per record, the last operation whose event was sent
    │   stream    reviews     one message per part reviewed: the digest judged, the verdict, the findings
    ├ written through         the tool runner's apply on the control-node, the only publisher on the
    │                         ledger's history (ADR 0597 §3, §9)
@@ -122,8 +123,11 @@ caller or the module gave (ADR 0597 §7; [design 25](25-the-bus-on-nats.md) § 1
 
 **Every operation's event is sent once, after a restart too.** `apply` emits nothing; the module sends the event of
 each operation it applied (`submitted`, `reviewed` and the rest) with the operation's sequence as the message's
-id, so the bus drops a second send, and keeps the last sequence it sent per record in the state `findings`
-(`sent.<kind>.<number>`). At start it sends the events of every later operation in each record's history, so a
+id, so the bus drops a second send within its duplicate window, and keeps the last sequence it sent per record in a
+state of its own, `sent` (one key `<kind>.<number>`). The duplicate window of its event stream and of `reviews` is
+one day, far longer than a start (40 seconds at most, § 10); a module stopped between a send and its `sent` key for
+longer than a day sends that one event again, which a consumer already takes as a bus delivered at least once. A
+missed send is never chosen over a second one. At start it sends the events of every later operation in each record's history, so a
 module stopped between `apply` and its event loses none, and a consumer of `mesh-knowledge.reviewed` never waits for
 one that was never sent.
 
@@ -277,7 +281,7 @@ starting figures, from today's 83 MB for 736 records with every version copying
 | `records` (state) | ledger | 64 MiB |
 | `reviews` | a bare stream, its own configuration | 512 MiB |
 | `drafts` | state | 64 MiB |
-| `asked`, `findings` | state | 64 MiB, the template's bound |
+| `asked`, `findings`, `sent` | state | 64 MiB, the template's bound |
 
 A write refused at a cap names the cap, and the module's health turns unhealthy naming it.