Privacy-Preserving AI Telemetry
SigRank collects token counts only — never prompts, code, or conversation text. Four integer pillars, cryptographically signed, verified server-side.
What leaves your machine
Every submission path sends only four numbers:
- Input tokens — fresh tokens sent to the model.
- Output tokens — tokens generated by the model.
- Cache create tokens — context written to cache.
- Cache read tokens — context reused from cache.
That is the entire payload — no prompts, no code, no file contents, no conversation text. The on-device scanner parses your input locally and sends only the four token counts to the server, which re-parses and re-scores them authoritatively.
The optional sigrank proxy is a local loopback transport path to Anthropic or OpenAI, not a submission path to the SigRank leaderboard. When explicitly enabled, it necessarily receives and forwards provider-bound API keys, prompts, tool calls, and responses in memory. It does not persist that content or send it to the SigRank service; it appends only provider-reported token counts, model/backend metadata, and timestamps to ~/.sigrank-mcp/proxy-sessions.jsonl.
What we collect
SignalAF may receive the following data, collected only as needed to operate the service:
- Submission-window metadata — window type, timestamps, and submission context.
- Four raw token pillars — fresh input, output, cache_read, cache_create counts.
- Session/activity aggregates — per-session, per-platform token totals.
- Device and agent integrity material — public keys, agent identifiers, and verification artifacts.
- Signed snapshot data — ed25519 signatures and source attestations for audit.
- Account-to-operator links — the binding between a claimed operator and an account.
Collection is not permission to repurpose data. New uses require a documented basis, minimization review, and any required renewed consent.
What we derive
The server recomputes all derived metrics from the four raw token pillars — operators cannot submit inflated values directly. Derived data remains conditional on its source window and method:
| Metric | Formula | Meaning |
|---|---|---|
| Yield (Υ) | cache_read × output / input² | Token-cascade efficiency |
| SNR | output / (input + output) | Output share of the direct exchange |
| Leverage | cache_read / input | Cache reuse relative to fresh input |
| Velocity | output / input | Output tokens per fresh input token |
| 10xDEV | log₁₀(cache_read / input) | Log-scale Leverage |
The service also derives ranks, percentiles, verification tiers, integrity reasons, and field aggregates from these metrics.
What we never collect
The SigRank service cannot see:
- Prompts or messages — the words you send to the model.
- Code or file contents — nothing from your working directory.
- Tool calls or their results — agent actions and outputs.
- Conversation text — the full exchange history.
- Which AI platform you use — beyond token counts.
- Your identity — only your chosen codename.
API keys are never collected by the submission path. The only exception is the optional sigrank proxy, which — only when explicitly enabled — receives and forwards provider-bound API keys in memory to route traffic to Anthropic or OpenAI. That content is never persisted or sent to the SigRank service.
Consent model
Consent is captured at enrollment, before routine submission collection begins. The consent record includes:
- The timestamp of acceptance.
- The accepted terms version.
- The accepted privacy version.
- The action or interface that captured consent.
- The linked operator or account.
Consent versions are immutable historical facts: accepting a later version appends or updates a new acceptance record; it does not make an earlier consent appear to have covered new terms. Materially changed purposes require renewed, explicit consent.
Phase 1 status: this document defines the target model. The Phase 2 checklist specifies planned operators fields (consented_at, terms_version, privacy_version, data_opt_out, data_opt_out_at); do not assume they are enforced until the migration and application wiring land.
Data retention
Retention is purpose-limited. Active account links, submissions, derived metrics, and integrity records are kept only while needed to operate the service, support reproducibility, prevent abuse, or meet documented legal obligations.
- Paused collection: retain existing history under the selected account state until deletion, account closure, or the applicable schedule.
- History deletion: remove telemetry and derived history from active systems; retain only minimum deletion/audit evidence and security records where necessary.
- Account deletion: remove the account link and associated active data, subject to the same narrow exceptions.
- Backups: expire according to an operational backup schedule and are not a source for restoring deleted active records except under controlled, documented conditions.
Specific durations must be published before enforcement. This Phase 1 policy intentionally does not invent retention periods absent an approved operational schedule.
Opt-out choices
SignalAF provides three distinct choices. These are clearly labeled — deleting history is not silently equivalent to deleting an account:
- 1. Pause collection. Stop future submissions while preserving existing history until another choice is made.
- 2. Delete history. Remove stored telemetry and derived history associated with the operator, revoke collection capability as needed, and retain only the minimum lawful deletion/audit record.
- 3. Delete account. Delete the account link and associated operator data according to the retention policy.
Until the Phase 5 controls are deployed, users should use the removal contact path. A future data_opt_out enforcement flag is planned; Phase 1 does not claim it is active.
Security model
SigRank defends submission integrity through multiple layers:
- ed25519 signing: every snapshot is signed by the operator's device-bound key, generated locally at enrollment. The server verifies the signature before accepting. The board's
source_attestationstable records signatures for audit. - Server-side rescoring: the server recomputes all derived metrics from the four raw token pillars. Operators cannot submit inflated yield or leverage values directly.
- Replay protection: nonce tracking blocks resubmission of identical snapshots.
- Plausibility gates: implausible token ratios are flagged for review before appearing on the public board.
- Benford's Law check: aggregate leading-digit analysis flags statistical anomalies in token counts. A Benford flag is evidence for review, not proof of fabrication — it is considered alongside data coverage, independence, and collection behavior.
Read tools need no auth — no API keys, no OAuth, no account needed to read the leaderboard or operator profiles. Enrollment requires a connect code from signalaf.com → Settings → New key; a codename alone is not enough for the signed/ranked path.
Privacy modes
Operators participate under a codename — a pseudonymous identifier chosen at enrollment. Your real identity is never required for the signed/ranked path; only the device public key and codename travel with each snapshot. Claimed operators may optionally link a codename to an account for profile features, but the submission payload itself remains pseudonymous.
The paste path (submit_paste) is unsigned and goes through the web-paste endpoint with a codename only — but still sends only the four token counts, not the raw paste. Even if you paste mixed text (prose + numbers), only the extracted token counts are transmitted; the raw text never leaves your machine.
Enterprise review pack
Enterprise review materials — including the privacy model, data policy, consent model, retention schedule, and security architecture — are available for procurement and security review. Research, datasets, reports, and downloads use anonymized signal-########## identifiers and must not include direct identity fields. Contact the team for the enterprise review pack.
FAQ
- Does SigRank read my prompts or conversation content?
- No. The on-device scanner reads four token counts only — input, output, cache_read, and cache_create. No prompts, code, file contents, tool calls, or conversation text are ever transmitted, read, or stored by the SigRank service.
- What data leaves my machine when I submit a snapshot?
- Only four integer token counts plus submission metadata, the device public key, codename, window, and an ed25519 signature. The server verifies the signature and recomputes all derived metrics without ever seeing your data.
- Can I delete my data or opt out of collection?
- Yes. SignalAF provides three distinct choices: pause collection (stop future submissions, preserve history), delete history (remove telemetry and derived data), and delete account (remove the account link and associated data). Until Phase 5 controls are deployed, use the removal contact path.
- How does SigRank prevent leaderboard gaming?
- Every snapshot is ed25519-signed by a device-bound key. The server recomputes all derived metrics from the four raw token pillars — operators cannot submit inflated values directly. Replay protection blocks resubmission, plausibility gates flag implausible ratios, and Benford's Law analysis detects statistical anomalies.
- Is the optional sigrank proxy a submission path?
- No. The optional sigrank proxy is a local loopback transport path to Anthropic or OpenAI, not a submission path to the SigRank leaderboard. When explicitly enabled, it necessarily receives and forwards provider-bound API keys, prompts, and responses in memory, but it does not persist that content or send it to the SigRank service — only provider-reported token counts are appended to a local file.
Learn more: Methodology · Open vs Proprietary · Science