TI-2026-100J — The Quiet Transit, Part J: The Phantom Finding

Classification: TLP:WHITE · Confidence: HIGH · Series: The Quiet Transit, Part J Subject: a published finding that was never true

1. The claim

Part H, section 9:

"And one previously documented handle has gone quiet. lir-bg-telco-1-MNT — recorded in this corpus as part of the same substrate, identified via a shared telephone number to Telco power Ltd of Sofia — now returns zero objects, while four sibling handles returned between 187 and 3,445 in the same batch. Renamed, deleted, or migrated. Unexplained, and asserted as nothing."

It was published with a scale-table row reading 0 | 0 | 0, and logged to the operations roadmap as an open discrepancy worth re-checking.

It was never true. There was no zero. There was no measurement at all.

2. The controlled experiment

VIA-REGISTRY-MNT was measured at 514 objects earlier the same day. That measurement underpins the whole of Part H — 46 autonomous systems, 60 organisations, the entire brokerage argument.

Re-queried later, through the identical code path:

$ curl .../search.json?query-string=VIA-REGISTRY-MNT&inverse-attribute=mnt-by
HTTP 429

Zero objects. The same value Part H recorded for lir-bg-telco-1-MNT.

The handle did not change. The response did.

3. What the response actually contained

{
  "link": { ... },
  "errormessages": {
    "errormessage": [{
      "severity": "Error",
      "text": "ERROR:201: access denied\n\nQueries from your IP address have passed
               the daily limit of controlled objects.\nAccess from your host has
               been temporarily denied.",
      "args": [{ "value": "<querying IP>" }]
    }]
  },
  "terms-and-conditions": { ... }
}

There is no objects key.

And the parsing expression used in every RIPE query across this series:

json.load(...).get('objects', {}).get('object', [])

Against that body it evaluates to []. Silently. Without raising.

An error was consumed as data, and an empty list was published as a measurement.

4. Why that handle, specifically

The Part H batch ran four handles in order:

That 3,445-object response is the largest single result taken anywhere in this series, and it contained 1,183 role objects — precisely the controlled object class the daily limit governs.

The handle that "vanished" was simply the next one in the loop.

A different loop order would have produced a different phantom. The finding was an artefact of execution, not of the registry.

5. And a second, independent error

Even with no rate limit, the query was wrong for that handle.

This corpus documents lir-bg-telco-1-MNT as one of four handles forming an identical mnt-ref cluster on ORG-TI147-RIPE (TechTies) and ORG-DSL56-RIPE (DEDIK).

The Part H query used inverse-attribute=mnt-by.

Different relationships, different semantics. A handle whose documented role is mnt-ref would legitimately return few or no results under an inverse mnt-by search with no rate limiting whatsoever.

So the six-handle comparison in Part H §6 was never valid for that member — and the word mnt-ref appears explicitly in the source note this series was working from.

6. Why this one got through

The other defects this series documented produced wrong numbers from real data:

• Part B — a score without its denominator
• Part E — a record without its provenance
• Part I — a population defined by the filter meant to assess it

This one is categorically different. It converts a failure into a measurement.

When the query does not run, the code does not report an error, a gap, or a null. It reports zero — a legitimate value in the same domain as every real answer. A reader cannot distinguish "the registry holds nothing" from "the request was refused."

Neither could the author. That is why it reached publication when the others were caught first.

Every signal was there

HTTP status 429. An errormessages array. A severity field reading Error. A human-readable ERROR:201 text naming the daily limit. The querying IP. A documentation link.

Nothing ambiguous. Nothing hidden. The consuming code read one nested key and moved on.

The rate limit itself exists to protect personal data in person and role objects from bulk harvesting, and it functioned exactly as designed. The failure was entirely on this side of the connection.

7. Who it touched

lir-bg-telco-1-MNT resolves, in prior corpus work, to Telco power Ltd of Sofia, Bulgaria via a shared telephone number.

Part H implied that one of that company's registry handles had been removed or migrated — a statement carrying obvious adverse connotation for a hosting business — on the basis of an unread error message.

That implication is withdrawn.

After correction, nothing is established here about the handle's current status. Not renamed. Not deleted. Not migrated. Not intact. The mntner object could not be fetched at the time of writing because the same limit applies to it. The prior characterisation — a member of a four-handle mnt-ref cluster resolving to Telco power Ltd — stands on its own original evidence and is untouched by this dossier.

Resolving the handle's present state requires an inverse mnt-ref query from an unthrottled source on a later day.

8. The same failure, four times

Four different data sources. Four different layers. One failure:

A value was used without checking what it meant.

Part B scored a consumer ISP as a bulletproof host on three infected customer routers. Part E could not tell a third party's assertion from a first-party observation. Part I hid seven Spamhaus-listed networks behind four characters of SQL. Part J turned a refusal into an absence, and an absence into a finding.

9. The objection

Four of ten dossiers in this series correct the series. That could be read as a corpus more interested in its own process than in threats — or as manufacturing content out of routine engineering mistakes.

Two answers.

First, this error was not internal. It produced a published statement that a named Bulgarian company's registry handle had been removed, on the basis of an unread error message. A wrong public claim about a real company is corrected in public, or it is not corrected at all.

Second, the failure mode generalises. Any tool consuming a paginated or rate-limited API with a permissive parser can silently convert refusal into absence — and in threat intelligence, absence is frequently the finding. "The infrastructure is gone." "The operator has no other assets." "Nothing was found." Every one of those sentences can be manufactured by an unchecked status code.

That is worth one page.

What would not be worth publishing is a further dossier in this series with no subject. This is the last one.

10. The fixes, in order of value

1. Check the status code. Treat any non-2xx as an exception, never as data. This alone would have prevented the finding.
2. Assert the shape. Require the expected key to be present rather than defaulting it — a missing objects key should raise, not yield [].
3. Distinguish zero from unknown. A measurement that could not be taken is null or not measured — never 0 — in both data and prose. Part H's corrected table now reads not measured for exactly this reason.
4. Match the relationship to the entity. Before comparing handles across an inverse attribute, confirm each one actually uses that attribute. mnt-by and mnt-ref are not interchangeable.
5. Re-run any batch whose members disagree wildly. A set returning 3,445, 389, 187 and 0 should have prompted a re-query of the outlier before publication.

[INFERRED — proposals, not implemented.]

11. Metadata

Sources

• RIPE NCC REST DB — reproduced 429 response, 2026-07-26
• RIPE ERROR:201 documentation
• LSN dossier_intel + operations roadmap — the original mnt-ref characterisation
• Part B · Part E · Part H · Part I

This dossier withdraws a claim previously published by this corpus about lir-bg-telco-1-MNT and, by extension, about Telco power Ltd. No adverse finding against that handle or that company is made or maintained here. RIPE NCC is named for accuracy: its API signalled the error condition correctly and completely, and the failure was entirely on the consuming side.