ADR-0005: Forgetting by tiers — distil every rung up front, then destroy keys on schedule

Status: proposed
Date: 2026-10-12
Requirements touched: P-05, P-07, P-13, S-03, S-04

Context

Rafa: "as more info pours into the device, it 'forgets' (lowers resolution of historical info, so remembers 'gist' for up to 30 days, then only outcomes (which should take very little memory comparatively)."

Flash doesn't reliably erase (wear levelling leaves stale copies), so deleting files is not forgetting.

Options

Option	For	Against
Re-distil old material down when it ages	One copy at a time	Needs compute later, perhaps when the battery is low; the high-rung copy exists until the job runs
Distil every lower rung at sealing; store each rung under its own key; destroy keys on schedule	Decay costs no compute and can't be skipped; works with the device off as long as the clock runs	More storage at first (small — text is tiny, see `01-concept/resolution.md`)

Decision

At sealing, a block captured at R3 produces R3, R2 and R1 copies.
Copies go into containers per (day, rung): e.g. 2026-11-03/R3, 2026-11-03/R2, 2026-11-03/R1. Each container has its own key in the secure element. Thirty days × three rungs ≈ 90 live keys, plus R1 keys.
Decay = destroy the container key on its date.
Retroactive lowering of sealed blocks and shortening one stretch = re-key: decrypt the container, drop or replace those blocks, re-encrypt under a fresh key, destroy the old key. Same mechanism for any downgrade.
Clock: backup cell + secure-element monotonic counter checkpointed hourly. If the clock is ever found behind a checkpoint or reset, fail closed: destroy every R3 and R2 key, keep R1.

Consequences

The forgetting curve is enforced by hardware, not by a background job that might not run.
A dead backup cell costs you your gist, not your outcomes. That seems like the right failure.
Confirm key-storage capacity of the chosen secure element.

# ADR-0005: Forgetting by tiers — distil every rung up front, then destroy keys on schedule - **Status:** proposed - **Date:** 2026-10-12 - **Requirements touched:** P-05, P-07, P-13, S-03, S-04 ## Context Rafa: "as more info pours into the device, it 'forgets' (lowers resolution of historical info, so remembers 'gist' for up to 30 days, then only outcomes (which should take very little memory comparatively)." Flash doesn't reliably erase (wear levelling leaves stale copies), so deleting files is not forgetting. ## Options | Option | For | Against | |---|---|---| | Re-distil old material down when it ages | One copy at a time | Needs compute later, perhaps when the battery is low; the high-rung copy exists until the job runs | | **Distil every lower rung at sealing; store each rung under its own key; destroy keys on schedule** | Decay costs no compute and can't be skipped; works with the device off as long as the clock runs | More storage at first (small — text is tiny, see `01-concept/resolution.md`) | ## Decision - At sealing, a block captured at R3 produces R3, R2 and R1 copies. - Copies go into **containers per (day, rung)**: e.g. `2026-11-03/R3`, `2026-11-03/R2`, `2026-11-03/R1`. Each container has its own key in the secure element. Thirty days × three rungs ≈ 90 live keys, plus R1 keys. - **Decay** = destroy the container key on its date. - **Retroactive lowering of sealed blocks** and **shortening one stretch** = re-key: decrypt the container, drop or replace those blocks, re-encrypt under a fresh key, destroy the old key. Same mechanism for any downgrade. - **Clock:** backup cell + secure-element monotonic counter checkpointed hourly. If the clock is ever found behind a checkpoint or reset, **fail closed**: destroy every R3 and R2 key, keep R1. ## Consequences - The forgetting curve is enforced by hardware, not by a background job that might not run. - A dead backup cell costs you your gist, not your outcomes. That seems like the right failure. - Confirm key-storage capacity of the chosen secure element.