Summary

  • RIPE Atlas raw results already expose measurement windows, probes and version fields, but those durable identifiers do not say how long Khipu's historical enrichment remains locally available.
  • The January 2026 update made four lookup families conditional on availability and made the number of retained local archives a preference, creating a separate evidence-expiry clock.
  • Keep retention local, but publish its boundary: an evidence export should record the archive horizon, fallback outcome, four snapshot identities and a supersession path before the shelf rolls over.

A historical view can outlive its evidence shelf

Imagine an operator opening a six-month-old measurement while a generous local archive shelf is still warm. The historical ASN, IXP and country labels load as expected. Weeks later, a reviewer opens the same measurement and the same saved view on a client configured to keep fewer snapshots. The question is no longer merely whether the filters match. It is whether the enrichment evidence still exists locally, or whether an unavailable archive triggered another path.

No observed divergence is claimed here. The point is contractual: a dated measurement can remain durable while the lookup material used to interpret it is governed by a separate, locally chosen retention horizon. A link cannot disclose an expiry boundary that its published state model does not carry.

The distinction is visible in the current Khipu documentation. Khipu turns traceroute, DNS and ping data into IP, ASN and country views. It can show RTT, IXP membership and anycast labels, filter by path and geography, and export filtered or full JSON or CSV. It caches ASN lookups and country mappings from RIPE NCC RIS, IXP information from PeeringDB, IP location information from IPLocate and processed measurement data. The same page warns that location systems can be wrong, particularly for CDNs and similar addresses.

That is not a defect confession. It is an honest description of an interpretive system. A probe observes packets and times. Khipu adds names and groupings from other records. The richer view is more useful precisely because it contains facts that did not arrive in the raw traceroute.

The raw result already carries version boundaries

RIPE Atlas does not treat every measurement result as an unversioned blob. Its measurement-result format says each result contains fw, identifying the probe firmware associated with its structure. Since result version 5000, mver separately identifies the measurement-code version as x.y.z: major for incompatible output, minor for added fields that remain parseable, and patch for code changes that leave the format intact.

The same specification distinguishes src, supplied by the probe, from from, added by the backend and used for ASN lookup and geolocation. Those values can diverge. In one delayed-delivery IPv4 case, the backend can populate from with the address known at reconnection. The documentation therefore does something important before analysis begins: it identifies both a field boundary and a production boundary.

Retrieval has boundaries too. The Results and Latest API manual lets an analyst request full history with a measurement ID, start, stop and probe_ids. The Latest endpoint can return up to ten previous results per probe, in reverse chronological order, and its response is cached for five minutes. Here versions means prior measurement results. It does not mean lookup-table versions.

Probe context has its own clock. The probe archive endpoint exposes dated historical snapshots of probe status and accepts date, probe, status and selected-field filters. A careful analyst can therefore name the raw result window and a probe snapshot without pretending either one identifies the later ASN, IXP or country enrichment.

This is the useful asymmetry. The packet side already teaches users to retain identifiers, times and versions. The visual side needs the same discipline for the records it adds.

Four archives entered the historical view

On 5 January 2026, a RIPE Atlas UI/API release added a consequential sentence: Khipu would pull archived cache information, if available, for ip2asn, ixp, ip2country and asn2country. The number of local archives would be set in preferences.

Every word matters.

“Archived” means the interpretive input has time. “If available” means historical selection has a failure or fallback boundary. Four names mean there is not one universal enrichment clock. “Set in preferences” means local state affects how much history is available to the user or client. The release note does not say how long archives persist, how they are named, whether the four share a timestamp, how fallback is ordered or which digest identifies a snapshot. Those remain unknown from the cited public material.

Nor should the four sources be collapsed into one truth service. IP-to-AS attribution follows routing evidence and its observation time. IXP identification follows an interconnection directory and matching rules. IP-to-country and ASN-to-country are different claims; neither automatically proves a router's physical position, a company's jurisdiction or the place where packets crossed a fabric.

Khipu's usefulness comes from putting those distinct clues into one legible path. Auditability requires keeping their identities distinct after they have been combined.

The retention boundary lives outside the shared view

The documentation's “What Gets Shared” list is concrete. It says a Khipu URL preserves six groups:

  • the selected measurement ID and type;
  • the current IP, ASN or country view;
  • active RTT, path and country filters;
  • display choices such as success state, labels and distance mode;
  • whether the country filter is open or closed;
  • fullscreen state.

This is a good configuration receipt. It answers, “What did the analyst choose to look at?” It does not answer the new commissioning question: how far back could this client reproduce enriched history before its locally retained shelf ended? The published list does not name the archive-count preference, the oldest available snapshot, an eviction rule, a fallback marker, an ip2asn, ixp, ip2country or asn2country archive identity, Khipu's build or an output hash.

The wording must stay bounded. An omission from public documentation is not proof that RIPE NCC keeps no internal provenance. It is not proof that the URL contains no undocumented selector. It is not proof that JSON or CSV exports lack hidden provenance. It means only that a recipient relying on the published sharing contract has not been promised those identities.

That boundary matters more as a tool matures. The 2 September 2025 release introduced Khipu in beta. On 26 September, the team added country-view lookup and scoring alongside a country filter and other improvements. The earlier prototype account had described a tool under heavy development, designed to make large traceroute collections comprehensible, with URL parameters for sharing filters and views.

That history shows a visual interface acquiring analytical meaning. It does not justify calling current Khipu beta, and it does not prove any output changed incorrectly. It explains why a sharing contract written for view state now sits beside a locally bounded historical shelf whose expiry needs to be declared before evidence is cited.

Availability belongs inside the reproducibility equation

Let R be the selected raw results. Let V be the view configuration carried by the URL. Let E_t be the four enrichment snapshots and fallback choices selected for historical instant t. Let A_l(t) say whether client l still retains those inputs. Let K identify the Khipu implementation. Then describe the derived output as:

O_l = F(R, V, E_t, A_l(t), K).

This is an audit model, not RIPE NCC's schema. It makes a limited point. The API and raw results can identify much of R. The shared URL identifies much of V. The January release makes historically selected E_t conditional and places archive quantity in local preferences. The published state does not name A_l(t), E_t or K.

If two replays use identical R and V but different E_t, a derived label can in principle change. That is an inference from the architecture described in the documentation, not a report that two users have observed divergence. If a future public export already embeds every material identity, it would falsify the practical critique.

Capture the retention manifest before the shelf rolls over

The solution does not require centrally mandated retention or a longer URL for every casual visitor. Keep the current link and let each operator choose storage depth. Before a result becomes evidence, however, export this compact retention manifest while the relevant snapshots are still available:

  1. Receipt identity. Stable receipt ID and receipt-schema version.
  2. Measurement identity. Measurement ID, type and public/private visibility boundary.
  3. Result window. Exact start, stop and timezone.
  4. Probe set. Ordered probe IDs and the applicable probe-snapshot identity.
  5. Raw retrieval. Result endpoint and retrieval time.
  6. Raw integrity. Content hash and the observed fw and mver value sets.
  7. Renderer identity. Khipu build or release.
  8. Archive selection. Historical instant, selection policy, local archive-count preference and fallback status.
  9. ip2asn. Source, archive identity, retrieval time and digest.
  10. ixp. Source, archive identity, retrieval time and digest.
  11. ip2country. Source, archive identity, retrieval time, digest and confidence or unknown state.
  12. asn2country. Source, archive identity, retrieval time, digest and confidence or unknown state.
  13. View configuration. Canonical view, filters, display choices and shared URL.
  14. Export scope. Full or filtered, visible path or result count and deterministic ordering rule.
  15. Output identity. Generation time, output digest and any correction or supersession link.

The receipt must not carry API keys, private measurement content into a public record, personal identity, browser history or local filesystem paths. A private measurement can retain the same schema inside its authorization boundary. Auditability is not a license to widen access.

Retention stays local; expiry becomes portable

The design follows HENG.LU Note 64: specify strictly only what has to travel, and leave future choices with the participants running the system. Archive depth, storage budget and eviction policy may remain local. For an evidence-grade result, the chosen horizon, observed availability or fallback, four snapshot identities, renderer and output digest must travel before that local shelf expires.

This does not create one official geography. A recipient may prefer another geolocation model, another IXP test or another IP-to-AS dataset. The receipt makes that fork intelligible: it tells the recipient which model produced the cited result and permits a different one to be run openly.

Portability is the institutional limit. The analysis should survive the browser session without requiring RIPE NCC to approve the conclusion. A derivation receipt records how the labels were made. It does not turn those labels into sovereign facts about ownership, jurisdiction or the path a packet physically took.

Sources

Evidence limits

Verified: raw results expose fw and, from result version 5000, mver; Khipu documents RIS, PeeringDB and IPLocate-backed caches; four archived lookup families were added conditionally; and the sharing page lists visual state without naming lookup archive identities.

Inference: changing an enrichment snapshot or fallback choice can change a derived label while raw results and visual choices remain fixed.

Recommendation: add an optional portable receipt binding raw data, enrichment, renderer and output.

Unknown: the internal cache schema and retention, undocumented URL or export fields, fallback precedence, the exact archive chosen in any past view, and whether any same-link divergence has occurred.