StreetProof™

Report

12,093 Requests, 6,066 Data Retrievals. Here’s What They Mean.

Evidence-firstPrivacy-scrubbedMachine-readable

A corrected StreetProof field report separating header checks from data retrievals during an anonymous index sweep.

Generated StreetProof data-report graphic with glass-wave charts for machine data retrievals and physical-index output.

Report summary

During the 24 hours ending at 8:00 a.m. MDT on September 23, 2026, StreetProof recorded 12,093 successful machine request events. Of those, 6,027 were HTTP HEAD checks that returned headers but no data body. The corrected Machine Pulse total is 6,066 data retrievals. In the same window, the physical index accepted 573 observations covering 504 entities in 56 cities, at 1.78 indexed observations per 1,000 processed frames. The systems were active at the same time; this report does not claim that one caused the other.

The anomaly

The number that needed an explanation

The StreetProof homepage originally showed 12,093 successful machine retrievals in a trailing 24-hour window. A September 24 audit found that the counter included 6,027 HTTP HEAD checks paired with later GET requests. HEAD returns response headers, not the requested data body, so those checks should not have been called retrievals.

The corrected retrieval total is 6,066. A successful retrieval now means a qualifying external operation that returns public StreetProof data. A crawler family still counts only traffic that matched an active, known crawler signature. A client can read thousands of records without identifying itself as Google, Claude, Meta, or any other recognized family.

Of the 6,066 data retrievals, 6,056 were classified as unattributed automation. Nine were attributed REST/API traffic and one was an MCP tool call. No retrieval in the trailing window matched a known crawler signature.

The raw request event count was real. The first retrieval label was wrong. This correction keeps both numbers and states what each one measures.

High request volume tells us the index was read. It does not tell us who valued it, why they read it, or what they did next.

The measurement

Two systems, one clock

StreetProof has a supply side and a demand side. The supply side turns eligible physical-world inputs into accepted observations. The demand side records privacy-safe machine retrievals of the resulting public data.

For index production, the useful rate is accepted observations per 1,000 processed frames. Raw frame volume mostly describes workload. It does not describe public value. In this window, StreetProof accepted 573 observations from 504 entities across 56 cities, producing 1.78 accepted observations per 1,000 frames.

The immediately preceding 24-hour window produced 556 accepted observations at 1.75 per 1,000 frames. Accepted output rose 3.1% and the normalized rate rose 1.4%. Operationally, that is flat—not a breakthrough and not a collapse.

Across the seven completed UTC days shown below, StreetProof accepted 3,025 observations at a weighted 1.47 per 1,000 frames. The daily rate moved between 1.07 and 2.02. That range is the honest baseline for this early period.

Physical index productionAccepted output stayed steady while daily efficiency moved

Bars show accepted observations. The green line shows accepted observations per 1,000 processed frames, which makes days with different collection volume comparable.

Accepted output stayed steady while daily efficiency movedBars show accepted observations. The green line shows accepted observations per 1,000 processed frames, which makes days with different collection volume comparable. Seven completed UTC days plus September 23 through 14:00 UTC. The partial day is marked with an asterisk. Raw frame totals are intentionally not published.00.01750.63501.15251.77002.2Sep 16Sep 18Sep 20Sep 22Sep 23*
Accepted observationsIndexed per 1,000 frames
573accepted observations

Trailing 24 hours

1.78indexed per 1,000 frames

Trailing 24 hours

504entities indexed

Trailing 24 hours

56cities with output

Trailing 24 hours

Seven completed UTC days plus September 23 through 14:00 UTC. The partial day is marked with an asterisk. Raw frame totals are intentionally not published.

Sep 16: Accepted observations 205, Indexed per 1,000 frames 1.864.

Sep 17: Accepted observations 542, Indexed per 1,000 frames 2.016.

Sep 18: Accepted observations 549, Indexed per 1,000 frames 1.481.

Sep 19: Accepted observations 429, Indexed per 1,000 frames 1.07.

Sep 20: Accepted observations 483, Indexed per 1,000 frames 1.179.

Sep 21: Accepted observations 258, Indexed per 1,000 frames 1.82.

Sep 22: Accepted observations 559, Indexed per 1,000 frames 1.594.

Sep 23 partial period: Accepted observations 312, Indexed per 1,000 frames 1.884.

The demand

What the machines requested

The 6,066 retrievals were not spread evenly across the site. Entity records returned data 2,987 times and evidence endpoints returned data 2,919 times. Together, those two route families accounted for 97.4% of successful machine retrievals.

The requests touched 2,977 entity IDs across 135 city slugs. They appeared through 55 privacy-safe client instances. A client instance is an aggregate signature, not a person, company, or guaranteed physical device. Daily one-way hashing and minimized client data prevent permanent visitor tracking.

The eight-day chart shows why one headline number is not a trend. Traffic arrived in bursts. September 17 had one large unattributed wave. September 22 had a larger one. Known crawler and MCP activity followed different patterns.

That shape matters. A smooth climb could suggest broadening demand. Two sharp spikes are more consistent with enumeration: software walking through a large part of the index. Useful? Yes. Proof of adoption? No.

Machine demandRetrievals arrived in bursts, not a smooth climb

Successful external data retrievals are separated into attributed REST/API, unattributed automation, known crawlers, and MCP tools using the same accounting contract as the homepage Machine Pulse.

Retrievals arrived in bursts, not a smooth climbSuccessful external data retrievals are separated into attributed REST/API, unattributed automation, known crawlers, and MCP tools using the same accounting contract as the homepage Machine Pulse. Seven completed UTC days plus September 23 through 14:00 UTC. HTTP HEAD checks, internal traffic, failed requests, rate limits, and Machine Pulse self-reads are excluded.01,5003,0004,5006,000Sep 16Sep 18Sep 20Sep 22Sep 23*
Attributed REST/APIMCP toolsKnown crawlersUnattributed automation
6,066data retrievals

Trailing 24 hours

55client instances

Privacy-safe signatures

135cities requested

Trailing 24 hours

2,977entities requested

Trailing 24 hours

Seven completed UTC days plus September 23 through 14:00 UTC. HTTP HEAD checks, internal traffic, failed requests, rate limits, and Machine Pulse self-reads are excluded.

Sep 16: Attributed REST/API 267, MCP tools 0, Known crawlers 426, Unattributed automation 9.

Sep 17: Attributed REST/API 70, MCP tools 29, Known crawlers 545, Unattributed automation 2865.

Sep 18: Attributed REST/API 62, MCP tools 61, Known crawlers 540, Unattributed automation 26.

Sep 19: Attributed REST/API 68, MCP tools 436, Known crawlers 427, Unattributed automation 35.

Sep 20: Attributed REST/API 617, MCP tools 109, Known crawlers 462, Unattributed automation 23.

Sep 21: Attributed REST/API 7, MCP tools 471, Known crawlers 22, Unattributed automation 13.

Sep 22: Attributed REST/API 17, MCP tools 0, Known crawlers 0, Unattributed automation 5516.

Sep 23 partial period: Attributed REST/API 3, MCP tools 1, Known crawlers 0, Unattributed automation 561.

The attribution

Why “crawler families” was zero

StreetProof does not award a famous name to anonymous traffic. The crawler counter increments only when a retained request matches an active known-crawler signature. No such match occurred during the headline 24-hour window, so zero was the correct reading.

The classifier was not asleep. During the trailing seven days, it recognized 2,248 AI-crawler requests: 1,992 from Claude-SearchBot, 255 from Meta-ExternalAgent, and one from Claude-User. Their latest requests landed on September 21, outside the homepage card's rolling 24-hour window.

StreetProof retains daily aggregates indefinitely and minimized request events for 90 days. It does not store raw IP addresses or complete user-agent strings. That boundary protects visitors, but it also means an unknown client cannot be named or retroactively reclassified after the identifying detail has been discarded.

That trade is deliberate. A measurement product should not become a surveillance product just because attribution would make a better headline.

6,056 unattributed
Automation was detected, but no recognized owner or crawler family could be assigned.
2,248 recognized
Known AI-crawler requests were preserved in the seven-day history, outside the current 24-hour card.
90-day events
Minimized request events support recent analysis without keeping raw IP addresses or full user-agent strings.
Indefinite aggregates
Daily totals preserve long-term trends after minimized request events expire.

The boundary

What this day proves—and what it doesn’t

The defensible conclusion is narrow: StreetProof's public index is machine-readable, and an unidentified automated client or clients retrieved a substantial share of it. The request pattern reached thousands of entities and both record and evidence routes. The system handled the sweep without recorded request failures in the frozen window.

The data does not establish that an AI platform used StreetProof in an answer, that search visibility improved, or that index growth caused the traffic spike. It does not identify the requester. It does not turn 55 aggregate client instances into 55 organizations or people.

The same discipline applies to the production side. A higher frame count is not success. More retained candidates are not success. The public output is accepted observations, and the comparable operating rate is accepted observations per 1,000 frames.

This is why the report presents the two systems beside each other without drawing a causal arrow between them. One measures evidence production. The other measures retrieval demand. Their relationship may become meaningful over time, but one unusual day cannot settle it.

The index was read at scale. That is the finding. Everything beyond it still needs evidence.

What comes next

The next report needs time, not hype

This field report freezes an early signal while the numbers are fresh. It is not the promised 30-day benchmark.

The next report will use the corrected metric contract: accepted observations, entities and cities; indexed output per 1,000 frames; response-bearing data retrievals; machine-client instances; requested entities and cities; known crawler activity; MCP usage; unattributed automation; failures; and telemetry gaps. HTTP HEAD checks remain available for internal request diagnostics but are not retrievals.

Thirty clean days will answer better questions. Is accepted-output efficiency stable? Are retrievals broadening beyond periodic sweeps? Do recognized crawler families return? Does MCP usage deepen? Do the same cities and entities keep getting requested?

If the answer is boring, the report should say so. Proprietary data becomes a moat when people trust the measurement, not when every chart points up and to the right.

Inspect the source

Read the live index for yourself.

The report freezes one aggregate snapshot. The public index remains the source of record for accepted observations and current coverage.

Explore the StreetProof public index