Cunicula Score 4.0
Every directory record receives one conservative score from 0 to 100. It balances privacy (25 points), control (20), transparency (20), security history (25), and accountability (10). The score is not a guarantee of safety; the five pillar values, evidence status, recorded risk, incidents, and sources remain visible.
- Privacy: combines the reviewed identity-exposure level with operator data exposure.
- Control: uses the reviewed control model, from local self-custody through custodial operation.
- Transparency: combines the reviewed source model with a dated, scoped, cited current audit record. A name in
auditedByalone earns no audit points. - Security: combines recorded risk with normalized incident severity, status, impact, disclosure, and remediation.
- Accountability: uses existing corporate identity, ownership, jurisdiction confidence, operating status, and incident disclosure fields.
Each listed service publishes three normalized inputs: operatorDataExposure, controlModel, and sourceModel. Each input carries its reviewed value, review date, and source URLs in score_review. An unknown value earns zero points. It does not cancel the score; it sets score_evidence to limited. Unresolved severe incidents and closed or partly reviewable critical code can cap the final result after the five pillars are summed.
Privacy observations
Reader surfaces show the recorded inputs beside the balanced score rather than treating the score as a substitute for facts.
- Identity exposure: Level 0 has no required account data. Level 1 has basic account or payment metadata. Level 2 has persistent contact, billing, or delivery data. Level 3 has conditional identity verification. Level 4 has full identity verification.
- Operator data: states whether a hosted operator is recorded.
- Jurisdiction: shows the recorded value and whether it is verified, inferred, or unknown.
- Five Eyes: neutral jurisdiction context. Membership does not by itself establish that a service is safer or less safe and does not change the compatibility calculation.
The API's privacy_score, privacy_score_version, and privacy_factors fields are deprecated from 2026-08-23 and remain available through 2027-02-23 for compatibility. New consumers should use privacy_observations.
Source coverage
Source coverage describes how completely current material claims have been checked. It does not say that a service is safe.
- Current: material claims checked against current sources.
- Partial: some material claims still need confirmation.
- Limited: current source coverage is limited.
- Provenance: identifies the strongest source tier and the share of cited sources in that tier.
- Review date: states when the record was last checked; review-due notices remain visible after a category window expires.
Promotion follows that order and requires a completed source review. A record becomes review due on the first day after its category window. The due notice keeps its last supported facts, sources, review date, provenance, and source-coverage status visible while blocking promotion until the record is reviewed again.
Deprecated API compatibility
The API's evidence_confidence, evidence_score_version, and evidence_factors fields are deprecated from 2026-08-26 and remain available through 2027-02-26 only for compatibility. New consumers should use evidenceStatus, evidence_provenance, and lastReviewed.
The legacy executable compatibility module remains available at /methodology/scoring-v3-1.mjs through the same window. It is not a service-safety model and its outputs are not shown on reader surfaces.
The independent Score 4.0 verifier verifies signed-release checksums, signed reviewed inputs, and every canonical score, breakdown, cap, evidence state, and rationale served by the API. Deprecated fields remain compatibility-only and do not drive reader ordering.
Recorded risk
Risk stays categorical and visible beside the score so a material warning cannot be hidden inside a composite number.
- Standard: no material warning is recorded.
- Caution: a limitation, unresolved claim, metadata issue, or operating concern is recorded.
- Danger: an active severe incident, loss of service, or direct material user harm is recorded.
- Risk remains separate from privacy observations and source coverage.
How to read the fields
A service can have low identity exposure, strong evidence, and high recorded risk at the same time. SolvoCard is one example. Its no-document signup affects privacy. Current reporting about unpaid balances affects risk. These are different facts.
Not included
- Popularity, price, visual design, or marketing claims.
- An overall recommendation or claim that a number guarantees safety.
- Free points for unknown facts. Unknown normalized inputs score zero and show Limited evidence.
Signed dataset releases
Release 2026-08-27 contains a point-in-time services.json and the exact scoring-v4.mjs and signed score-inputs.json used with it. An Ed25519 signature covers SHA256SUMS; those checksums cover the dataset, score inputs, executable scoring models, primary-source records, and release manifest.
Cunicula publishes an Ed25519-signed dataset snapshot every Friday at 16:00 Australia/Melbourne. Urgent factual corrections may publish sooner; the next Friday snapshot still proceeds. Each release is immutable and remains available through the release index.
Public key fingerprint, SHA-256: fb79a0b4b48612d4d5238ab715420045080c2798b28d71523bb27ee7e8bd7eff. Download the public key and detached signature, then run these commands from the directory containing all release files:
OpenSSL must print Signature Verified Successfully, and every checksum must print OK. A failed signature or checksum means the release must not be used. The manifest records the dataset schema, record count, source commit, scoring versions, and key fingerprint.
Per-record edit history
Every provider page includes a record edit history. Every /api/v1/services/{slug} response exposes the same entries as edit_history: changed_at states when,changes states the exact before and after values, why carries the recorded revision reason, source.commit preserves the revision identifier, and source.url links the matching public history entry on the provider page. source.review_source records the review source where available. See the Privacy.com page for a public example.
History is generated deterministically from all committed revisions of data/services.json, tracking records by stable internal identity across slug changes. Creation events are summarized. Internal affiliate and numeric identity fields are excluded, and the normal public-claim validation remains in force so unsupported historical ownership or intelligence text is not republished. This record history is separate from the monitored external-document change feed. Recent listing edits are also available through the edit-history RSS feed.
The API's legacy history_scope.source_repository key is retained for compatibility. Its value points to this public provenance and history surface, not to a source-code repository.
Changes
- 2026-08-26, Score 4.0: added the five-pillar balanced score, three normalized inputs, conservative unknown handling, and incident and closed-source caps.
- 2026-08-23, Formula 3.1: removed operator-jurisdiction deductions, replaced the reader-facing privacy number with observed identity and operator facts, and began the six-month API deprecation window.
- 2026-08-09, reproducibility release: published the executable score model, exact score inputs and computation time, the first signed dataset release, and field-level record edit histories.
- 2026-08-06, Formula 3.0: defined separate privacy and evidence formulas. Risk no longer changes either number.
- 2026-07-16: stopped applying operator-jurisdiction deductions to local software and protocols with no hosted operator data.
Corrections
Corrections update the service facts, sources, review date, and affected fields together. The review checklist is in How to vet a privacy tool.