Two key populations, deliberately not merged. The upper table is the platform's real published JWKS: the active DAPS/DCP signing key (a real Ed25519 keypair — it signs CX assertions and, per key_provider.py, every session and refresh JWT this deployment issues) plus any retired verify-only halves, each carrying the status the server publishes. The lower table is cx_key_rotation, the operator rotation ledger written by POST /api/v1/catena-x/ops/keys/rotate — which generates a genuinely new Ed25519 keypair and records its SHA-256 fingerprint, but deliberately does not replace the JWKS key, because replacing that key invalidates every token in flight. A rotation row is therefore not a JWKS entry, and no row here has an issue date or an expiry: a SigningKeyBox holds a keypair, not a certificate. Two things this platform genuinely does not have are named above rather than shown as figures — no store records that a DCP verifiable credential was issued (catena_x.dcp_credentials.DcpIssuer really builds and signs them; nothing keeps the receipt), and nothing schedules a key rotation, so there is no "next rotation" date to report.

This card is the deployment gate; the card below is the decision log. ODRL policy authoring is real: cerivio_cil.catena_x.edc_descriptor builds CX-0152-conformant policy documents, with the prefixed operands the standard requires, and — since 2026-09-18 — cerivio_cil.catena_x.policy_store makes an authored document durable and versioned (odrl_authored_policy). Policy evaluation is also real now: cerivio_cil.odrl_pdp.evaluator reads an authored policy's actual permission/prohibition/constraint fields and computes a genuine ALLOW/DENY, and every such evaluation is persisted to odrl_policy_decision_log (no gov_audit_log emission yet — that is a separate, still-open gap). What is still, genuinely, missing is a DEPLOYED Policy Decision Point: in a Catena-X dataspace that is normally the EDC connector itself, and that connector is not deployed — the real state of that gate is what THIS card reads. So the decision log below has no source='pdp' rows and, on a fresh deployment, no rows at all — rather than the four invented allow/deny/escalate rows that used to be here, which named counterparty BPNs, assets, cohort sizes and an allow rate that had no source. The same reasoning is why the k-Anon Threshold tab's decision-log card shows a real, honestly empty table instead of enforcement events.

The decision log is real; today it is honestly empty. The evaluator is real: cerivio_cil.odrl_pdp.evaluator reads an authored policy's actual permission/prohibition/constraint fields (per CX-0152 · the same operands edc_descriptor builds) and computes a real ALLOW/DENY for any real request against a real, durably authored policy — cerivio_cil.catena_x.policy_store.OdrlPolicyStore (odrl_authored_policy) makes an authored document durable and versioned, which it was not before this pass (authoring built a document in memory; nothing persisted it). What is still, genuinely, missing is a deployed Policy Decision Point: no real PDP or EDC connector is deployed anywhere in this codebase, so this table has zero source='pdp' rows for that reason, and zero rows at all until an internal caller authors a real policy and evaluates a real request. This endpoint is PLATFORM_ADMIN-scoped, so a REGULATOR credential gets a real 403. See cerivio_cil.odrl_pdp.pdp_integration's module docstring for exactly what deploying a real PDP connector requires.

The decision log is real; today it is honestly empty. The k-anonymity algorithm is real: cerivio_cil.catena_x.k_anonymizer performs genuine Sweeney-2002 cell suppression, and POST /api/v1/catena-x/ops/kanon/test runs it against the threshold above. The threshold is real and durable: cx_kanon_setting, floored at 3 (§2 GeschGehG + EU Directive 2016/943), one row per change with reason and actor. Since 2026-09-18 the decision log is also real: k_anonymity_decision_log is a genuine SQLite table, and cerivio_cil.k_anonymity.evaluator computes a real ALLOW/BLOCK for any real cohort size against the real threshold above — reused, not reinvented. What is still, genuinely, missing is an external data clean room (EDC): no such system is deployed anywhere in this codebase, so no cross-tenant disclosure request has ever reached this platform for real, and the table above has zero rows for that reason. This endpoint is PLATFORM_ADMIN-scoped, so a REGULATOR credential gets a real 403. See cerivio_cil.k_anonymity.edc_integration's module docstring for exactly what deploying a real EDC connector requires, and GET /api/v1/compliance-exports/manifest under k_anon_event_log for the same statement served to the Compliance Exports Hub.

This is recorded payload, not wire throughput. The figures above are the byte lengths of the payload_json column of the real cx_transfer rows this platform has created, grouped by asset — real arithmetic over a real table, and the only per-asset volume anything here can answer for. It is deliberately not called throughput: no counter in this repository measures bytes on an EDC wire, cx_transfer has no direction column so there is no inbound/outbound split to report, no call site times a transfer so there is no latency distribution, and /metrics publishes no Catena-X series at all. Those three gaps are named on the cards above instead of being filled with a plausible number, which is what the six hardcoded megabyte figures that used to be on this tab were.