Documented
Evidence and limitation are fixed for the exact release.
From finding to verification
A problem does not close when it is published
Each receipt preserves the original finding, institutional reply, promised change and retest. Repair receives the same prominence as the problem.
Lifecycle
From evidence to verified repair
A repair is not verified by a promise or a new policy alone. The relevant behaviour or document has to pass the stated check.
Sent
The actor able to fix it receives the claim and relevant artefacts.
Updated
The policy, SDK, choice flow or documentation changes.
Retested
The same procedure checks whether the original behaviour still reproduces.
CAL
The v1.0 ledger contains calibration repairs only
They demonstrate statuses and historical continuity. No real institution is credited or criticised here before testing.
proposed
REP-CAL-001
Oraș Test — Sesizări
Furnizor fictiv: Initialize the analytics SDK only after explicit acceptance, or remove it from the core journey.
Verification test
Repeat the journey on a clean install and confirm no pre-choice connection.
proposed
REP-CAL-201
Transport Test
Operator fictiv: Publish the route backend’s contractual role and data categories.
Verification test
Documentary verification; no app change is necessarily required.
verified
REP-CAL-301
Identitate Test
Furnizor fictiv: Delay SDK initialisation until after acceptance.
Verification test
Three clean installs covering refusal, acceptance and withdrawal.
Verified: August 5, 2026