Aggregate counts of grievances received and resolved, DPDP data-rights requests, takedown actions, and security events. No personal identifiers are published — only totals.
Schema: transparency-v1
| Generated: Loading…
Each counter below is a simple SQL COUNT(*) over our audit log and data-rights table. We publish two reporting windows — the last 30 days, and lifetime totals. The numbers update live with each page load.
No personal identifiers (names, emails, IPs, case IDs) are exposed. The underlying audit log is hash-chained to prevent tampering (see Phase 0.11 in our security roadmap).
DPDP §9 grievance officer queue
DPDP §11–§14 (deletion, export, correction, consent withdrawal, child data, other)
Content takedown requests received via the legal-notices channel
Aggregated from our hash-chained audit log
If a category shows 0/0, either no events of that type have been recorded yet, or the table backing that counter has not yet shipped (e.g. legal_notices is part of Phase 0.12). Counters are not retroactively re-classified; once shipped, they fill in going forward.
Every security-relevant event we record is chained to the previous event via SHA-256 (Phase 0.11). The current tip hash is published below. Record it externally — if we ever silently edit an interior audit row, the chain verification will fail.
—
Algorithm: SHA-256 over canonical pre-image. Updated live.
Live verification
Every change to our legal knowledge graph (sections, precedents, draft variants) is recorded as an audit-chain event in the kg.* namespace. This card surfaces the most recent mutations directly — no need to scroll the full chain.
Endpoint: /api/transparency/kg-events · projects only the curated payload subset · DPDP-safe (no actor / case / document refs)
Aggregate counters for the knowledge-graph correction queue over the lookback window. Counts by surface (what is being corrected) and by status (the lifecycle of a proposal). The median triage latency is the p50 — never p99 or a full distribution — to avoid fingerprinting individual reviews. No per-proposal rows ever cross this surface.
Endpoint: /api/transparency/kg-curation · GET-only · aggregate-only · windowDays clamped 1..30 · NO per-proposal rows
The size and shape of the verified contributor network behind the knowledge graph (Moat #7). Counts by tier (T1 citizen → T4 judicial) for the full network and for the publicly-listed subset. The median onboarding-to-first-acceptance latency is the p50 — never p99 — to avoid fingerprinting individual reviews. The 30-day net positive reputation flow sums only growth (rejections excluded) so a network in a heavy review backlog does not falsely read as shrinking. No per-contributor row ever crosses this surface — no contributorId, no displayName, no token, no bio.
Endpoint: /api/transparency/network-health · GET-only · aggregate-only · 30-day window hard-coded · NO per-contributor rows
A day-by-day breakdown of the positive reputation flow surfaced as a single scalar on the Network Health tile above. Each bar is one UTC day; the height is the sum of positive delta_reputation across accepted contributions on that day. No per-contributor row crosses the wire — only daily totals and bucket sample sizes. Window is hard-coded at 30 days; the day index resets at UTC midnight.
— —
Endpoint: /api/transparency/reputation-flow-history · GET-only · aggregate-only · 30-day window hard-coded · day buckets UTC · NO per-contributor rows
The shape of the audit chain itself: how many events have been recorded, how they're distributed across severity classes (info / notice / warning / critical) and namespaces (contributor.* / security.* / kg.* / etc.), and the 7-day rolling daily rate. Pair this with /api/transparency/verify-chain (which proves the chain is untampered) to close the trust loop: we can prove it's intact AND we can show you what's in it, both at aggregate resolution only. No event id, no actor, no payload, no row hash ever crosses this surface.
— —
Endpoint: /api/transparency/audit-chain-stats · GET-only · aggregate-only · 7-day rate window hard-coded · NO per-event rows
Public scorecard for the background cron dispatchers that keep the platform self-improving: when each cron last ran successfully, when each was last skipped (typically auth failure during a deploy window), and a 7-day count of successes vs. skips. Sourced entirely from the audit chain's own security.cron_action and security.cron_skipped events. Aggregate-only — no bearer-token contents, no IP addresses, no payload internals.
Endpoint: /api/transparency/cron-health · GET-only · aggregate-only · 7-day rate window hard-coded · cron-slug set mirrors RESERVED_FUNCTIONS_ROUTES /api/_cron/* entries (Gate 55 F)
Where contributors are in the verification pipeline, in 5 buckets that partition the population exactly once: signed in but no credentials submitted yet → credentials submitted but pending verification → credentials verified but no contributions yet → first contribution submitted but pending review → first contribution accepted. The 7-day delta arrows show how many contributors entered each bucket within the last 7 days, surfacing where new arrivals are stalling. Aggregate-only — no per-contributor identifiers ever leave the database.
Endpoint: /api/transparency/contributor-onboarding-funnel · GET-only · aggregate-only · 7-day window hard-coded · 5 canonical states partition population exactly once
What kinds of credentials the platform has actually collected, and how many of each are verified vs. pending vs. rejected vs. expired.
Endpoint: /api/transparency/credential-mix · GET-only · aggregate-only · 6 kinds × 4 states three-way mirror (endpoint = JS = migration 0043 CHECK enum)
How fast the open Knowledge Graph correction funnel is moving, as a 30-day daily-bucket time series.
Endpoint: /api/transparency/kg-edit-velocity · GET-only · aggregate-only · 30-day window hard-coded · 5-status set three-way mirror (endpoint = JS = migration 0047 CHECK enum)
How fast the two human-review queues are clearing — 7-day status distribution, pending backlog, and approximate median latency per source.
Endpoint: /api/transparency/reviewer-throughput · GET-only · aggregate-only · 7-day window hard-coded · 2-source set three-way mirror (endpoint = JS = migration 0043 + 0047 CHECK enums)
What the platform actually audits — catalog shape (total event types, distribution by severity) + live 7-day emission frequency per namespace.
Endpoint: /api/transparency/audit-event-catalog-shape · GET-only · aggregate-only · 7-day window hard-coded · 4-severity set three-way mirror (endpoint = catalog = JS)
Of the event types we say we audit, how many actually fired in the last 30 days. Per-namespace coverage + flagged dead catalog types.
Endpoint: /api/transparency/audit-chain-coverage · GET-only · aggregate-only · 30-day window hard-coded · cross-product over AUDIT_EVENT_CATALOG (single source of truth)
The platform's schema-as-history made legible: migration count, contiguity check, and live D1 schema object-type distribution.
Endpoint: /api/transparency/migration-shape · GET-only · aggregate-only · CANONICAL_MIGRATION_FILENAMES filesystem mirror + monotonic-integer contiguity invariant
How the platform is honouring DPDP §13 data-rights requests as a whole: 30-day partition by (type × status), pending backlog, mean time-to-resolution.
Endpoint: /api/transparency/data-rights-funnel · GET-only · aggregate-only · 30-day window hard-coded · 7×3=21 zero-filled cells · REQUEST_TYPES Map mirror with functions/_lib/data-rights.js
Is abuse defense cosmetic or real? 7-day per-scope bucket pressure, throttled-event totals, and hottest-bucket peaks across OTP/leads/data-rights/etc.
Endpoint: /api/transparency/rate-limit-pressure · GET-only · aggregate-only · 7-day window hard-coded · per-actor sha256Hex identifier never projected · sorted by total pressure desc
How the platform is handling inbound legal notices at statutory level: 30-day partition by (classification × decision), channel mix, pending backlog.
Endpoint: /api/transparency/legal-notices-funnel · GET-only · aggregate-only · 30-day window hard-coded · 9×6=54-cell zero-filled grid · 5-channel mix · soft canonical mirror with migration 0019 header docstring
Does the citizen→lawyer marketplace actually match? 30-day partition by status, pending backlog, mean time-to-first-lawyer-response.
Endpoint: /api/transparency/marketplace-quote-funnel · GET-only · aggregate-only · 30-day window hard-coded · 6-cell zero-filled grid · three-way mirror with migration 0022 CHECK enum
What is the workspace actually used for? 30-day TOP-24 event_type mix + 3-cell visibility partition + total event count.
Endpoint: /api/transparency/case-events-funnel · GET-only · aggregate-only · 30-day window · TOP-24 event_type + 3-cell visibility
Is verified-reviewer QA real or cosmetic? 30-day 4-status partition + TOP-12 tier mix + mean turnaround time.
Endpoint: /api/transparency/internal-reviews-funnel · GET-only · aggregate-only · 30-day window · 4-status grid + TOP-12 tier · three-way Set mirror
Is DPDP consent actually free-specific-informed-withdrawable? 30-day 14×3 purpose×action partition + 6-method capture mix.
Endpoint: /api/transparency/consent-events-funnel · GET-only · aggregate-only · 30-day window · 14×3 + 6-method · three-axis three-way Map mirror
Is EN↔HI translation pipeline machine-only or human-reviewed? 30-day language mix + 5-status review partition.
Endpoint: /api/transparency/document-translations-funnel · GET-only · aggregate-only · 30-day window · 2-lang + 5-status · two-axis soft mirror
Is the self-improving moat actually spinning? Five independent improvement loops (reviewer, KG-edit, contributor, translation-review, audit-chain) measured as 7-day per-day rates and summed into a single composite flywheel-RPM.
Endpoint: /api/transparency/platform-learning-velocity · GET-only · aggregate-only · 7-day window · 5 loops · soft mirror
A single machine-readable manifest of every transparency surface — enforced by a two-way filesystem↔registry bijection. Drift is structurally impossible.
Endpoint: /api/transparency/index · GET-only · zero-SQL pure manifest · Gate 71
A single round-trip aggregator that composes ALL 26 transparency surfaces into one canonically-serialized JSON bundle with a SHA-256 digest. Verify locally: sha256(canonical(bundle)) === digest.
Endpoint: /api/transparency/signed-bundle · GET-only · algorithm SHA-256 · Gate 73
A public manifest of every npm dependency, Cloudflare runtime compatibility_date, and SRI host allow-list. Gate 75 enforces equality with package.json + wrangler.jsonc — supply-chain drift is structurally impossible.
Endpoint: /api/transparency/dependency-attestation · GET-only · zero-SQL pure manifest · Gate 75
A public manifest of every scheduled background job — 3 wrangler crons + 2 HTTP-triggered crons. Gate 77 enforces equality with wrangler.preview-queues.jsonc + RESERVED_FUNCTIONS_ROUTES — silent cron drift is structurally impossible.
Endpoint: /api/transparency/cron-schedule-attestation · GET-only · zero-SQL pure manifest · Gate 77
A public manifest of every D1 migration file under cloudflare/migrations/. Gate 78 enforces filesystem↔endpoint equality + canonical naming + monotonic numbering — silent schema-history rewriting is structurally impossible.
Endpoint: /api/transparency/migration-attestation · GET-only · zero-SQL pure manifest · Gate 78
A public per-cron freshness budget — staleAfterSeconds = ceil(expected × 1.5), escalationBudgetSeconds = ceil(expected × 3.0). Gate 79 enforces a five-axis bijection against cron-schedule-attestation — silent budget drift is structurally impossible.
Endpoint: /api/transparency/cron-emission-latency · GET-only · zero-SQL pure manifest · Gate 79
A public manifest of every CSP directive — 15 directives + 6 defensive-baseline invariants. Gate 80 enforces a three-way bijection between this manifest, functions/_middleware.js, and the on-disk _headers file — CSP drift is structurally impossible.
Endpoint: /api/transparency/csp-directive-attestation · GET-only · zero-SQL pure manifest · Gate 80
A public, bilingual, machine-readable catalog of every government safety helpline the platform surfaces to citizens in distress.
Endpoint: /api/transparency/safety-helpline-attestation · GET-only · zero-SQL pure manifest · Gate 83
A public manifest of every abuse-vector category the platform's fixed-window rate limiter meters.
Endpoint: /api/transparency/rate-limit-scope-attestation · GET-only · zero-SQL pure manifest · Gate 82
A public manifest of every non-CSP security header — 9 headers + 26-directive Permissions-Policy + 8 defensive-baseline invariants. Gate 81 enforces a three-way bijection between this manifest, functions/_middleware.js, and the on-disk _headers file — drift is structurally impossible.
Endpoint: /api/transparency/security-header-attestation · GET-only · zero-SQL pure manifest · Gate 81