On July 31, a strange route moved to the top of New Runtime’s machine traffic table.
/machine-consumption.json received 125 machine requests in the preceding 24-hour production snapshot. Of those, 121 were classified as search and four as AI. A crawler claiming to be Applebot made 274 requests across the site during the same window.
That was interesting. It was not yet evidence that Applebot discovered the manifest, understood it, and followed its links.
The useful response was not to celebrate a high counter. It was to turn the counter into an experiment.
The observation
machine-consumption.json started as a privacy-safe report about how automated clients read New Runtime. It was a custom route, not an industry standard and not a documented Apple discovery mechanism.
A crawler could have learned the URL through an HTML link, a sitemap, a previously known route, an external reference, or a private scheduling heuristic. A bot could also fetch it repeatedly because the response appeared to change often. Raw access logs cannot reveal the crawler’s internal decision.
The original snapshot also contained an important quality warning. Its all-time route ranking accounted for 14,684 of 17,447 external machine requests. A ranking with a truncated denominator is not a trustworthy basis for a product claim.
So the first intervention was measurement hygiene:
- preserve the original window and release evidence;
- raise the route-report capacity until the 24-hour denominator reconciles completely;
- classify the manifest as a discovery route instead of an anonymous public path;
- exclude WordPress probes, credential scans, utility clients, internal monitoring, and marked synthetic checks from the audience.
A crawler name is not an identity
Any client can send Applebot in its User-Agent. New Runtime now treats that string as a claim.
Where a provider publishes a verifier, the private reporting job checks the source address against the provider’s official CIDR data or performs forward-confirmed reverse DNS. Apple, Google, OpenAI, and Perplexity publish machine-readable address ranges for relevant crawler families. Bing and Yandex support DNS-based verification.
The public report exposes only three states:
verified— the request matched a supported provider verifier;claimed_unverified— the client claimed a family but did not pass the available check;not_verifiable— no supported public method was available.
Source addresses are used ephemerally for verification and short-window sessionization. IPs, hostnames, raw User-Agents, raw log lines, and session identifiers are never published.
That wording matters. Until verification succeeds, the correct claim is “a client claiming to be Applebot,” not “Applebot proved it read the manifest.”
From counter to gateway
The route still exposes schema_version: 1, so existing consumers do not break. Its optional v1.1 fields turn the response into a compact map:
- a human methodology page;
- a published JSON Schema;
- a sharded discovery graph;
- a pre-registered experiment registry;
- typed next reads for changes, topics, patterns, OpenAPI, read-only MCP, and feeds;
- explicit window, route-coverage, privacy, and interpretation limits.
The bootstrap response has a 48 KiB budget. It is not intended to contain the entire site. It tells a client where to read next.
The standard discovery layer remains more important than the custom manifest. New Runtime also publishes XML sitemaps, RSS, Atom, JSON Feed 1.1, HTML feed autodiscovery, an OpenAPI contract, a read-only MCP catalog, and an RFC 9727 API Catalog. The custom route connects those surfaces; it does not replace them.
The graph gives coverage a denominator
A claim such as “the bot read 31 pages” is meaningless without knowing how many pages were available and how they were connected.
DiscoveryGraph v1 is generated from the built public site. It separates two kinds of edges:
- physical edges such as HTML links, canonical relationships, alternate representations, sitemap membership, and feed membership;
- knowledge edges such as topic membership, pattern evidence, and public source evidence.
The index stays small and points to deterministic bounded shards. A build validator checks node and edge references, size limits, orphan canonical records, sitemap and feed consistency, canonical conflicts, broken internal routes, and accidental private-route leakage.
This graph is not an attempt to tell a crawler how it must think. It is an inspectable expectation against which observed coverage can be compared.
What the overlay measures
Verified requests are aggregated into 24-hour, 7-day, and 30-day windows.
The public Lab reports:
- unique canonical nodes fetched;
- coverage relative to the graph that existed in the observation window;
- HTML, Markdown, JSON, and feed representations used;
- time from publication to first verified fetch;
- the share of bounded sessions in which a content read followed a manifest read within 30 minutes;
- observed route span and distance from the documented entrypoint.
The manifest-to-content number is deliberately called follow-through, not a causal path. Without a reliable referrer or the crawler’s queue state, temporal order is correlation.
If the manifest is repeatedly fetched and no downstream content appears, the result is polling. That is a valid negative result and a reason to simplify the surface.
Three pre-registered experiments
The public registry contains three experiments.
manifest-gateway asks whether typed links are followed by downstream content reads. graph-discovery asks whether verified coverage increases or median discovery latency falls. authority-distribution asks whether this methods note produces attributable referrals, canonical citations, or repeat verified fetches.
The primary result window is seven days. A 30-day window continues automatically. A promising seven-day result means at least two verified bot families read the new graph or manifest and then requested linked content, or median discovery latency improves by at least 25% from baseline.
Traffic growth is not a release criterion. The engineering outcome is a system that can tell the difference between discovery, polling, spoofed identity, shallow crawl, citation, and attributable return.
Recall and TTFU proxy
Fetch is not the final outcome. A small versioned probe set asks external systems about New Runtime, its latest Field Notes, its MCP surface, and selected topics.
A recall pass requires an exact canonical newruntime.com citation and agreement with a published fact contract. The elapsed time to the first correct cited answer is reported as a TTFU proxy.
It is only a proxy. It does not prove that the site entered model training data or internal model memory. If an official search or web-enabled model provider is not configured, the run is recorded as not_run; the production site does not fabricate an answer.
What comes next
The immediate question is now precise:
Does the route that machines already read lead verified crawlers deeper into New Runtime, or is it only a frequently polled JSON file?
The first post-release snapshot will establish the intervention receipt. The 24-hour, 7-day, and 30-day windows will then accumulate without changing meaningful page lastmod values on every telemetry refresh.
The live result belongs in the Machine Discovery Lab. If the experiment works, New Runtime gains a measurable discovery path. If it fails, it gains a documented negative result instead of a flattering but empty traffic counter.