diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b6f333d..63640fd 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -134,7 +134,10 @@ JAZZER_FUZZ=1 mvn -Dtest=TopicRouterFuzzTest test
 2. Keep the change focused — one logical change per pull request.
 3. Make sure `mvn verify` passes.
 4. Update the README / `docs/` when the configuration surface or the
-   metrics inventory changes.
+   metrics inventory changes. `DocumentationContractTest` pins the
+   configuration guide's defaults tables and the metrics overview's
+   inventory to the constants, so a changed constant fails `mvn verify`
+   until the tables follow.
 5. Open the pull request with a description of *what* changed and *why*.
 
 ## Reporting bugs and requesting features
diff --git a/README.md b/README.md
index 81403a1..64b14bc 100644
--- a/README.md
+++ b/README.md
@@ -193,9 +193,11 @@ Reference for every supported element:
 | `<includeCallerData>`        | No       | boolean | Captures caller data on the logging thread before the asynchronous hand-off (default false); only relevant when a fallback layout uses `%caller`. |
 | `<appender-ref ref="..."/>`  | No       | ref     | Single fallback appender — see [Resilience](#resilience).                          |
 
-Missing or blank values for the five required elements cause the
-appender to refuse startup with an explicit `addError` on Logback's
-status manager. The error message identifies which element is missing.
+A missing `<encoder>` or a blank `<environment>`, `<component>` or
+`<cmdbId>` makes the appender refuse startup with an explicit `addError`
+on Logback's status manager naming the element; a missing
+`<defaultTopic>` or unusable producer properties fail the pipeline
+construction the same way.
 
 ## Delivery guarantees
 
@@ -302,10 +304,12 @@ Three resilience mechanisms run independently per topic class:
    source of truth for delivery outcome, so delivery failures are
    never invisible.
 
-3. **Fallback appender.** When the circuit is open or a send fails
-   synchronously, the original `ILoggingEvent` is routed to the
-   configured fallback appender. Standard Logback `<appender-ref>`
-   syntax is supported:
+3. **Fallback appender.** Whenever an event cannot reach Kafka — an
+   open breaker, a throttled probe, a failed send (synchronous or via
+   the callback), a full send queue, a hot-path error, or the remainder
+   at shutdown — the original `ILoggingEvent` is routed to the
+   configured fallback appender, tagged with the reason in the metrics.
+   Standard Logback `<appender-ref>` syntax is supported:
 
    ```xml
    <appender name="KAFKA_FALLBACK_FILE" class="ch.qos.logback.core.FileAppender">
@@ -443,7 +447,7 @@ hazard — `synchronized` blocks in the appender hot path, which cause
 carrier-thread pinning on virtual threads and Reactor-Netty
 event-loop stalls — does not arise: the appender extends
 `UnsynchronizedAppenderBase`. There are no locks in the hot path;
-only atomics and volatiles.
+only atomics, volatiles and a per-thread reentry flag.
 
 Two reactive-specific concerns remain that are worth tuning per
 service.
@@ -505,12 +509,12 @@ buffered record.
 Services that run BlockHound (`io.projectreactor.tools:blockhound`)
 in their integration tests will see the appender's internal
 operations flagged as blocking — most notably the
-`LinkedBlockingQueue.offer()` in the [FallbackDispatcher] and the
-internals of `KafkaProducer.send()`. These are not true blocks in
-the harmful sense (the queue offer is non-blocking on a non-full
-queue; the producer send is the operator's accepted
-`max.block.ms` budget), but BlockHound's heuristics don't know
-that.
+`LinkedBlockingQueue.offer()` of the per-class send queue (every
+event) and of the fallback dispatcher. These are not true blocks in
+the harmful sense (the offer is non-blocking, a full queue rejects
+instead of waiting; `KafkaProducer.send()` itself runs on the
+appender's own worker threads, never on the caller), but BlockHound's
+heuristics don't know that.
 
 Add an allow-list entry in the test setup:
 
@@ -594,7 +598,7 @@ Micrometer on the classpath and emits no metrics until
 | `kafka.appender.events.dispatched`  | Counter | `topic.class`                     | Events handed to `producer.send` without a synchronous failure (callback outcome unknown) |
 | `kafka.appender.events.fallback`    | Counter | `topic.class`, `reason`           | Events diverted from Kafka (to the fallback if configured, otherwise dropped) |
 | `kafka.appender.send.duration`      | Timer   | `topic.class`, `outcome`          | Wall-clock send duration from invocation to callback          |
-| `kafka.appender.fallback.dropped`   | Counter | —                                 | Events lost because the fallback dispatcher queue was full    |
+| `kafka.appender.fallback.dropped`   | Counter | —                                 | Events lost by the fallback dispatcher (queue full, `doAppend` threw, worker died, shutdown remainder) |
 | `kafka.appender.fallback.queue.size`     | Gauge   | —                                 | Current depth of the fallback dispatcher queue                |
 | `kafka.appender.fallback.queue.capacity` | Gauge   | —                                 | Maximum depth of the fallback dispatcher queue                |
 | `kafka.appender.send.queue.size`         | Gauge   | `topic.class`                     | Current depth of the class's send dispatcher queue            |
@@ -692,15 +696,17 @@ happens after the `MeterRegistry` is available:
 ```kotlin
 val loggerContext = LoggerFactory.getILoggerFactory() as LoggerContext
 loggerContext.loggerList.asSequence()
-    .flatMap { logger ->
-        generateSequence({ logger.iteratorForAppenders() }) { null }
-            .first().asSequence()
-    }
+    .flatMap { logger -> logger.iteratorForAppenders().asSequence() }
     .filterIsInstance<KafkaAppender>()
     .distinct()
     .forEach { it.bindMeterRegistry(meterRegistry, Tags.empty()) }
 ```
 
+(Descend into `AsyncAppender` wrappers yourself if you use them; the
+Spring binding does.) A repeated `bindMeterRegistry` call replaces the
+previous binding, and a call on a stopped appender is ignored with a
+status warning.
+
 Pre-Spring log events (Logback initialization, Spring bootstrap
 logging) are not counted in either setup — this is a deliberate
 trade-off, since capturing them would require a static
@@ -861,8 +867,12 @@ AUDIT record end-to-end against an Apache Kafka container — real
 serializers, compression, headers, and the AUDIT acks/idempotence
 handshake.
 
-The module has no Maven plugins beyond the Kotlin compiler and Surefire.
-Java 21 and Kotlin 2.4.10.
+The artifact targets Java 21 (Kotlin 2.4.10); building needs JDK 24+
+because of the JVM flags in `.mvn/jvm.config`. The quality gates that
+run with `mvn verify` (ktlint, JaCoCo, the documentation-contract test
+that pins the guide's tables to the constants, Jazzer regression
+inputs) and the CI-only scans (OSV via CycloneDX SBOM, CodeQL, nightly
+fuzzing) are described in [CONTRIBUTING.md](CONTRIBUTING.md).
 
 ## Contributing
 
diff --git a/benchmarks/README.md b/benchmarks/README.md
index 9be0c7b..0b41fd6 100644
--- a/benchmarks/README.md
+++ b/benchmarks/README.md
@@ -24,15 +24,16 @@ java -jar benchmarks/target/benchmarks.jar AppendPipelineBenchmark -bm sample -t
 ```
 
 All benchmarks use 3 forks, 5 warmup and 5 measurement iterations by
-default (annotation-driven). Raw outputs of the 2026-08-29 verification
-session live under `results/2026-08-29/`.
+default (annotation-driven). Raw outputs live under `results/<date>/`:
+the 2026-08-29 verification session, the 2026-08-30 re-run after the
+header fix, and the 2026-09-07 sender-path re-measurement.
 
 ## Inventory
 
 | Benchmark | Verifies | What it measures |
 |---|---|---|
-| `RecordHeadersBenchmark` | PERF_ANALYSIS-2026-08-29T11-01-08 finding 2 | Per-record header construction: production shape (5 × `headers().add`) vs. one shared pre-built header list. Primary metric: `gc.alloc.rate.norm`. |
-| `SenderPathBenchmark` | finding 3 | The delivered-path worker side (`ResilientMessageSender.send` incl. breaker, record build, instant-success callback) with `metricsBound=false/true`; the param delta is the observability envelope per delivered event. |
+| `RecordHeadersBenchmark` | PERF_ANALYSIS-2026-08-29T11-01-08 finding 2 | Per-record header construction: the pre-fix shape (5 × `headers().add` per record) vs. the shared pre-built header list production uses since the fix (`EnrichedRecord.headers`). Historical evidence, not a current-code regression guard. Primary metric: `gc.alloc.rate.norm`. |
+| `SenderPathBenchmark` | finding 3 | The delivered-path worker side (`ResilientMessageSender.send` incl. breaker, record build, instant-success callback object) with `metricsBound=false/true`; the param delta is the observability envelope per delivered event. Also the guard for the callback object's scalar replaceability: 112 B/op unbound since the `@Volatile` removal (`results/2026-09-07/`). |
 | `HandoffBenchmark` | finding 1 | The caller-side hand-off primitive: N producers `offer` into a bounded `LinkedBlockingQueue` while one batch-draining consumer keeps it near-empty (worst-case put-lock contention; `rejected` aux counter proves the regime). Thread split via `-tg 1,<producers>`. |
 | `AppendPipelineBenchmark` | secondary evidence (findings 1/3), caller-side allocation | The full production `doAppend` path open-loop against a `DiscardingProducer`. Under open load it saturates the worker and measures the shedding regime — the teardown prints the achieved path mix (delivered vs. diverted), which is part of the evidence, not a hidden variable. |
 
diff --git a/docs/config/example-logback-spring.xml b/docs/config/example-logback-spring.xml
index 30af221..7a2590b 100644
--- a/docs/config/example-logback-spring.xml
+++ b/docs/config/example-logback-spring.xml
@@ -83,7 +83,8 @@
         <!-- Multi-line "key=value" Kafka producer configuration. Helm /
              Spring placeholder substitution happens before the appender
              parses the text. Lines starting with '#' are treated as
-             comments. Whitespace around keys and values is trimmed. -->
+             comments. Leading whitespace (XML indentation) is ignored,
+             trailing whitespace on values is trimmed. -->
         <kafkaProducerProperties>
             bootstrap.servers=${KAFKA_BOOTSTRAP_SERVERS:-kafka.example.com:9092}
             security.protocol=SSL
@@ -155,9 +156,10 @@
              Recommended: leave unset or set to false. -->
         <!-- <debug>true</debug> -->
 
-        <!-- Fallback appender. When the Kafka circuit breaker is open or
-             a send fails, the event is delivered through this appender
-             instead. Without it, failed events are silently dropped. -->
+        <!-- Fallback appender. When an event cannot reach Kafka (open
+             circuit breaker, failed send, full send queue, shutdown
+             remainder), it is delivered through this appender instead.
+             Without it, such events are silently dropped. -->
         <appender-ref ref="KAFKA_FALLBACK_FILE"/>
 
     </appender>
@@ -165,9 +167,10 @@
     <!-- =================================================================
          Root logger configuration. Reference the KafkaAppender DIRECTLY:
          wrapping it in an AsyncAppender is NOT recommended - the appender
-         already bounds caller-thread blocking internally (max.block.ms,
-         circuit breaker, async fallback dispatcher), and default
-         AsyncAppender settings weaken the loss semantics. See README,
+         already performs producer.send on its own per-class worker
+         threads (the logging thread only encodes and enqueues in O(1)),
+         and default AsyncAppender settings weaken the loss semantics.
+         See README,
          "Should I wrap this in a Logback AsyncAppender?".
 
          Only for sub-100 ms hard-latency SLAs is a wrapper justified,
diff --git a/docs/config/kafka-appender-config-guide.md b/docs/config/kafka-appender-config-guide.md
index 19e5847..a9c410f 100644
--- a/docs/config/kafka-appender-config-guide.md
+++ b/docs/config/kafka-appender-config-guide.md
@@ -20,6 +20,7 @@ metrics are catalogued in [`metrics-overview.md`](../metrics/metrics-overview.md
 - [10. Startup validation and failure behavior](#10-startup-validation-and-failure-behavior)
 - [11. Wrapping in an AsyncAppender](#11-wrapping-in-an-asyncappender)
 - [12. Defaults quick reference](#12-defaults-quick-reference)
+- [13. What is deliberately not configurable](#13-what-is-deliberately-not-configurable)
 - [Appendix A: The four-class topic model](#appendix-a-the-four-class-topic-model)
 
 ---
@@ -257,22 +258,37 @@ built-in overrides.
 
 ### Composition
 
-The producer properties are assembled in two layers, then the serializers are
-forced:
+The producer properties are assembled in four layers, then the serializers
+are forced:
 
 1. **Base properties** — everything from `<kafkaProducerProperties>`
    ([§3](#3-kafka-producer-properties)).
 2. **Default overrides** — a set of built-in defaults applied with
    `putIfAbsent`: your value wins wherever you set the same key; a default
-   only fills a gap you left.
-3. **Forced serializers** — `key.serializer` and `value.serializer` are set
+   only fills a gap you left. One default is conditional: when you set
+   `enable.idempotence=true` yourself, the class's `acks` default is
+   skipped (the Kafka client refuses idempotence with anything but
+   `acks=all`), so Kafka's own `acks=all` default applies.
+3. **Mandatory overrides** — values that win even over an explicit value
+   you set. The set is **empty for `TECHNICAL` and `PERFORMANCE`**, so it
+   changes nothing in the minimal configuration; it carries the enforced
+   values of the AUDIT/FUNCTIONAL classes once a `<mapping>` activates
+   them ([Appendix A](#appendix-a-the-four-class-topic-model)).
+4. **The `max.block.ms` cap** — a ceiling for *every* class (500 ms;
+   200 ms for `PERFORMANCE`): a lower value of yours is kept, a higher or
+   unparseable one is clamped to the ceiling and reported at startup in
+   the same format as a mandatory-override conflict
+   ([§10](#10-startup-validation-and-failure-behavior)). It bounds each
+   send worker's worst-case stall per event ([§8](#8-producer-lifecycle-and-shutdown)).
+5. **Forced serializers** — `key.serializer` and `value.serializer` are set
    to `ByteArraySerializer` unconditionally ([§3](#3-kafka-producer-properties)).
 
-> A generic third merge layer — *mandatory* overrides that win even over an
-> explicit value you set — is **empty for the `TECHNICAL` class**, so it
-> changes nothing in the minimal configuration. It carries the enforced
-> values of the AUDIT/FUNCTIONAL classes once a `<mapping>` activates them;
-> see [Appendix A](#appendix-a-the-four-class-topic-model).
+The merged result is then validated: wherever `enable.idempotence=true` is
+in effect (mandated for `AUDIT`, or set by you for any class), `acks` must
+be `all`/`-1`, `retries` must be positive and
+`max.in.flight.requests.per.connection` at most 5. A violation aborts
+`start()` with a named error instead of the Kafka client's generic
+construction failure.
 
 ### Default overrides
 
@@ -343,8 +359,9 @@ filling the gaps and the serializers forced:
 | `value.serializer`   | forced                         | `ByteArraySerializer`    |
 
 Nothing you set is overruled for the `TECHNICAL` class — it has no mandatory
-overrides. (For a topic mapped to `AUDIT`, the same `acks=1` is forced to
-`acks=all`, with a startup warning; see
+overrides; only a `max.block.ms` above its 500 ms cap would be clamped.
+(For a topic mapped to `AUDIT`, the same `acks=1` is forced to `acks=all`,
+with a startup warning; see
 [Appendix A](#appendix-a-the-four-class-topic-model).)
 
 ---
@@ -437,9 +454,12 @@ default extractor reads the MDC entry `traceId` and uses it if non-blank
 **and at most 128 characters long**; otherwise the key is `null` and Kafka
 distributes the record via its configured partitioner (sticky-random by
 default). Using the trace id as the key keeps all records of one trace on
-the same partition, preserving their relative order. A custom extraction
-strategy (session id, account id, …) is supported at the API level but is
-not currently exposed through XML.
+the same partition, preserving their relative order. An MDC that cannot be
+read (a `LoggerContext` without an MDC adapter, as in some embedded
+setups) yields no key rather than a hot-path failure. The key source is
+fixed ([section 13](#13-what-is-deliberately-not-configurable)); a
+different key (session id, account id, …) would be added as an
+XML-bindable appender property, per ADR-0002.
 
 ### Why the key is length-bounded
 
@@ -515,9 +535,8 @@ logging volume all probes fire within microseconds and then every further
 event is routed to the fallback for the duration of the Kafka round-trip,
 even after the cluster has recovered. The throttle spreads probes out to one
 per **`halfOpenProbeGap`** (default **5 ms**), so the probes are dispatched
-over `N × gap` of wall time. It is transparent in CLOSED and OPEN. Setting
-the gap to zero disables it. This is a programmatic setting; it is not
-currently exposed through XML.
+over `N × gap` of wall time. It is transparent in CLOSED and OPEN. The gap
+is fixed in code ([section 13](#13-what-is-deliberately-not-configurable)).
 
 ### Fallback appender
 
@@ -537,11 +556,35 @@ Attach a fallback appender with `<appender-ref ref="…"/>`:
 </appender>
 ```
 
-An event is routed to the fallback when the breaker is open, the throttle
-gate denies a probe, or a send fails (synchronously or via callback error).
+An event is routed to the fallback whenever it cannot reach Kafka; the
+`reason` tag of `kafka.appender.events.fallback` names the gate
+([§9](#9-metrics-integration)):
+
+- `breaker.open` — the class's circuit breaker denied permission;
+- `throttle` — the half-open throttle denied a probe;
+- `send.error` — `producer.send` threw, the client reported an error
+  through the callback (synchronously before `send` returned, or later
+  from its I/O thread), or the class's send worker died;
+- `encoder.error` — a hot-path exception before the send (encoder,
+  routing);
+- `queue.full` — the class's send queue was full;
+- `shutdown` — the event was still queued or in flight when the appender
+  stopped, or was logged after it stopped.
+
+Every event is diverted at most once, whichever gate fires first.
 
 - **Single slot, first wins.** Only one fallback appender is attached; a
   second `<appender-ref>` is ignored.
+- **Owned by the appender.** `stop()` stops the fallback appender (it
+  stays attached and inspectable). Do not share it with other loggers
+  unless a full-context shutdown is the only stop path in your
+  deployment: a selective stop of the Kafka appender would silence the
+  shared appender for everyone.
+- **Must not log through SLF4J per event.** The fallback's `doAppend`
+  runs on the dispatcher's worker thread, which carries the appender's
+  reentry guard: log events it emits there are dropped (no metrics, no
+  fallback) instead of looping back into the pipeline. Logback's own
+  file appenders report through the status manager and are unaffected.
 - **No fallback ⇒ silent drop.** Leaving it unset is the operator's explicit
   choice that best-effort delivery is acceptable. Configuring one is the way
   to say "loss is unacceptable here". **Strongly recommended in production.**
@@ -555,7 +598,11 @@ gate denies a probe, or a send fails (synchronously or via callback error).
 - **Overflow ⇒ drop, counted.** If the fallback is slow enough to fill the
   queue, further events are dropped (never blocked) and counted in the
   `kafka.appender.fallback.dropped` metric. The system is already degraded
-  (Kafka delivery is failing); an unbounded queue would grow to OOM.
+  (Kafka delivery is failing); an unbounded queue would grow to OOM. The
+  same counter covers a `doAppend` that throws (the loss is counted, the
+  exception swallowed) and a worker that died: an `Error` escaping the
+  fallback appender ends the worker, is reported once as a status
+  warning, and every event offered afterwards is dropped and counted.
 - **Shutdown.** On `close()` the worker keeps delivering for the whole
   **5 s** budget; only then is it interrupted, with a further **0.5 s**
   grace for a delivery parked in `doAppend`. Events still queued or in
@@ -570,16 +617,45 @@ producer fails to construct, the already-created ones are closed and the
 exception is rethrown — the registry is never partially initialized, and
 `start()` reports the failure via `addError`.
 
-At `stop()` the send dispatchers are closed first, **in parallel**
-within one shared **~2 s** budget: each drains its queue by still
-sending through the open producers; whatever cannot be sent in time
-diverts to the fallback appender with metric reason `shutdown`. Then every producer is closed **in parallel**
-within a **10 s** overall budget. A per-producer close failure does not
-prevent the others from closing (partial cleanup beats none); failures
-are aggregated and surfaced as a status warning. The parallel close
-keeps the total well inside the Kubernetes default
+`stop()` runs its teardown once (a repeated `stop()` is a no-op) in this
+order:
+
+1. **Ingress closed.** Logback's `isStarted` gate is cleared first, so no
+   new event enters the multi-second teardown; an `append` that already
+   passed the gate is covered by the dispatchers' post-close accounting
+   (reason `shutdown`).
+2. **Send dispatchers, in parallel, ~2 s.** Each worker keeps sending
+   through the still-open producers for the **1 s** drain budget and is
+   then interrupted with **0.5 s** grace; whatever is still queued or in
+   flight diverts to the fallback with metric reason `shutdown`. The
+   budget is shared across classes, so it does not stack. CAUTION: up to
+   one send queue per active class drains into the single fallback
+   queue of the same default capacity; on a stop during an outage the
+   overflow is dropped and counted.
+3. **Producers, in parallel, 10 s** (plus a 0.5 s join margin). A
+   per-producer close failure does not prevent the others from closing
+   (partial cleanup beats none); failures are aggregated and surfaced as
+   a status warning.
+4. **Fallback dispatcher, 5 s drain + 0.5 s grace.** Only now, because
+   the two steps before it still feed the fallback. The remainder is
+   dropped and counted; a non-zero lifetime drop count is reported as a
+   status warning.
+5. **Metrics unbound** only after the dispatchers closed, so a scrape
+   during the teardown still sees the shutdown diversions and drops.
+6. **Fallback appender and encoder stopped.** The fallback appender
+   stays attached ([§7](#7-resilience-circuit-breaker-throttle-fallback)).
+
+Worst case ≈ 18 s in total — inside the Kubernetes default
 `terminationGracePeriodSeconds: 30` regardless of how many classes are
-active.
+active; the parallel closes are what keep the budgets from stacking.
+
+**No restart.** A `start()` on a running appender is ignored with a
+status warning; `start()` after `stop()` is refused with an error naming
+[ADR-0004](../adr/ADR-0004-appender-instances-are-not-restartable.md).
+Logback itself never restarts an appender instance — a reconfiguration
+stops the old instances and builds new ones — and the appender follows
+that lifecycle; program code that needs a fresh pipeline creates a new
+instance.
 
 ### Interaction with `delivery.timeout.ms`
 
@@ -612,7 +688,9 @@ kafkaAppender.bindMeterRegistry(meterRegistry, Tags.of("application", "payment-s
 
 `commonTags` is optional (default `Tags.empty()`) — the registry's own common
 tags are usually enough. Calling this on a stopped appender is a no-op with a
-status-manager warning.
+status-manager warning. A repeated call replaces the previous binding (its
+meters are removed first), so a context refresh or manual re-wiring never
+duplicates meters.
 
 ### Spring binding
 
@@ -631,8 +709,16 @@ class LoggingConfig {
 }
 ```
 
-Binding is idempotent (each appender bound once by reference identity).
-Pre-Spring log events are not counted.
+The binding decides on each appender's own bound state, not on instance
+identity: an appender that is already bound is skipped, one whose earlier
+bind failed is retried on the next call, and one that is not started yet
+is deferred. `bindAppenders()` is public and idempotent, which matters
+for the one gap: a Logback reconfiguration at runtime
+(`<configuration scan="true">`, a programmatic reset) replaces every
+appender instance, and neither Spring nor Logback fires a callback after
+the new configuration is in place — the replacement appenders stay dark
+until `bindAppenders()` is called again. Pre-Spring log events are not
+counted.
 
 ### Metric inventory
 
@@ -642,10 +728,10 @@ See [`metrics-overview.md`](../metrics/metrics-overview.md) for the full catalog
 | Metric                                     | Type    | Extra tags                | Meaning |
 | ------------------------------------------ | ------- | ------------------------- | ------- |
 | `kafka.appender.events.accepted`           | Counter | `topic.class`             | Events entering `append()` (after class routing). |
-| `kafka.appender.events.dispatched`         | Counter | `topic.class`             | Events handed to `producer.send()` (callback outcome not yet known). |
+| `kafka.appender.events.dispatched`         | Counter | `topic.class`             | Events handed to `producer.send()` without a synchronous failure (broker outcome still unknown; an event the client rejected before `send()` returned counts as `send.error` fallback instead). |
 | `kafka.appender.events.fallback`           | Counter | `topic.class`, `reason`   | Events diverted from Kafka delivery (to the fallback if configured, otherwise dropped). |
 | `kafka.appender.send.duration`             | Timer   | `topic.class`, `outcome`  | Wall-clock from `send()` invocation to callback. |
-| `kafka.appender.fallback.dropped`          | Counter | —                         | Events dropped by the dispatcher (queue full / shutdown timeout). |
+| `kafka.appender.fallback.dropped`          | Counter | —                         | Events lost by the fallback dispatcher: queue full, `doAppend` threw, worker died, or shutdown remainder. |
 | `kafka.appender.fallback.queue.size`       | Gauge   | —                         | Current dispatcher queue depth (live per scrape). |
 | `kafka.appender.fallback.queue.capacity`   | Gauge   | —                         | Fixed queue capacity. |
 | `kafka.appender.send.queue.size`           | Gauge   | `topic.class`             | Current send-dispatcher queue depth for the class. |
@@ -680,13 +766,21 @@ appender **stopped** rather than throwing. Checked conditions:
 
 - `<encoder>` is present.
 - `<component>`, `<cmdbId>`, `<environment>` are non-blank.
+- `<sendQueueCapacity>` is positive.
 - Pipeline construction succeeds (`<kafkaProducerProperties>` parses,
-  `<defaultTopic>` is a valid Kafka topic name, all producers construct).
+  `<topicMapping>` passes the checks of [§5](#5-topic-routing), the
+  idempotence preconditions of [§4](#4-producer-property-composition)
+  hold, all producers construct).
+
+A `start()` on a running appender is ignored with a warning; after
+`stop()` it is refused ([§8](#8-producer-lifecycle-and-shutdown)).
 
-Two conditions are reported as **warnings** and do *not* stop the appender:
+Three conditions are reported as **warnings** and do *not* stop the appender:
 
 - **Mandatory-override conflicts** — a value of yours was overruled for a
   compliance-graded class ([§4](#4-producer-property-composition)).
+- **`max.block.ms` above the class cap** — clamped to the cap and reported
+  in the same format ([§4](#4-producer-property-composition)).
 - **Cleartext transport for a graded class** — a topic classified `AUDIT`
   or `FUNCTIONAL` is served by a producer whose `security.protocol` is
   unset or `PLAINTEXT`. Such records are enforced to be durable but travel
@@ -701,7 +795,11 @@ Two conditions are reported as **warnings** and do *not* stop the appender:
 
 In the hot path, an unexpected per-event failure (encoder bug, OOM) is
 logged **once** (subsequent occurrences suppressed to prevent log storms)
-and the event is routed to the fallback.
+and the event is routed to the fallback. Two runtime conditions are
+reported as warnings as well: a send or fallback worker that dies (an
+`Error` escaping the delivery) — the affected class then diverts every
+event with reason `send.error`, the fallback dispatcher drops and counts
+— and, at `stop()`, a non-zero lifetime fallback drop count.
 
 **Pipeline-construction failures report the exception type only.** The
 message and stack trace of a failing producer construction are authored by
@@ -750,6 +848,8 @@ bound.
 | `client.id` (unless set by operator)         | `tabellarium-<component>-<topicclass>` | code |
 | Fallback class for unmapped topics           | `TECHNICAL`                      | XML (`<defaultTopicClass>`) |
 | Partitioning key MDC source                  | `traceId`                        | code |
+| Partitioning key maximum length              | `128` characters (longer ⇒ no key) | code |
+| `max.block.ms` cap (per class)               | `500 ms`; `200 ms` for `PERFORMANCE` | code |
 | Circuit breaker: failure-rate threshold      | `50%`                            | code |
 | Circuit breaker: sliding window / min calls  | `20` / `10`                      | code |
 | Circuit breaker: open-state wait             | `30s`                            | code |
@@ -757,7 +857,7 @@ bound.
 | Half-open probe gap                          | `5 ms`                           | code |
 | Send dispatcher queue capacity (per class)   | `1024`                           | XML (`<sendQueueCapacity>`) |
 | Caller-data capture before async hand-off    | `false`                          | XML (`<includeCallerData>`) |
-| Send dispatcher drain on stop (parallel)     | `1 s` drain + margin, shared     | code |
+| Send dispatcher drain on stop (parallel)     | `1 s` drain + `0.5 s` interrupt grace, `2 s` shared budget | code |
 | Fallback dispatcher queue capacity           | `1024`                           | code |
 | Fallback dispatcher shutdown timeout         | `5 s` drain + `0.5 s` interrupt grace | code |
 | Producer close timeout                       | `10 s`                           | code |
@@ -830,7 +930,10 @@ TopicRouter.route(markers)                   → topic NAME      (e.g. "audit.se
 TopicTable.classFor(topicName)               → topic CLASS     (e.g. AUDIT)
    │
    ▼
-producer[class].send(record)  via  circuitBreaker[class]
+SendDispatcher[class].dispatch(…)            → bounded queue, O(1); the caller returns
+   │  (send worker thread of that class)
+   ▼
+producer[class].send(record)  via  throttle[class] + circuitBreaker[class]
 ```
 
 The class is never chosen directly. It is derived: **marker → topic name →
@@ -838,7 +941,8 @@ topic class → the producer and breaker for that class.** The producer for a
 class is built once at startup by merging your base properties with that
 class's overrides ([A.4](#a4-property-overrides-per-class)). Only classes that
 some topic actually resolves to are *active* — the appender creates a
-producer, breaker, and I/O thread only for those, never for dormant classes.
+producer, breaker, send worker and Kafka I/O thread only for those, never
+for dormant classes.
 (Without `<mapping>` elements everything resolves to the
 `<defaultTopicClass>` — `TECHNICAL` unless configured otherwise — which is
 then the only active class.)
@@ -889,20 +993,31 @@ Each class carries two sets of producer-property overrides:
 | `retries`            |  `10` |      —     |     —     |      —      |
 
 ¹ For AUDIT and FUNCTIONAL, `acks=all` (and, for AUDIT, `enable.idempotence=true`)
-is a **mandatory** override, not a default — you cannot weaken it.
+is a **mandatory** override, not a default — you cannot weaken it. For
+TECHNICAL and PERFORMANCE the `acks=1` default steps aside when you set
+`enable.idempotence=true` yourself ([§4](#4-producer-property-composition)).
+
+The `max.block.ms` default of each class is also its **cap**: a lower
+operator value is kept, a higher or unparseable one is clamped to the
+class value and reported at startup like a mandatory-override conflict.
 
 **Merge order** — for each active class the final producer properties are
-composed in three layers:
+composed in four layers, then validated:
 
 1. **Base properties** — everything from `<kafkaProducerProperties>`.
 2. **Default overrides** — applied via `putIfAbsent`; your value wins where
    both are present.
 3. **Mandatory overrides** — applied unconditionally; the enforced value wins,
    and any conflict is recorded.
+4. **The `max.block.ms` cap** — a higher value is clamped and recorded.
+
+With `enable.idempotence=true` in effect, `acks` must be `all`/`-1`,
+`retries` positive and `max.in.flight.requests.per.connection` at most
+5, otherwise `start()` fails with a named error.
 
-(In the minimal configuration only layers 1 and 2 have any effect, because
-the sole active class, `TECHNICAL`, has no mandatory overrides — see
-[§4](#4-producer-property-composition).)
+(In the minimal configuration only layers 1, 2 and 4 have any effect,
+because the sole active class, `TECHNICAL`, has no mandatory overrides —
+see [§4](#4-producer-property-composition).)
 
 **Mandatory-override violations** — when a value you set conflicts with a
 mandatory override, the appender logs a warning to Logback's status manager at
diff --git a/docs/metrics/metrics-overview.md b/docs/metrics/metrics-overview.md
index 8a80ecf..d22a20f 100644
--- a/docs/metrics/metrics-overview.md
+++ b/docs/metrics/metrics-overview.md
@@ -1,4 +1,4 @@
-## Complete metrics overview (as of all patches applied)
+# Metrics overview
 
 All metrics carry the `appender` tag, reflecting the Logback appender name (`"unnamed"` if not set). Plus, optionally, the common tags the operator passed to the `KafkaAppenderMetricsBinding` constructor.
 
@@ -6,10 +6,10 @@ All metrics carry the `appender` tag, reflecting the Logback appender name (`"un
 
 | Metric                             | Tags                                | When it is incremented                                       |
 | ---------------------------------- | ----------------------------------- | ------------------------------------------------------------ |
-| `kafka.appender.events.accepted`   | `appender`, `topic.class`           | Every event that enters `KafkaAppender.append()` (after routing to its topic class) |
+| `kafka.appender.events.accepted`   | `appender`, `topic.class`           | Every event that enters `KafkaAppender.append()` (after routing to its topic class; a hot-path failure before routing counts under `technical`). Events dropped by the reentry and self-logging guards never enter the pipeline and are not counted |
 | `kafka.appender.events.dispatched` | `appender`, `topic.class`           | Event was handed to `producer.send()` without a synchronous failure (callback outcome still unknown); an event the client rejected before `send()` returned - metadata timeout, buffer exhausted, record too large - counts as `events.fallback{reason="send.error"}` instead, never as both |
 | `kafka.appender.events.fallback`   | `appender`, `topic.class`, `reason` | Event was routed past Kafka (to the fallback appender if configured, otherwise dropped) |
-| `kafka.appender.fallback.dropped`  | `appender`                          | FallbackDispatcher had to drop (queue full or shutdown timeout) |
+| `kafka.appender.fallback.dropped`  | `appender`                          | FallbackDispatcher had to drop: queue full, the fallback appender's `doAppend` threw, its worker died, or events remained at shutdown |
 
 ### Timers
 
@@ -50,10 +50,10 @@ All metrics carry the `appender` tag, reflecting the Logback appender name (`"un
 | --------------- | ------------------------------------------------------------ |
 | `breaker.open`  | Circuit breaker gave no permission (OPEN, or HALF_OPEN exhausted) |
 | `throttle`      | Half-open throttle: probe gap not yet elapsed                |
-| `send.error`    | `producer.send()` threw synchronously or the callback reported an exception |
+| `send.error`    | `producer.send()` threw synchronously, the callback reported an exception, or the class's SendDispatcher worker died |
 | `encoder.error` | Hot-path exception before `send()` (encoder, routing, OOM)   |
 | `queue.full`    | The class's SendDispatcher queue was full — Kafka delivery cannot keep up |
-| `shutdown`      | Event was still in the SendDispatcher queue or in flight when the appender stopped |
+| `shutdown`      | Event was still in the SendDispatcher queue or in flight when the appender stopped, or was logged after it stopped |
 
 ### `outcome` — 2 possible values (only on `send.duration`)
 
@@ -132,7 +132,7 @@ Activated automatically via reflection when `io.micrometer.core.instrument.binde
 | `kafka.producer.buffer.available.bytes` | Free buffer bytes                         |
 | …                                       | (~40 producer-internal metrics in total)  |
 
-All carry the `topic.class` tag to disambiguate between the per-class producers.
+All carry the `topic.class` tag to disambiguate between the per-class producers, plus the `appender` tag and the common tags.
 
 ## Key Prometheus queries for a dashboard
 
@@ -162,7 +162,7 @@ resilience4j_circuitbreaker_state{name=~"kafka-appender-.*"}
 
 | Condition                                                    | Meaning                                                      | Severity                        |
 | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------- |
-| `kafka_appender_fallback_dropped_total > 0`                  | Actual data loss, FallbackDispatcher queue overflowed        | Critical                        |
+| `kafka_appender_fallback_dropped_total > 0`                  | Actual data loss in the fallback path (queue overflow, failing fallback appender, dead worker, shutdown remainder) | Critical                        |
 | `kafka_appender_fallback_queue_size / capacity > 0.8` for 5 min | Fallback appender is slower than the event rate              | Warning                         |
 | `resilience4j_circuitbreaker_state{state="open"} == 1`       | Cluster loss for this topic class                            | Critical (for AUDIT/FUNCTIONAL) |
 | `rate(kafka_appender_events_fallback{reason="send.error"}[1m]) > 0` for 10 min | Persistent send errors that were not filtered out as client errors | Warning                         |
diff --git a/src/main/kotlin/eu/inqudium/tabellarium/KafkaAppender.kt b/src/main/kotlin/eu/inqudium/tabellarium/KafkaAppender.kt
index e3d0e6e..410e55e 100644
--- a/src/main/kotlin/eu/inqudium/tabellarium/KafkaAppender.kt
+++ b/src/main/kotlin/eu/inqudium/tabellarium/KafkaAppender.kt
@@ -917,9 +917,9 @@ class KafkaAppender :
      * one fallback slot and the first one wins.
      *
      * **Ownership:** the KafkaAppender assumes it owns the attached
-     * fallback appender's lifecycle - [stop] stops it (keeping it
-     * attached, so a later [start] can start it again) to release file
-     * handles and worker threads. Do not attach an appender that is
+     * fallback appender's lifecycle - [stop] stops it (it stays attached
+     * and inspectable; the appender itself is not restarted, ADR-0004)
+     * to release file handles and worker threads. Do not attach an appender that is
      * simultaneously referenced by other loggers unless a full-context
      * shutdown is the only stop path in your deployment; a selective
      * stop of this appender would silence the shared appender for