Prometheus
DE EN
DE EN

07 — Roadmap

The three phases

Each phase delivers on its own, and the order is not decorative: each builds technically on the previous one. Federation without a working protocol would be meaningless, threshold consensus without multiple mirrors impossible.

Phase 1 · running · ~10 weeks

Reach & Runtime MVP

  • Registry scraping via npm, PyPI, Maven Central, crates.io, and Go Modules
  • Self-instrumentation SDKs with four event types
  • One bootstrap mirror in the EU
  • Open Data snapshots as Parquet and CSV.gz — from day 1
  • Public Audit Log via Sigstore Rekor — from day 1
  • K1-K7 as binding acceptance tests before launch

As of 2026-08-13: The collection side is fully delivered, and the mirror accepts submissions — with the complete validation chain and persistence, so far on the development environment. Audit log, snapshots, federation registry, and dashboard remain open. Status in detail →

Phase 2 · planned · ~Q3 2026

Federation & Zero Knowledge

  • End-user agent (Mode B) with k ≥ 25
  • Hybrid aggregator (Mode C)
  • ZK-SNARK attestation for k-anonymity — then mandatory
  • Second independent mirror
  • Gossip federation between mirrors
  • Mix-Net submission as opt-in transport — complements direct egress, does not replace it
  • mTLS as mandatory for federation

Brought forward and already built: the end-user agent, the hybrid aggregator, the ZK attestation, and the Mix-Net transport. All four are implemented and tested — they still go live only in Phase 2, because they presuppose a running mirror and a second operator.

Phase 3 · planned · ~Q1 2027

Threshold Consensus

  • At least three independent mirrors
  • Threshold consensus on accepted aggregates
  • Sybil and Eclipse resistance as acceptance criterion

Brought forward and already delivered in P1-Ph3: the SDK languages Java, Go, Rust, and .NET, the build tool plugins for Maven, Gradle, cargo, and npm, as well as the cross-language conformance suite.

Timeframes for Phase 2 and 3 are planning, not commitment. They depend directly on whether mirror operators and pilot libraries can be found.

Delivery status

What stands today — and what does not

A roadmap without a delivery status is a statement of intent. So here is the actual state as of 2026-08-13, building block by building block. "Delivered" means: built, tested, and through the review gate. It does not mean the thing is publicly running — for that, a reachable mirror is still missing.

Building blocks and their delivery status
Building blockStatus
SDK — Mode ADelivered. Six languages with byte-identical canonical output, backed by a cross-language conformance suite.
Registry scraper — Mode DDelivered. Five registry adapters and a GitHub manifest crawl. Measured so far against fixed test data, not yet against the real registries.
End-user agent — Mode BDelivered, not in operation. Daemon with operating system hooks for Linux, macOS, and Windows; k ≥ 25 is enforced before every egress.
Hybrid aggregator — Mode CDelivered, not in operation. Including the signing and egress path, verified end-to-end against a mock mirror.
ZK attestation for k-anonymityFoundation delivered. The proof is 896 bytes and binds 25 pairwise distinct session tokens. Until it becomes mandatory in Phase 2, the local check remains the binding gate.
Mix-Net transportDelivered. The same bytes across three independent implementations; the submission body itself is untouched by it.
Mirror — submission intakeDelivered, on the development environment. Complete validation chain at the ingress — signature, PII schema, k-anonymity, time window, duplicates — plus persistence. Duplicate detection survives a restart.
Public Audit LogOpen. Next sprint on the critical path.
Snapshot workerOpen. Without it there are no Open Data files yet.
Federation registryOpen. The list of mirrors is specified, but not yet published in signed form.
Open Data API and dashboardOpen. The read endpoints today answer "not implemented yet" rather than "unknown" — so that a peer can tell the two apart.
Publicly reachable mirrorOpen. Depends on the bootstrap funding, the last real launch blocker.

Acceptance criteria

K1 to K7 as measured

The seven criteria decide the Phase 1 launch. They are listed here with their actual measurement status, not with their target value.

Acceptance criteria K1 to K7 with measurement status
CriterionMeasured
K1 — reachMet against fixed test data. The run against the productive registries is pending.
K2 — PURL resolutionMet against fixed test data, with a clear margin to the threshold. Live run likewise pending.
K3 — no PIIFinally met. Both gates work independently; at the mirror the full blocklist is checked and rejection names the offending field.
K4 — no cohort too smallMet locally and at the mirror ingress. The check on the published snapshot is still missing, because there is none yet.
K5 — outage without data lossMirror restart recovery is proven. The full 30-minute scenario is pending.
K6 — analysis in under two minutesNever measured. The criterion runs through the dashboard, and that is not built yet.
K7 — SDK runtime budgetMet in all six languages, each well below the threshold.

The remaining path to the Phase 1 launch is sequenced as "Project 1.0" in seven waves and is publicly traceable through the project's issue tracker — including the dependencies between the waves. Repository on Codeberg →

Before launch

Status of the open decisions

The decision blockers are closed. Four of the points that blocked the Phase 1 launch were decided on 2026-05-29 — three via ADR, the GDPR assignment via the responsibility matrix in the infrastructure documentation. They are listed here with their decision, not as open questions. What remains open is listed below.

Anti-Sybil — decided

Rate limit per DID (≤ 24 in 24 h for modes A, B, and C), cross-mode plausibility flag between Track A and Track D, and a 7-day burn-in as trust_tier: "new". Proof-of-Work was explicitly rejected — it wastes end-user CPU and works asymmetrically against botnets. Phase 2 adds a maintainer Web-of-Trust.

GDPR per Mirror — decided

The mirror operator is the sole controller for the aggregates stored and published in their mirror. The reporter is a data subject with their own DID; joint controllership does not arise. Each entry in mirrors.json requires a published privacy policy.

PURL and Aliases — decided

PURL strictly according to registry assignment, without mutation. Forks and renames run via a separately signed alias table; resolution is a pure view-layer function, which is why aggregate storage and audit log remain unchanged. Aggregates in __small_cohorts must never be resolved by name.

Open Data License — resolved, clearance pending

Phase 1 snapshots are published under CC-BY-4.0 and carry a Provisional clause in the manifest. The launch is explicitly not blocked by this. The only open item is the Foundation legal clearance; if it is rejected, the published snapshot remains valid and a re-issue appears under a new snapshot ID with new licensing.

Open before mirror launch: bootstrap financing. Who covers the hosting costs of the Phase 1 reference mirror of around €50 per month — foundation sponsorship, university data center, or crowdfunding? This point is scheduled for "before the mirror goes productive" and is thus the last real launch blocker. Help with this →

Additionally, continuously calibrated but not launch-blocking: the specific threshold values of the anti-Sybil heuristic — factor-10 threshold between Track A and Track D, burn-in period, and rate limit values are reviewed quarterly.

To open contributions →