Lethe.

Methodology

The Lethe Compliance Method.

A documented way to run the Delete Act cycle: eight steps, the same order every time, each one with defined inputs, defined outputs, and a record it leaves behind. This is the method, written down so it can be checked.

What this is

A method is the cycle written down and run the same way every time, with a record at each step. The sameness is the point. It is what lets the evidence hold and the audit go quietly. None of this is proprietary magic. It is the Delete Act executed in the right order, documented so it can be checked by you, your counsel, or an auditor.

The eight steps below map to the obligation itself. Read across each one and you can see exactly what goes in, what comes out, and what gets kept. That last column is the part most tools leave implicit, and it is the part that matters in 2028.

The eight steps

Inputs, outputs, and the record at every stage.

01

Retrieve

Pull the current deletion list from DROP, on cadence.

Inputs

DROP access, the cycle schedule, and your list selections.

Outputs

This cycle's request set: the full opted-in universe on the first pull, deltas and withdrawals after.

Record produced

Retrieval timestamp, source file identifiers, and a cycle ID that ties everything that follows to this pull.

02

Normalize

Standardize your records to the state's field rules before anything is hashed.

Inputs

Your exported records and the published field-standardization rules.

Outputs

Clean, conformed records ready to hash, with malformed rows surfaced rather than dropped in silence.

Record produced

The ruleset version applied, and row counts in and out, so the transform is reproducible.

03

Match

Hash to the state's exact method and resolve matches against the DROP list.

Inputs

Normalized records, the DROP hashed identifiers, and your six list selections.

Outputs

An exact-match set per identifier list, and a clean no-match set.

Record produced

Hash method (SHA-256, Base64, no salt), per-list match counts, and a check against CalPrivacy's reference tool.

04

Delete

Produce the deletion worklist and direct your processors.

Inputs

The match set, your record references, and the applicable exemptions.

Outputs

A worklist keyed to your own record IDs, exempt records flagged rather than erased, and processor-direction notices.

Record produced

The worklist, the exemptions claimed, and a log that the instruction to service providers and contractors went out.

05

Suppress

Add the matches to a durable suppression record, and re-apply it every cycle.

Inputs

The match set and the prior suppression record.

Outputs

An updated suppression record, with anyone who reappeared flagged against the feed that reintroduced them.

Record produced

Suppression entries, reappearance counts, and the responsible sources, so you fix the leak instead of re-deleting forever.

06

Verify

Chain and anchor the cycle's record to a neutral authority.

Inputs

The cycle's complete operational record.

Outputs

A hash-chained log anchored to an outside authority, carrying the evidence grade it earned.

Record produced

The chain head, the anchor receipt, and the grade from A to D, stated plainly rather than asserted as a bare pass.

07

Report

Write and submit the status of each request to DROP.

Inputs

The per-request match and deletion results.

Outputs

The status file DROP ingests, with the correct codes and original filenames, ready before the window closes.

Record produced

The status submitted for each request and the submission time, inside the 45-day reporting window.

08

Preserve evidence

Bundle the cycle into an audit package, and retain it.

Inputs

Every record produced above and the chained, anchored log.

Outputs

A human-readable, independently verifiable audit package for this cycle.

Record produced

A versioned package retained for the audit window, so what an auditor reads in 2028 was built the day the work was done.

Why it is built this way

Each step produces a record, and the records chain together. By the time a cycle is done, you do not have a claim that the work happened. You have an ordered, timestamped trail that an outsider can follow and verify. That is the difference between a process and a defensible process, and it is the whole reason the method is written down rather than kept in someone's head.

See how the evidence is verified

See the method run against your own data.

A readiness assessment applies the first steps to your records and shows you where you stand.