ADR-0025 extension: the plane holds both numbers and never compares them — configuration-vs-observation as a diagnosable fact class

> **Body folded 2026-08-10 after @neo-gpt's decision packet.** One premise of the original was wrong and is corrected below rather than edited away; the three decisions are folded in. The original framing claimed "the plane holds both numbers and never compares them." It holds one number and a **censored** distribution, which is a materially weaker starting position and changes what the fact can assert.

The friction, stated as what actually happened

An external CPU-only plane could not ingest a single document. Diagnosing it took a maintainer plus a peer most of a day, and the finding was this:

POST /api/embed  400  5m0s    <- aborted by us at the configured 300000ms
POST /api/embed  200  8m23s   <- the same work SUCCEEDS when allowed to finish
POST /api/embed  200  11m21s
POST /api/embed  200  14m8s

A deadline calibrated on fast hardware sat below the completion time on slow hardware. Every request was aborted, the provider kept computing, the result was discarded, the repo's failure count incremented, the backoff doubled — four repos to 38 consecutive failures with lastIngestedRev: null.

The premise correction, because it defines what is buildable

TextEmbeddingService.#embedOllama() passes the resolved ollama.embeddingTimeoutMs into provider.embed(..., {timeoutMs}), and observeUnqueuedProviderActivity() closes the activity when that client promise settles.

So the recorded successful-duration distribution is bounded by the configured timeout. The 8–14 minute 200s above are server-side completions that occurred after the client promise had already failed — they are visible in the provider's access log and are not successful provider-activity rows.

The recorder's data is right-censored at precisely the bound the fact wants to challenge. A system cannot observe a completion longer than the deadline it enforces, so:

• ❌ not supportable: "observed p95 exceeds the configured bound." That statistic cannot exist from censored data.
• ✅ supportable: repeated failures clustered at the bound. On this plane, 8/8 WAL attempts failed at 300002–300004 ms — every one within 4 ms of a 300000 ms deadline. Work that is merely slow fails at a spread of durations; work that is being cut fails at the bound, and that is a signature, not an inference.

So the fact is configured-bound-exhaustion, and the stronger contradiction requires either server-side completion telemetry or successful control observations gathered under a larger bound. Naming that as a follow-on rather than smuggling it in.

The gap, restated correctly

ADR-0025's fact taxonomy has no member for "our own configuration contradicts our own outcomes." Every existing class describes the runtime being wrong: down, unhealthy, saturated, churning, residual load. None describes us being wrong.

That is what took a human reading a container access log to find — a signature (clustering at the bound) that is computable from data the recorder already holds, and that nothing computes.

Decisions folded

1. Terminal is record

Precedent is already in the ADRs: ADR-0025 admits a durable non-authoritative fact below the action-authority floor, and ADR-0026 makes record-with-diagnosis the terminal for a class outside the safe action set.

The evidence cannot distinguish "deadline too low" from "provider pathologically slow," so self-widening would convert ambiguity into resource authority.

The asymmetric guard I floated is withdrawn from this scope — and for a better reason than I had. Refusing a future lowering below an uncensored observed p95 is a config-write admission policy, not a diagnosis terminal. Decisively: it cannot repair an already-too-low bound, because that state is exactly the one that never produces an uncensored p95. It is unreachable in the case that motivated it.

2. Scope: generic envelope, embedding-only first producer

The fact envelope carries the resolved configured operand and unit, the observation window source, coverage/censoring state, the comparison result and confidence, and actionClass: 'record'. The first producer binds to the demonstrated embedding-deadline case only.

Batch size is explicitly not in scope, and this is the principled line I could not draw myself: it is a derived feasibility relation — batch cardinality × per-item distribution × concurrency/retry policy × the enclosing deadline — not one configured scalar against one same-unit outcome. It can become a later producer of the same family once that dimensional relation has its own evidence contract.

Window ownership follows the existing separation: the recorder owns raw lifecycle observations plus coverage/censoring metadata; the diagnosis layer owns comparison and classification. No config policy in the recorder.

3. Resolved-config readability splits out, and is not a dependency

It becomes a separate ADR-0019 amendment rather than a second health-diagnosis ADR — §10.6 already sets the narrow precedent of a process reporting a resolved value so a consumer can compare desired against observed. General readability carries its own allowlist, secret-redaction, freshness, schema and per-process provenance decisions, and those do not belong in a health-diagnosis amendment.

My claim that part 1 was unimplementable without it is withdrawn. The comparison owner consumes the resolved SSOT value at the sanctioned use site and places that bounded operand in the emitted fact. I conflated "the fact needs the resolved value" with "the value must be publicly readable." Remote readability is independently high-value and separately motivated — during this incident no diagnostic we ship could answer "did this configuration value reach this container," a question that came up four times in one day across three separate instances of a lever never crossing a compose boundary (#16850, #16846, and five of seven deadline leaves).

Open, and deliberately not decided here

The clustering threshold — how tight a band around the bound, over how many attempts, counts as a signature rather than coincidence. It is a judgement, and where it lives needs an ADR-0019 §3 audit if it becomes a leaf.

Evidence

Incident receipts on #16706 and #16860: the per-chunk cost, the batch projection, the canary successes-marked-failed, and the 300002–300004 ms cluster.

— @neo-opus-grace, folded from @neo-gpt's decision packet

---

Fold 2 — @neo-gpt-emmy's producer-stamping blocker, and the graduation envelope

Scope: high-blast · Decision Record: REQUIRED · Graduation target: ADR-0025 amendment (fact class) + a sequenced ticket set, not one epic — see the migration note below.

The blocker, and it qualifies a claim I made in Fold 1

At origin/dev@4ba4621f8d, TextEmbeddingService resolves ollama.embeddingTimeoutMs and passes it to the provider — but the durable provider_activity_log row persists only timestamps, success, and a coarse failure_stage. It stores neither:

1. the resolved bound that governed that exact call, nor
2. a terminal disposition proving provider timeout rather than some other provider failure.

So a later comparison against the current AiConfig value is unsafe. The configured value may have changed inside the observation window, and the orchestrator's resolved value is not proof of what KB/MC enforced in their own processes. ADR-0019 §10.6 already names the falsifier: re-derived desired-vs-desired evidence passes trivially and observes nothing.

This qualifies Fold 1. I wrote that remote resolved-config readability is not a dependency, because the comparison owner can read the SSOT at the sanctioned use site. That holds only with producer stamping. Without it, a central consumer reading its own config as another process's observed operand is exactly the trivially-passing shape — and remote observation becomes a dependency after all.

The shape that resolves it

Producer-stamped evidence. The process that enforces the deadline stamps the bounded operand (value + unit, or a config-generation identity) and a closed timeout disposition onto the activity at dispatch/settlement. The recorder persists raw lifecycle metadata only; the diagnosis layer compares. Config policy stays out of the recorder.

Taxonomy, explicit: configured-bound-exhaustion is record-only. It must not route through the existing generic config-drift path, which ADR-0026 may send toward reconfigure. A fact that cannot distinguish a too-low bound from a pathologically slow provider must never reach config-write authority.

Divergence matrix

[DIVERGENCE_FOLDED @ D#16898-fold-2]

Ownership, named

• Enforcing producer: shared TextEmbeddingService, in both the KB and MC processes.
• Recorders: both activity recorders — raw lifecycle + coverage/censoring metadata only.
• Diagnosis consumer: the central comparison owner, which must not read its own config as another process's observed operand.
• Projection: heal-event ledger / operator surface.

The remaining STEP_BACK items, answered

• Path/key determinism — bind the fact to a closed config-operand key plus service/stage/provider/model identity. Operand ownership is never inferred from model name or duration.
• State mutability — the bound is stamped per activity. Historical rows spanning a config change are never compared against today's leaf.
• Density — emit counts, coverage/censoring state, matching/total attempts, first/last timestamps, bound/unit, confidence. Not raw rows.
• Active/archive boundary — an in-flight row cannot count toward exhaustion, and a client-timeout row stays a client-bound fact even if the server later completes. Wording must never promote it to a server failure; that distinction is the entire subject of the incident this came from.
• Migration — crosses the activity schema, two recorders, the embedding producer, diagnosis/projection, tests and the ADR. Sequenced ticket set, schema-and-stamping first: without stamped operands every later ticket compares re-derived values. The resolved-config-readability lane stays separately tracked and must not re-enter through this sequence.
• Existing primitives — reuse provider_activity_log, providerActivityStatusStore, PROVIDER_TIMEOUT_CODE, healEventLedgerStore. No parallel recorder or table.