Trace Commons

Data flow

The community surface is a thin read-side over snapshots produced by the Trace Commons server. The pipeline:

  1. Contributor's local Ironclaw redacts a trace and queues it.
  2. Ironclaw uploads the redacted envelope to the hosted ingest API.
  3. Server applies the novelty / perplexity / tail-fraction gate.
  4. Accepted submissions enter the corpus and the credit ledger.
  5. A snapshot worker computes leaderboard rows + corpus aggregates on a schedule, applying the deployment's configured release guards.
  6. This site renders against the latest snapshot.

Consent scopes

The contributor's standing policy carries a consent_scope that determines which uses the envelope contents permit:

  • debugging_evaluation (default): debugging, evaluation, aggregate analytics.
  • benchmark_only: evaluation, benchmark generation, aggregate analytics.
  • ranking_training: + ranker training.
  • model_training: + training-data inclusion.
  • public_attribution: separate, profile-management consent that links the contributor's pseudonym to a public handle. Does NOT grant any trace-content uses on its own.

Aggregation guards

The snapshot worker honours these operator-tunable guards:

  • TRACE_COMMONS_ANALYTICS_MIN_CELL_COUNT — a leaderboard row is suppressed if the contributor's window count is below this threshold. Publication is refused outright unless this is at least 2.
  • TRACE_COMMONS_COMMUNITY_TENANT_IDS — the tenants aggregated into the community surface. Publication is refused unless at least two tenants are in the cohort, so a "community" figure is never one tenant's corpus under another name.
  • TRACE_COMMONS_ANALYTICS_BROAD_RELEASE_NOISE — when enabled, applies keyed bounded jitter to aggregate counts. See the note below.
  • TRACE_COMMONS_ANALYTICS_BROAD_RELEASE_PRIVACY_ACCOUNTING — budget tracking across snapshots.

What the noise setting does not guarantee

An earlier version of this page described the broad-release noise setting as Laplace noise. That was inaccurate and we have corrected it.

What the implementation actually does is derive a bounded signed offset from a keyed hash and add it to the count. It is deterministic for a given input, the derivation includes the exact count being perturbed, and the epsilon figure tracked by the accounting setting is not calibrated against a sensitivity analysis. It is a reasonable obfuscation measure. It is not a differentially private mechanism and it carries no formal privacy guarantee, so it should not be relied on as one.

Until a calibrated mechanism is implemented and reviewed, the server treats no noise mechanism as approved and therefore refuses to publish community aggregates at all. Publication resumes when the minimum-cell threshold, the tenant-cohort minimum, and an approved mechanism are all satisfied.

Source-of-truth links