The Instrument

What the record can and cannot say

TI-2026-103O · Series: The Loud Hour · Letter O of 15 Confidence stated per claim. [DOCUMENTED] = direct observation, reproducible from primary data. [INFERRED] = reasoning over observations, with confidence bounded.

Updated 2026-07-30. Two changes, both additive; no original text has been altered. §11 — this letter issued eleven rules of evidence and the series went on to force nine more; §11 now carries the current canonical set, R1–R20, with the letter that produced each addition. §12 — open item 6, what caused the July volume step, is closed: Letter H settled it as AS197170's fleet arriving, and the two-phenomena caution beneath it is upgraded from method to [DOCUMENTED] finding.

Why this letter comes first

Fourteen other letters in this series count things. This one establishes whether the counting means anything.

A honeypot record is not a recording of the world. It is a recording of one sensor's encounter with the world, mediated by a database schema, an enrichment pipeline, a set of API endpoints, and whatever assumptions were compiled into each of them on the day they were written. Every number in the other fourteen letters passes through that chain. If the chain distorts, the numbers inherit the distortion — and a forensic series that does not audit its own instrument is not forensic, it is decorative.

So this letter is the audit. It documents eight defects found while building the burst census, states which are resolved and which are not, retracts one finding this investigation had already reached, and fixes the rules of evidence the rest of the series operates under.

Three of the eight would have produced published falsehoods. One of them — the last and largest — had already produced one, in an earlier draft of this series' own summary, and the retraction is set out in full in §11 rather than quietly patched. A provenance letter that only documents other people's errors is not an audit; it is advertising.

A note on scope. This letter describes the instrument functionally — session store, IP registry, timeline endpoint — rather than naming internal hosts, endpoint paths or service addresses. The operator can map these to real components; a reader cannot use them to map infrastructure. That is deliberate and consistent with the TLP:WHITE handling this series is published under. Auditability does not require publishing an internal API map.

1. The extent of the record

[DOCUMENTED] The corpus spans 2026-03-21T08:08:48Z to 2026-07-30T07:45Z — 3,040 recorded hourly buckets containing 170,038 sessions. The first session in the record is the first session that exists; this series draws on no earlier archive.

[DOCUMENTED] Coverage is not complete. Across the window, 104 hourly buckets contain no sessions at all, distributed:

A missing bucket is ambiguous on its face: it means either that nothing arrived, or that nothing was recorded. §10 shows the June cluster is the second kind, and that distinction turns out to matter for the single largest event in the census.

[DOCUMENTED] The corpus floor is non-stationary by more than an order of magnitude:

July carries 78% of all traffic in the record; its median hour is 11× April's.

No statement in this series about "unusual volume" is meaningful without naming the period it is unusual against. §7 and §10 explain why.

2. D1 — The phantom birthday

Status: RESOLVED. Severity: would have deleted the earliest burst from the record.

The IP registry records, for one of the series' principal actors:

179.43.139.58 — first_seen: 2026-05-21T11:32:48.573376Z

The timeline independently attributes 535 sessions to that same address at 2026-03-29T00:00Z — two months earlier. Both cannot be true.

The test

The session store was queried directly for that address's earliest rows, ascending.

[DOCUMENTED] Its first session is 2026-03-21T14:12:20.947856Z — the corpus's opening day. admin/admin, success, 0.7s, zero commands. The March data exists.

Two controls then distinguished a registry defect from a session defect:

The finding

[DOCUMENTED] Two unrelated addresses — different ASNs, different countries, different behaviour, first active five days apart in March — carry first_seen stamps 2.393 seconds apart, both on 2026-05-21 at 11:32. For the second, first_seen falls within half a second of created_at, the row-insertion time.

[INFERRED — confidence HIGH] The IP registry was backfilled by a sweep beginning 2026-05-21T11:32:48Z. Addresses already present in the session store received a first_seen equal to the moment the sweep reached them. Addresses first observed after the sweep receive a correct value — which is why the third control matches to the microsecond.

first_seen, for any address active before 2026-05-21T11:32Z, is the age of its database row, not the age of its activity.

That date recurs in §10. It is not a coincidence, and it is the single most important date in this letter.

Consequence

The session store is intact and authoritative. No burst attribution is affected. The March, May and June events stand exactly as censused.

Rule R1. All chronology derives from the session store. Registry first_seen is never cited as a first-observation date, and any external analysis quoting it for an address active before 2026-05-21T11:32Z is quoting a database artefact.

3. D2 — Two counters, one address

Status: PARTIALLY RESOLVED. Publication rule issued.

The registry and session store disagree on how much a given address did:

[DOCUMENTED] The ratio is not constant — exactly 1.00 for one address, almost exactly 2.00 for another.

The obvious hypothesis, that honeypot_hits counts credential attempts while the session store counts connections, survives one test and fails another. 91.92.40.202 attempted 761 distinct credentials across 1,524 sessions; two attempts per session predicts 3,048 against 3,047 observed. But 179.43.139.58's two credentials sum to 8,530 recorded attempts against 13,884 honeypot_hits — a 5,354 shortfall the hypothesis cannot absorb.

[INFERRED — confidence LOW] The counters have different definitions and at least one aggregates something absent from the session store. Not established here.

Rule R2. This series quotes session counts from the session store, independently verifiable by pagination. honeypot_hits is not quoted as a session, attempt or connection count anywhere in the remaining letters until its definition is established.

4. D3 — The empty hour

Status: CLOSED. Endpoint vindicated; the observation is real.

[DOCUMENTED] For bucket 2026-06-22T19:00Z, the timeline endpoint reports sessions_total: 1528 and ips_total: 1 — every session attributed to 179.43.139.58.

An hour in which no other address on the internet touched the sensor is a strong claim. Two explanations produce the same observation: the burst genuinely occupied the listener, or the endpoint under-reports co-occurring sources during high-volume buckets. An earlier draft of this letter left it open pending a control test. The test has now been run.

Test 1 — instrument agreement

Three independent code paths were queried for the same bucket:

[DOCUMENTED] All three agree.

Test 2 — the discriminating control

Agreement alone proves nothing if all three share a common defect. The decisive test is whether the endpoints suppress source counts at comparable volume elsewhere:

[DOCUMENTED] At volumes within 20% of the disputed hour, the same endpoints happily report 11, 26, 28 and 32 distinct sources. There is no volume-induced suppression. Had the artefact hypothesis been right, those rows would read 1 as well.

Test 3 — local context

[DOCUMENTED] The hours surrounding the burst were not busy but nearly silent:

2026-06-22 15:00      1 conn    1 source
2026-06-22 16:00      4 conns   2 sources
2026-06-22 17:00      1 conn    1 source
2026-06-22 18:00      1 conn    1 source
2026-06-22 19:00  1,528 conns   1 source   <-- burst
2026-06-22 20:00  1,336 conns   2 sources
2026-06-22 21:00      1 conn    1 source

A background of one source per hour makes a burst hour of one source entirely unremarkable. The claim only looked strong because it was measured against a monthly median of 10 connections — which was silently, and wrongly, read as ten distinct sources per hour. Ten connections per hour is six to eight sources on a normal June day, and one source on this one.

The finding

[DOCUMENTED] ips_total: 1 is a correct observation, corroborated by three instruments, in a period whose background was already one source per hour. The endpoint is not defective. The original suspicion was mine, and it was wrong.

Rule R3 (revised). Endpoint-derived distinct-source counts are usable where corroborated by an independent path and contextualised against local background. They are not to be compared against connection medians, which are a different unit (see R6).

D3 closes clean. But the local-context table above — ten near-silent hours immediately before the largest burst in the record, and a recording failure immediately after — is what opened D8, which does not close clean at all.

5. D4 — The silent clamp

Status: RESOLVED. This defect produced a wrong statement inside this investigation.

[DOCUMENTED] The per-IP temporal endpoint accepts an hours argument. Requested with hours=3200 — the full corpus — it returned a body containing time_window_hours: 720. The request was clamped to 30 days. No error, no warning; the only evidence is an echoed field.

The response then reported first_activity: 2026-06-30T20:27:31Z for 179.43.139.58, whose first session is 2026-03-21. Within the clamped window that is correct. Read as what it appears to be, it is wrong by 101 days — and it points at exactly the same address as D1, by a completely different mechanism.

This was read incorrectly during this investigation before the echoed field was noticed.

Rule R4. Every response is checked for echoed parameters differing from those sent, before its contents are used. Per-address history beyond 30 days is built from the session store.

[INFERRED — confidence MEDIUM] One clamped parameter found by accident implies others exist. R4 is written to catch the class, not the instance.

6. D5 — The global-average trap

Status: RESOLVED. Method replaced.

[DOCUMENTED] The pipeline's anomaly detector reports 365 anomalous hours, each scored against an avg field holding the constant 54.06 for all 3,040 buckets — the whole-corpus mean.

[DOCUMENTED] 342 of 365 fall in July. Given §1 — July's median is 102, nearly double the constant, while April's is 4 — this detector very largely restates "July had more traffic."

The reverse distortion is the damaging one. Against the constant, the largest event in the record scores 28.3×. Against its own local context it scores far higher. The May and June bursts, occurring against medians of 24 and 4, are dramatically more extreme relative to their surroundings than anything in July — and the constant-divisor view systematically understates exactly the events this series exists to examine.

Rule R5. Burst detection uses a centred 7-day rolling median local baseline; an hour qualifies at ≥10× local median and ≥150 absolute connections. This yields 44 burst hours merged into 26 events at a ≤2-hour join gap. Subject to R10 below.

The second half of the trap

[DOCUMENTED] The rolling-median detector returns no events after 2026-07-12 — not because bursting stopped, but because July's baseline outruns any single node's excursion.

The 2026-07-29T23:00 event — 348× that address's own four-month baseline, the event that prompted this series — is invisible to a corpus-level detector, reaching roughly 2–13× of corpus baseline depending on unit.

[DOCUMENTED — principal methodological finding] Corpus bursts and node bursts are distinct phenomena requiring distinct detectors. A corpus detector finds coordinated pressure across many sources; a node detector finds one machine departing from its own habit. Neither sees the other's events. Letter A publishes two censuses, and any claim that something is "the biggest burst" names which detector it is biggest under.

Letter N inherits the defensive consequence: alerting built on corpus thresholds did not, and structurally could not have, flagged 2026-07-29.

7. D6 — The gateway sessions

Status: RESOLVED. Negligible.

[DOCUMENTED] The session store contains sessions attributed to the sensor host's own container-bridge gateway — an RFC 1918 private address that cannot be an internet source. Enrichment assigns it country US and org "Internet Assigned Numbers Authority", both artefacts of attempting to geolocate an unroutable address. The specific address is withheld under the TLP:WHITE handling this series is published under; it identifies nothing about the adversary and everything about the sensor's own network.

[DOCUMENTED] It accounts for 6 sessions of 170,038 (0.0035%), spanning 2026-03-21 to 2026-06-28, three within the corpus's first four minutes with root/123456 and sub-0.2s durations.

[INFERRED — confidence HIGH] Local deployment verification traffic.

No aggregate is corrected; the contribution is four orders of magnitude below the smallest effect discussed. It is documented because an unexplained private address in an attack corpus should be found already disclosed rather than discovered.

8. D7 — Three numbers for one hour

Status: RESOLVED by vocabulary.

[DOCUMENTED] The hour 2026-07-29T23:00Z is variously 1,263, 1,180 and 1,042 depending on instrument. All three are correct; they count timeline connections for the sensor, credential attempts for the sensor, and credential attempts for one address.

Rule R6. Three terms, never interchanged:

• connection — one session record. The unit of the corpus census.
• attempt — one credential presentation. Several may occur per connection.
• node-connection — connections attributed to a single source address.

Every figure in the remaining letters is labelled with its unit. The three numbers above are not a discrepancy and are not reported as one; treating them as one would manufacture a controversy out of imprecision. D3 §4 shows the same error in a different guise — comparing a source count against a connection median.

9. D8 — Three sensors wearing one name

Status: RESOLVED as to existence and dating. Consequences pervasive. Severity: highest in this letter. Invalidates cross-period comparison and one published finding.

While closing D3, the daily success rate was examined for the first time across the full window. It is not stable. It is not even approximately stable.

[DOCUMENTED] For every single day from 2026-03-21 to 2026-05-20 inclusive — sixty-one consecutive days — the success rate is exactly 100.0%. Every connection that reached the sensor authenticated successfully.

[DOCUMENTED] On 2026-05-21 it falls to 5.1%. On 2026-05-22: 1,697 connections, zero successes. On 2026-05-23 it returns at 66.0%, then wanders between 18% and 78% through late June, before settling from 2026-06-29 into a stable 3–17%.

That first date — 2026-05-21 — is the same date, within the same hours, as the registry backfill sweep of D1.

[INFERRED — confidence HIGH] These are not fluctuations in attacker behaviour. They are three different sensor configurations, and the record should be read as three regimes:

R2 is additionally the period carrying 59 of the corpus's 104 missing hours, and a zero-success day. It is a migration window, not a stable observing condition.

Consequences

(a) "Success" is not a signal in R1. For sixty-one days every login succeeded. Any statement that an address "achieved a 100% success rate" before 2026-05-21 is a statement about the honeypot's configuration, not about the address. This series had provisionally used near-100% success as a defining trait of one behavioural class; that trait is evidentially void for all R1 observations and must be re-established from R2/R3 data alone. Zero-command behaviour, by contrast, remains meaningful throughout — the sensor never suppressed command capture.

(b) Cross-regime ratio comparison is invalid. The 2026-03-29 event (R1), 2026-06-22 (R2) and 2026-07-29 (R3) were measured by three different instruments. Ranking them on one scale is a category error.

(c) The largest event's ratio is overstated. The 2026-06-22T19:00 burst sits at the edge of R2's collection failure:

The centred rolling median for the burst hour draws on the degraded window, giving a local baseline of 4 and a ratio of 382×. Against June's healthy observed rate of 14.6/h the same 1,528 connections give 122×.

[DOCUMENTED] The corrected figure is 122×, not 382×. The event remains extraordinary; the number published for it changes.

Rule R10. Every burst is scored within its regime, against a baseline computed from hours at ≥95% coverage. Cross-regime comparisons are made on absolute connection counts or not at all. Letter A publishes regime boundaries alongside every ratio, and re-scores all 26 events accordingly.

What D8 does not establish

What changed on 2026-05-21 and 2026-06-29 — a deliberate configuration change, a version migration, a credential-policy change, or a fault — is not established here. The coincidence of the auth change with the registry backfill on the same date and within the same minutes is strong [INFERRED — confidence MEDIUM-HIGH] evidence of a planned migration rather than a fault, but the operator's own change record, not this corpus, is the authority. Letter A states the regimes as observed and does not speculate on cause.

10. Retraction — the capability collapse

A finding reached earlier in this investigation is withdrawn.

The claim was that command density fell as volume rose — from 0.319 commands per connection in April to 0.081 in July, against a ~30× volume increase — and that the sensor was therefore "touched far more and worked proportionally less."

The arithmetic was right. The denominator was wrong.

A command can only be issued in a session that authenticated. Dividing commands by all connections across a window in which the authentication rate fell from 100% to 7.2% measures the auth policy, not the attackers. Normalised against successes — the population that can exhibit the behaviour — the trend reverses:

By regime: R1 0.258 → R3 1.139, a 4.4× increase.

[DOCUMENTED] There is no capability collapse. There is a capability concentration. Far fewer sessions get in; those that do work several times harder than anything in the accept-all era. The corrected statement is the more interesting one, and it is nearly the opposite of what was originally written.

Rule R11. Any rate is normalised against the population that can exhibit the behaviour, not against total traffic. Where a denominator changes across the window, the rate is reported per regime.

This retraction is why §9 is in this letter and why this letter is published first. The error survived an initial pass because 0.081 looked stable across May, June and July and therefore looked like a real plateau. It was a plateau in a ratio whose denominator was moving underneath it.

11. Rules of evidence for The Loud Hour

Updated 2026-07-30 — this section is the series' canonical rule list. Every letter states that it "operates under the rules of evidence in Letter O", so a reader who arrives here must find the current set, not the set as it stood when this letter was written. **Eleven rules were issued here. Nine more were forced by later letters, the last of them after the series closed.** The originals are unaltered; the additions are marked with the letter that produced them.

The eleven issued in this letter

R7 and R8 are inherited from prior work in this corpus; they bind this series equally.

The nine added after this letter was published

What the twenty have in common

[INFERRED — confidence HIGH] They cluster into three families, and the clustering is the lesson. Six concern field semantics (R1, R2, R12, R13, R18, and half of R6) — fields that do not mean what their names suggest. Seven concern absence (R3, R8, R15, R16, R17, R19, R20) — every one written because a well-formed empty answer was mistaken for a finding. Seven concern normalisation (R5, R6, R7, R9, R10, R11, R14) — denominators, units and baselines.

Not one concerns the adversary. Every rule in this series exists because of the instrument, the index, or the analyst reading them. That was the argument for putting a provenance letter first, and twenty rules later it is the finding this letter is most confident of.

[DOCUMENTED] R20 is the only rule issued after the series closed, and it is the one that matters most for how the others are read: R16 already covered it. Run a saturation control before reporting an absence — Letter G searched the public literature for a maintainer handle, found nothing, and reported the nothing, without running the registry query that would have answered it. A rule written for enrichment linkages applied to a literature search and was not applied. Rules are not self-executing, and this list is not a substitute for asking what would have to be true.

12. What this letter could not establish

Stated plainly, because a provenance letter that ends in reassurance has failed.

1. The definition of honeypot_hits (D2). Unresolved; R2 routes around it.
2. What changed on 2026-05-21 and 2026-06-29 (D8). The regimes are dated and characterised; their cause is not established from this corpus.
3. Whether pre-2026-05-21 session data was imported from an earlier system, and whether completely. If partial, per-address totals before that date are floors, not counts. Nothing here depends on a pre-May total being exact, but the caveat is live and repeated at each point of use in Letter A.
4. Whether other endpoints clamp silently (D4). One instance found by accident; the class is not enumerated.
5. Whether the 104 missing buckets represent silence or non-recording. §9's coverage table shows the June cluster coincides with degraded recording. April's 34 are uninvestigated.
6. What caused the July volume step. Datable to 2026-07-13/15, involving both volume and distinct-source growth, and distinct from the R2→R3 regime boundary of 2026-06-29. Whether it reflects a change in the internet, in the sensor's exposure, or in the collection path is not established.

### ✅ ITEM 6 CLOSED — settled in Letter H, The Ledger. [DOCUMENTED] **None of the three candidates this letter offered is the answer. The step is a single autonomous system arriving. AS197170 accounts for 130,565 attempts against an R3 total of 136,706 connections** — of the same order as the entire regime. Because a fleet job generates approximately one credential attempt per connection (Letter D), attempts and connections are near-equivalent for this population, so **AS197170 alone is sufficient to account for the step.** The R6 unit caveat is stated rather than buried: total_attempts from the ASN record and connections from the hourly timeline are different counters, and part of the fleet's traffic falls in R2. Measured against R2+R3 combined (158,185 connections) the fleet is ~83%. Either framing gives the same answer. [DOCUMENTED] The mechanism is visible in the fleet's own growth curve — concurrent active addresses per day: 1 on 06-30, 4 by 07-03, 9 on 07-14, 14 on 07-15, 19 on 07-18, 33 on 07-21, 30 on 07-23, then contracting to 3 by 07-30. **The scale-up coincides precisely with the 2026-07-13/15 inflection this letter dated**, and the contraction is visible in the corpus tail. The change was in the internet, not in the sensor or the collection path — the third and second candidates above are excluded, and the first is now specific: one fleet, not a diffuse shift.

Point 6 deserves emphasis. A 25-fold baseline shift and a set of 26 discrete excursions are, on present evidence, two separate phenomena sharing a corpus. Any letter that merges them is writing fiction with real numbers. The temptation is considerable precisely because they are adjacent in time — and §9 has just demonstrated what happens when a moving denominator is mistaken for a finding.

⚠ CONFIRMED 2026-07-30 — the caution turned out to be a finding. This paragraph was written as method, on the reasoning that adjacency in time is not shared causation. It survived the series as fact: the step change belongs to AS197170, the fleet, arriving from 06-30 and scaling to 33 concurrent addresses by 07-21; the largest excursion belongs to 94.154.35.215, AS202412 — a beacon that had run at roughly two connections an hour for four months and produced 202 in one hour on 2026-07-29T23:00. **Different autonomous systems, different populations, different behavioural class** (Letter A's three-species taxonomy), and Letter M's Test 1 shows a sibling beacon flat at 2/hour straight through the 348× hour. Two phenomena sharing a corpus, as stated — now [DOCUMENTED] rather than [INFERRED]. A letter that had merged them would have attributed the fleet's arithmetic to a beacon's burst and answered the series' opening question wrongly.

13. Standing

[DOCUMENTED] The session store is intact across the full window. Both censuses are reproducible from primary data under R5 and R10. The principal actor attributions rest on enrichment whose provenance and as_of timestamps are individually recorded and whose internal disagreements are reported under R7.

Four defects would each have produced a published falsehood: D1 deleting the earliest burst from the record; D5 inverting the ranking of the largest; D8 permitting three incompatible instruments to be compared on one scale; and the §10 error, which did produce one, stated here rather than corrected in silence.

Every one was found by cross-checking one instrument against another rather than by trusting either. That is the only method this series claims — and D3, where the instrument was vindicated and the analyst was wrong, is the reason the method has to run in both directions.

⚠ ADDED 2026-07-30. A fifth defect belongs on that list, and it is not an instrument's. **The maintainer object ru-avm-1-mnt, read across Letters C, E and G as an operator link, is the object of a sponsoring Local Internet Registry** — the series' tenth correction, and its only one issued after publication. It was not found by cross-checking instruments, because both instruments were right: the registry said what it said, and the behavioural signals said what they said. It was found by asking what the registry object was for, which no amount of cross-checking substitutes for. R20 exists because of it. See TI-2026-103P — The Sponsor.

Next: Letter A — The Census. Twenty-six events, three regimes, two detectors, one table.