Method
Where each channel’s numbers come from, how a window is aggregated, what is excluded, what is never published, and how to verify an edition against the published key.
In one paragraph
Each channel’s instrument writes the same label at contact time. For a fixed window the records are aggregated per channel and per layer, the publisher’s own test traffic is removed, tenant identity is dropped, and the totals are published as a numbered edition signed with an Ed25519 key whose public half is at /.well-known/aethelforge/keys.
Sources
Nothing in the Index is sampled or estimated. Every number is a count of records an instrument wrote at contact time.
The bot record the fleet middleware writes for every non-human request on each monitored site, one record per site per day.
Declared user agent and its category; the Web Bot Auth Signature-Agent header; the fetcher patterns assistants publish for on-demand page reads.
Bot hits, by category and by kind: crawler, agent fetch, declared agent, unknown bot. People are not counted on the web channel.
The receptionist’s call log for a live business line: attestation, whether anyone spoke, the transcript and the post-call analysis.
Caller kind and its companions — declared, on behalf of, vendor, evidence — from an analysis run after every call with speech.
Calls, by caller kind. Legacy calls analysed before the label existed are counted as unknown or recording, never as human.
The concierge’s archived sessions and its weekly analysis across every tenant that runs the widget.
Request-time signals stamped on the session and the conversation’s own self-declarations; the weekly analysis returns counts per kind.
Sessions per week, by kind. Evidence lines are capped and scrubbed of personal detail before they leave the analysis.
The lead store: every submission from the fleet’s contact, quote and intake forms.
Submission text, the user agent behind it, a forwarded signature when the site passes one, and the receptionist’s verdict for phone-originated leads.
Leads, by kind, with the spam flag and referrer recorded at submission kept as separate columns.
Windows and aggregation
An edition names its window in full days, inclusive, in UTC. For each channel the records inside the window are grouped by layer and summed. Nothing is smoothed and nothing is backfilled; a record that arrives late belongs to the edition whose window it falls in, and if that edition is already published it appears as a note in the next one.
Edition 001 covers 31 days. Later editions will run on shorter windows as the instruments accumulate history, and each one states its own.
Test traffic the publisher generates to verify an instrument is removed before aggregation, and every exclusion is written into the edition’s notes.
What is never published
Signing and verification
Every edition is served as JSON with an Ed25519 signature over its canonical bytes. The key set is public and includes past keys, so an edition signed under a rotated key still verifies.
curl -s https://aethelforge.ai/api/index/latest \ | jq 'del(.signature)' -c # canonical message curl -s https://aethelforge.ai/.well-known/aethelforge/keysThe latest edition as signed JSON
FAQ
A live counter cannot be cited. A fixed window can be checked, compared with the next one, and signed so that nobody — including the publisher — can quietly change it later. Editions are the unit of trust; the live telemetry lives on the status page.
The publisher’s own test traffic, probes used to verify the instruments, and any record that predates the label on that channel and cannot be re-analysed. Exclusions are stated in the edition’s notes.
Tenant names, phone numbers, transcripts, message text, IP addresses and anything that identifies a person or a client business. The Index reports counts and shares. The per-site detail belongs to each client and stays with them.
Only by publishing a new edition that says what changed and why. The original stays online with its original signature. That is the point of signing them.