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

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.
Bars show accepted observations. The green line shows accepted observations per 1,000 processed frames, which makes days with different collection volume comparable.
Trailing 24 hours
Trailing 24 hours
Trailing 24 hours
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.
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.
Trailing 24 hours
Privacy-safe signatures
Trailing 24 hours
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
™