Rubric: one retry ceiling

Written by a person. Last read by a person on 2026-09-04, 4 days ago. Its facts were checked by the eval suite on 2026-09-07.

Enforced by check_retry_ceiling.

The claim

The retry ceiling this site documents and the retry ceiling it enforces are the same value, read from the same key, so they cannot drift apart.

Observable evidence

• Whether retry.max_attempts exists in data/volatile.yaml.
• Every line of content mentioning max_attempts, and whether it reads the shared key or states a number of its own.

The pass bar

The key exists, and no line states a retry ceiling without reading it.

This matters more than it looks. A-P0-6 makes cost containment a documented feature and the site's operating constraint. A page that tells a reader to cap their retries while the system serving it runs an uncapped loop is not documentation, it is advice, and the difference is the entire argument this project makes.

Ambiguous cases

Naming the key. Allowed, and necessary. Prose explaining where the ceiling lives should be able to write retry.max_attempts without tripping the check. What is caught is a bare mention paired with a number, which is a second copy of the value.

Illustrative code with its own defaults. A generic backoff helper with base=1.0 is not claiming to be this site's ceiling. Those blocks carry a volatile-ok comment stating so, and the exemption is visible in the source rather than silent.

A reader's own ceiling. Documentation that shows a reader configuring max_retries on their client is describing their system, not ours. This currently passes only because such lines carry no digit adjacent to max_attempts; a stricter reading would need to distinguish whose ceiling is being discussed, which is a judgement rather than an observation.

The enforced half. Until the live demo exists in change 0005, only the documented half is real. This rubric guarantees one source of truth; it cannot yet prove the running system reads it, and saying so is more useful than implying otherwise.