# AERL Audit Criteria for Public Rating Cards

Version: 0.1.0-public
Date: 2026-05-08

This document explains how to read AERL rating cards on the public jp-election-data surface.

AERL means Artifact Evidence-Readiness Levels. It is a way to describe whether a data artifact has enough evidence, release control, reproducibility, and residual disclosure for a stated use.

An AERL rating is not official certification, legal judgment, administrative authority, or proof of truth.

## What The Rating Evaluates

The rating evaluates the published data artifact and its evidence package.

It asks:

- Is the source family identified?
- Is the release version fixed?
- Are the files listed with stable roles?
- Are core facts separated from viewer or spreadsheet deliverables?
- Are validation and consistency checks documented?
- Are residuals and limits disclosed?
- Is the allowed use clearly separated from blocked use?

The rating does not decide the official election result. Official election material remains with the relevant election authority.

## Public Quality Axes

| Axis | Public question | Expected public evidence |
|---|---|---|
| Source basis | What official or public source family was used? | Source family label, source role, public source reference where available |
| Release boundary | Which version is being evaluated? | Release ID, publication date, file roles |
| File identity | Are the evaluated files fixed? | Public manifest entries, file hashes, sizes |
| Structural validity | Do the files follow the expected schema? | Tidy/data-contract documentation and validation status |
| Semantic validity | Are election, party, district, and municipality meanings controlled? | Normalization rules, dictionaries, public notes |
| Numerical consistency | Do totals and election invariants reconcile within the stated boundary? | Validation reports, residual notes, known limitations |
| Provenance support | Can the release be traced back to source families without relying on a viewer page? | Public-safe source register and release metadata |
| Reproducibility | Can a reviewer cite the same release and reproduce the same comparison boundary? | Versioned release ID, manifest, documented layer model |
| Residual disclosure | Are known disagreements or uncertain points visible? | Known residuals document and rating-card blockers |
| Public boundary | Does the public page avoid internal-only traces? | Public-safe docs, public keys, no internal worklog details |
| Claim boundary | Does the card say what it can and cannot support? | Allowed use, blocked use, allowed claims, forbidden claims |
| Human review | Is the level clear about whether human review is pending or completed? | Human-review field and next-action notes |

## Public R Level Guide

| Level | Public meaning | Typical allowed use |
|---|---|---|
| R0 | Unassessed raw or discovered material | Discovery only |
| R1 | Working artifact | Internal work only |
| R2 | Internally validated candidate | Internal analysis and anomaly search |
| R3 | Review-grade package | External review and publication check |
| R4 | Reproducible report-grade package | Public technical review and report-grade citation to a fixed release |
| R5 | Decision or hearing-grade package | Human-reviewed decision support |
| R6 | Certification or legal-support package | Legal or certification support with stronger evidence controls |
| R7 | Official or authoritative record | Official record controlled by the relevant authority |

The public jp-election-data project does not self-grant R7.

## R4 Public Criteria

A public R4 rating normally requires:

1. A fixed release ID.
2. A public manifest or equivalent file list.
3. Stable roles for core fact files.
4. Public-safe source and provenance summary.
5. Documented schema or tidy rules.
6. Documented validation or consistency checks.
7. Known residuals or limitations disclosed.
8. Clear allowed use and blocked use.
9. Clear statement that the rating is not official certification or truth proof.

R4 allows report-grade public review of a fixed release. It does not allow claims that the dataset is official, legally certified, or complete beyond the stated release boundary.

## Canonical, Release Facts, And Official Records

`release facts` are versioned data files published within a fixed release boundary.

`canonical` on this public surface means the project treats the release-bound files as the reference files for reuse, citation, and reproducible comparison within the project.

`official` means controlled by the legally or institutionally authorized election authority.

These are different claims. A file can be canonical for this project without being an official record.

## Allowed Claims For A Rating Card

A public rating card may say:

- This release has an AERL evidence-readiness level.
- This release can be used for public review within the stated boundary.
- The listed files are the project's release-bound reference files.
- Known residuals and blocked uses should be read before reuse.

## Forbidden Claims

A public rating card must not be used to say:

- The rating certifies the official election result.
- The rating proves the numbers are true.
- The project replaces election authority records.
- Viewer pages, summaries, or workbooks are fact authority by themselves.
- A mutable latest link is enough for citation without resolving the release ID.

## How To Cite A Rated Release

When citing data connected to an AERL rating card, cite the release ID and the artifact role.

Do not cite a viewer page or `latest` route alone as numeric authority.

## Regrade Policy

A rating can be changed if new information appears.

Triggers include:

- Source conflict.
- Parser or normalization bug.
- Schema or file-role issue.
- Residual escalation.
- Overstated public claim.
- Missing human review for a stronger use case.

When this happens, the rating should be revised, frozen, downgraded, revoked, or superseded as appropriate.