Open proposalsProposal 2Draft 1

Logs that expire

How to write a record of an agent's work so that it knows, when it is written, whose law reaches it and when it must go, and can show afterwards that it went

Proposed by: LexLintSean McDermott, Co-Founder and CEO
Draft 1: 5 November 2026Comments to open@lexlint.io
License: CC BY 4.0Adopt it, fork it, improve it

Legal information, not legal advice. This proposal describes a way to keep the records a law asks for and to delete them when a law asks for that. It does not decide which law applies to anyone, which period binds a record, or whether a deletion meets any law's requirements; those are questions for counsel. See the notice in the footer.

Summary

Laws pull a record of an agent's work in two directions. Some say keep it: for at least six months, on a rolling 180 days inside one country, for five years. Others say let it go: no longer than its purpose needs, and on request within a month. A record built only for integrity cannot forget, and a record built only for privacy cannot prove anything. This proposal keeps both by splitting the record in three: an envelope that holds the facts the law turns on and no personal data, an append-only chain over those envelopes, anchored in public only by digest, and a deletable store that holds the payload under keys that expire by jurisdiction and retention class. Whose law reaches the record, and when it must go, are decided when it is written. At expiry or on a valid erasure request the payload is deleted, its keys are destroyed and the destruction enters the chain, which still verifies. It says how far the European Data Protection Board's reading of blockchains reaches each layer, including on destroying a key.

Figure 1. What stays and what goes. The chain keeps the facts and a commitment; the content and its keys go on the day the record says, and their going is written into the chain.

1The problem, in one page

A record of what an agent did is asked for by several laws at once, and they do not ask for the same thing. India's CERT-In Directions of 2022 ask an operator to "retain them securely, within Indian jurisdiction, on a rolling 180-day basis" and to hand them over with an incident report or on order (in force since 27 June 2022). CERT-In's AI Security Auditing Guidelines of 4 November 2026, guidance read with those Directions, ask that an agent's execution chain (its tool calls, delegated tasks, approvals, external actions and outputs) be "logged and protected against unauthorised modification" (s. 9.7). The EU AI Act asks the provider and the deployer of a high-risk system to keep its logs for a period appropriate to its purpose, "at least six months, unless other Union or national law, such as data-protection law, provides otherwise" (Art. 19 and Art. 26(6), from 2 December 2027 for Annex III systems). Korea asks that an access record be stored "safely against forgery and alteration" for at least a year (PIPA Art. 29).

The same entry can carry personal data that another law says must go. The GDPR keeps personal data in identifiable form "for no longer than is necessary for the purposes for which it is processed" (Art. 5(1)(e)) and gives a person the right to have it erased, answered within a month (Arts. 12 to 22). Its exception for a legal obligation, Art. 17(3)(b) as the Regulation states it, counts an obligation "by Union or Member State law". A retention period set by another country's law is not named there. So one entry, about one person, can sit under a legal responsibility to keep it from one jurisdiction and a legal responsibility to delete it from another. Which prevails for that entry is a question for counsel, and it can only be asked if the record knows both facts.

The usual designs answer half the question. A hash-chained, signed, externally anchored log answers the integrity half and cannot forget: once personal data is in it, nothing can take it out without breaking the chain. A log with ordinary deletes answers the privacy half and proves nothing: anyone who can delete an entry can delete the evidence that they did. Encrypting entries and later destroying the key is often offered as the bridge. It helps, and section 8 explains why it is not enough by itself.

The claim in one line

A record has to know, at the moment it is written, whose law reaches it and when it must go, and it has to be built so that its content can go on that day while its proof of existence, and the proof that the content went, stay.

2Where each part of the record lives

The record is split by what each part must survive, and by who can ever read it.

Layer	Holds	Can it change?	Holds personal data?
Envelope	The facts the law turns on, fixed at the time of the act: when, what kind of act, which agent, the jurisdiction readings per party, the retention class and its two dates, any hold, where the payload is held, a commitment to the payload	Never. It is written once	No, by design. It names no person and keeps results, never signals
Chain	The envelopes in order, each linked to the one before it, signed, under the operator's access control; plus the destruction, hold and production events	Only by appending	No: it holds envelopes and events, never a payload or a ciphertext
Public anchor	A checkpoint digest of the chain at fixed intervals, registered where the operator cannot rewrite it (a transparency log, a timestamping authority)	Never	No: a digest of envelopes. Where a deployment registers single entries there instead, each carries only a keyed commitment whose secret stays in the payload store
Payload store	The content: inputs, outputs, tool results, files, the identity of the people involved, each payload encrypted, beside the secret that opens its commitment	Yes. Each object is deletable	Yes. This is the only layer that does
Key service	The keys that encrypt the payloads, arranged so that a whole retention class can be destroyed on one day and one person's keys on another; it signs a receipt for every key it destroys	Keys are created, used and destroyed; none is exported	No

A fifth, small store, the subject index, maps a person to the records about them, so that an access or erasure request can be answered. It lives beside the payload store, under the same keys, and goes with them.

Two rules hold the split together. Nothing in the envelope or the chain identifies a person, directly or through a digest that can be tried against candidates. And nothing in the payload store is needed to verify the chain, so deleting any payload breaks no link.

3At event time: the envelope

Everything that decides a record's fate is written into its envelope when the act happens, by the component that holds the facts, and never derived afterwards. That is the requirement the paper Whose law was that? states as R9, the parties known when the act happens, and R2, made at the time by the component that holds the signal.

Field	What it holds	Why it is here
id	A random identifier for this record alone	Records about one person must not be linkable through the envelope
prev	The digest of the previous chain entry	The chain
at	The time of the act, from a clock synchronized to a named source	Reporting clocks start from it; the CERT-In Directions name the source
act	The kind of act: a tool call, a refusal, an approval, a delegation, a disclosure	One record per consequential act, refusals included
actor	The agent, its version, the organization that runs it, and a reference to the delegation chain	Which agent, on whose authority
readings	For each party, the jurisdiction reading as it was given: the party, the fact (presence, residence, establishment), the jurisdictions or `unknown`, its source and issuer	Retention, location and production all turn on these; carried as the proposal Jurisdictional context defines them
context	The identifier and version of the legal context that governed the act, and of the retention policy table read	A later reader can tell which answers went stale
retention	The retention class, `keep_until` (the latest floor that applies), `delete_by` (the earliest ceiling that applies), the jurisdictions each date came from, and a conflict mark when the first falls after the second	The record knows when it must go
hold	None, or a reference to a hold event	A hold suspends `delete_by`
location	Where the payload is held, as a jurisdiction	Some laws ask for the record inside one country
demand	Who may demand the record, by authority and law	What must be produced differs by jurisdiction
payload	A hiding commitment to the payload, where the payload store holds it, and the identifier (never the value) of the key that wraps it	Binds the content to the record without holding it

The envelope holds results, never signals. A reading says "presence: FR, observed, by edge.example"; it never holds the IP address it came from, nor a hash of it (R3). "Unknown" is a value (R4), and the retention policy says which class an unknown reading takes, so a missing fact never becomes a guessed country.

An envelope can still identify someone in combination. A coarse reading, a time and an act can single out a person in a small population. The EDPB's guidelines note that on-chain metadata, event logs included, "may constitute personal data when they enable direct or indirect identification" (footnote 12). Whether a given envelope does is assessed in the deployment's impact assessment, and the remedy is a coarser reading or a field moved into the payload, never a field kept because the chain needs it.

4The write path

Read the parties. Take each party's reading as the work carried it in, or unknown. Never re-derive one from the socket (R7).
Set the dates. Look up each reading in the retention policy table, which is counsel's statement of what each jurisdiction's law asks and the organization's own period where the law sets none. Take keep_until as the latest floor and delete_by as the earliest ceiling. Where a floor falls after a ceiling, write the record anyway, mark the conflict, and record the rule counsel set for that pair, or unresolved when there is none (section 7). The system never picks a winner by itself.
Check for holds that already cover the matter, the parties or the period.
Encrypt the payload under a fresh record key, with the envelope's digest as associated data, so a payload cannot be moved under another envelope. Wrap the record key under a key for this person in this retention epoch, and wrap that key under the epoch key for the retention class and delete_by day. Destroying either the person's key or the epoch key makes the payload unreadable.
Store the ciphertext, and the secret that opens the commitment, in the payload store in the jurisdiction location names. Add the record's identifier to the subject index.
Append the envelope to the chain, sign it, and anchor the chain's head outside the operator's control at a fixed interval.

Rounding. An epoch key covers one class and one day. A record whose delete_by falls inside a day goes in the epoch that ends on or before it, so a ceiling is met early rather than late; a floor is checked against the epoch's end before the record is placed. A record whose floor and ceiling cannot both be met in any epoch is a conflict, and step 2 already marked it.

5Expiry and erasure

At expiry. On each epoch's day the key service destroys the epoch key, unless a hold has taken some of its records out of the epoch first (section 7). The payload store deletes every object in that epoch. A destruction event is appended to the chain: the epoch, the number of records, the key identifier, and the key service's signed receipt.

On a valid erasure request. The subject index gives the person's records. For each one not under a hold, and whose keep_until has passed or for which counsel has decided that erasure prevails, the person's keys in each epoch are destroyed, the payloads and their commitment secrets deleted, and the subject index entry removed. A tombstone for each record is appended to the chain, naming the record and the reason class (erasure request) and never the person.

Both, always. Deletion removes the content from the stores the operator controls. Key destruction reaches the copies a deletion cannot reach on the same day: backups, replicas, caches, a store being migrated. A design that only destroys keys leaves ciphertext behind for as long as it is kept, resting on the cipher holding for that long, and section 8 says why that is weak. A design that only deletes leaves readable copies in every backup until the backup expires. With both, the only copies that rest on key destruction alone are backups and replicas, and they expire on a stated schedule, so that reliance is short and has an end.

What is left. An envelope with no personal data, and a commitment whose secret is gone. The chain verifies end to end, because it was built over envelopes and commitments and never over content. The deletion is in the chain as an event like any other, signed and anchored, so the record is changed only in the one way it was built to change, and the change is evidence of itself. Korea's protection "against forgery and alteration" and the CERT-In guidelines' protection "against unauthorised modification" both ask that a record not be changed without authority or without trace. Whether an authority reading a given law or guidance accepts an authorized, recorded destruction on those terms is a question for counsel; this design makes every destruction visible, with its authority, so that the question can be asked and answered.

The commitment matters. An unsalted hash of a short value (an email address, a user identifier, an IP address) can be recovered by trying candidates, so it stays personal data after the content is gone. The commitment is either a keyed hash under a per-record key held only in the payload store, or a hiding commitment whose opening secret is held there. Either way the secret goes with the payload.

6Proving it later

What has to be shown	How this design shows it	Who may ask
A record existed, and is as it was written	The chain verifies from any anchored checkpoint; the envelope and commitment match	A regulator, a court, an auditor, a counterparty
It was kept as long as required	No destruction or tombstone event for it before its `keep_until`	A regulator under a retention law
It was destroyed on time	A destruction event or tombstone dated on or before `delete_by`, with the key service's receipt	A supervisory authority, the person concerned
Nobody read it after that	The key service's own log shows no use of the destroyed key after its receipt; keys are generated and held in hardware that cannot export them, and its attestation says so	An auditor
No backup holds it readably	A sampled restore of an expired epoch yields only ciphertext under destroyed keys	An auditor
The records were what they claimed	Each payload decrypts and opens its commitment while it exists; a payload that does not match its envelope is detected	A court, at production

Production. The envelope lets a holder find the records a demand reaches (by jurisdiction, time, act and party) without opening any payload, and decrypt only those. What each law asks differs. The AI Act asks a provider to give a competent authority access to the logs under its control "when it makes a reasoned request" (Art. 21(2), from 2 December 2027). The CERT-In Directions ask for logs with an incident report or when CERT-In orders it. The GDPR asks a controller to make its record of processing available to the supervisory authority on request, and that record states "where possible the envisaged time limits for erasure" (Art. 30); the retention policy table this design reads is that statement, kept current.

A produced copy leaves the design. Once a payload is decrypted and handed over, no key destruction reaches it. Production is therefore an event in the chain like a destruction: which records, under which demand, to whom, and when. What the recipient keeps, and for how long, is the recipient's.

7Floors, ceilings, holds and conflicts

Floors and ceilings differ by jurisdiction, and many are conditional. A sample, as the LexLint law library holds them:

Jurisdiction	Instrument	What it asks of the record	In force
European Union	AI Act Arts. 19, 26(6)	High-risk systems: logs kept for a period appropriate to the purpose, at least six months, unless other Union or national law, such as data-protection law, provides otherwise	From 2 December 2027 (Annex III) or 2 August 2028 (Annex I)
European Union	GDPR Art. 5(1)(e)	Personal data kept in identifiable form no longer than necessary	Since 25 May 2018
India	CERT-In Directions, 2022	Logs of all ICT systems kept securely, within Indian jurisdiction, on a rolling 180 days; clocks synchronized to a named national source	Since 27 June 2022
India	AI Security Auditing Guidelines, s. 9.7 and s. 8.6 (guidance, read with the 2022 Directions)	An agent's execution chain logged and protected against unauthorized modification; an auditor checks the Directions' 180-day minimum	Guidance, dated 4 November 2026
India	DPDP Rules, 2025, Rules 6(1)(e), 8(3)	Logs and personal data kept at least one year from processing for named purposes, then erased unless another law requires more	From 13 May 2027
South Korea	PIPA Art. 29 and its decree and notice	An access record kept safely against forgery and alteration, at least one year, two years in named cases	Since 15 September 2023
Switzerland	Data Protection Ordinance Art. 4	In named high-risk cases, logs kept at least one year, separate from the processing system	Since 1 September 2023
Brazil	ANPD Resolution 15/2024	A record of every security incident, reported or not, kept at least five years	Since 26 April 2024
Brazil	LGPD	Personal data deleted once processing ends, unless kept for a legal or regulatory obligation or another named purpose	Since 18 September 2020
United States	HIPAA Security Rule, 45 CFR 164.316	Required documentation kept six years from creation or last effect	Since 20 April 2005

The paper Whose law was that? counts how widely such periods range across the law library (section 3.1). The point here is the shape: a floor, a ceiling, or both, attached to a jurisdiction reached through a particular party, often only in named cases. That is why the dates are computed per reading and per class (R1, R8), not once per system.

Holds. A legal hold suspends delete_by for the records it covers. The GDPR's own exceptions include processing needed "for the establishment, exercise or defence of legal claims" (Art. 17(3)(e), as the Regulation states it). A hold is an event in the chain, naming its scope, the authority for it and its reference. Before an epoch key is destroyed, the key service rewraps the held records' keys under a hold key that has no date. Releasing the hold is another event, and the released records return to the epoch their dates now give, which may be the next one due.

Conflicts. When a floor from one reading falls after a ceiling or a right to erasure from another, the record carries the conflict from the moment it is written, with the policy table's rule for that pair or unresolved. An unresolved conflict goes to a person within a stated time, and until then the record is findable as a conflict in production and audit. This proposal does not supply the rule; it makes sure that nobody discovers the conflict for the first time while a regulator is waiting.

Cross-border production. A demand from one jurisdiction for a record about a person in another meets the second jurisdiction's transfer rules. The GDPR moves personal data outside the EEA only on an adequacy decision, Standard Contractual Clauses with a transfer assessment, Binding Corporate Rules or a narrow derogation (Arts. 44 to 49), and its Art. 48, as the Regulation states it, recognizes a third country's court judgment or authority decision requiring a transfer only where it rests on an international agreement such as a mutual legal assistance treaty. A record kept in India under the CERT-In Directions, about a person in the EU, can be reached by both. The envelope's readings, location and demand show the overlap per record before any order arrives; deciding what to produce is counsel's.

8What the EDPB's reading of blockchains reaches, and what it does not

The European Data Protection Board adopted the final version of its Guidelines 02/2025 on processing of personal data through blockchain technologies on 7 July 2026 (version 2.0, after a consultation on version 1.1 of 8 April 2025). The Board issues guidelines under Art. 70(1)(e) of the GDPR; they are guidance, its reading of the Regulation, and are not law. They are read here from the Board's own copy, on 5 November 2026.

Their subject is the hard case. Three things make a public blockchain hard to reconcile with erasure: its data are replicated to parties no controller governs, nothing on it is ever deleted, and anyone can read it. Whether data identify someone turns on "all the means reasonably likely to be used", by the controller or by another person, with regard to cost, time, available technology and technological development (Recital 26, as the law library reads it), and on a public chain anyone has unlimited time to try. The guidelines themselves tie confidentiality to the type of chain, public or permissioned (para. 65). A private log under one operator's access control, with an end date for every entry, differs on all three counts, so their statements are not lifted onto it wholesale. Each layer of this design meets them to a different degree.

Layer	How far the guidelines' reasoning reaches	What the layer holds, and why
Public anchor	Directly: append-only, replicated, readable by anyone	Checkpoint digests of the chain only. Where single entries are registered, keyed commitments only, their secrets in the payload store (paras. 52 to 54)
Private chain	By analogy: append-only, but under the operator's control	Envelopes without personal data, and commitments whose secrets are in the payload store; never a ciphertext (para. 104)
Payload store under expiring keys	Least: deletable, access-controlled, dated	Ciphertext until `delete_by`; then the key is destroyed and the ciphertext deleted, so nothing rests on a cipher holding forever (paras. 51, 96)

Where the guidelines speak to a part of this design:

The guidelines say	Para.	What this proposal does
After the decryption key is deleted, encrypted data will be unintelligible "at least until the algorithm is broken, the decryption techniques advance sufficiently to allow the decryption of the cipher text, or if the key had already been compromised or leaked"; "encrypted personal data is still personal data"	51	No ciphertext in the chain. Payloads are deleted, and key destruction is the second line, for copies
"Even state-of-the-art encryption perfectly implemented will be overtaken by time" if kept indefinitely; "all encryption systems have an undetermined, but limited, lifespan", including against cryptanalytically relevant quantum computers	51, 96	Every payload has a `delete_by`; nothing is left as ciphertext to wait out its cipher
A salted or keyed hash, after deletion of the key or salt, "should not be linkable to the original data", provided the algorithm holds and the key or salt did not leak and was not poorly chosen; unsalted or unkeyed hashes are in general not enough	52	The commitment is keyed per record, and its secret is deleted with the payload
With a perfectly hiding commitment, once the original data and its witness are deleted, "it will be neither possible to recover nor to recognise the original personal data"	53	The preferred commitment
Personal data in "clear text, encrypted or hashed" form on a chain is "not advisable"; it "should be stored off-chain"	104	The three layers of section 2
Where data must be kept for less than the chain's life, "a technical solution should guarantee the appropriate data retention period", allowing deletion or, if applicable, anonymity; if none exists, "no personal data should be stored on the chain"	120	`delete_by` in every envelope, carried out by the key service and the store
Linking between a person's existing and future transactions, "with means reasonably likely to be used", should be prevented	64	Per-record identifiers; no persistent handle for a person in the envelope
On-chain metadata, event logs included, may be personal data	fn. 12	The envelope is assessed, not presumed clean (section 3)

Does destroying the key count as erasure, or make the data anonymous? The guidelines do not say it does. They say encrypted personal data is still personal data, and they describe key deletion only by its effect: the data are unintelligible for as long as the cryptography holds, which they also say is limited. For the operator the answer while the key exists is not in doubt: the law library reads the GDPR as treating pseudonymized data as personal data for whoever holds the additional information that attributes it, and the Court of Justice as allowing that it may not be for a recipient with no reasonable means to lift the measures (Art. 4(5), Recital 26 and Case C-413/23 P).

This design does not need the answer for afterwards, because it does not keep the ciphertext. Payloads are deleted at delete_by and their keys destroyed, and the only copies that rest on key destruction alone are backups and replicas that expire on a stated schedule. What persists is an envelope without personal data and a commitment whose secret is gone, which is the kind of residue the guidelines describe as no longer linkable: a commitment (para. 53), a keyed hash under stated conditions (para. 52), and data that can "be effectively rendered anonymous" by erasing what is held elsewhere (para. 103). Whether that residue is anonymous for a given record is the controller's determination with its counsel, and a supervisory authority may read a particular deployment differently.

9What the LexLint papers already ask

The LexLint handbook, the logging analysis and the papers already recommend most of what this design carries. Each row names the practice, where it is argued, what the paper says happens without it, and where this proposal carries it.

Practice	Argued in	Without it	Here
What to record
One record per consequential act, refusals included, no gaps	Logging: recommendations	No consequence stated	3, `act`
Which agent, which version, on whose delegation	Evidence, class 2	Almost nothing in force today will have said so	3, `actor`
Awareness recorded as a legal moment	Whose law was that?, 2.2	A record rebuilt after the fact leaves little of a 72-hour clock	3, `at`
Not everything logged	Whose law was that?, 3.1 and 4.4	A full copy of customer rows in a log is a second incident	2, content only in the payload store
Jurisdiction and party
One reading per party, never one country per act (R1)	Whose law was that?, 5	A single code looks as though it answers every party's question	3, `readings`
The result kept, never the signal (R3)	Logs, 3	A hashed IP address still carries the IP address	3
"Unknown" is a value (R4)	Logs, 4	A default country is how a wrong answer is made	3, 4
The crosswalk's version kept beside the reading	Logging: recommendations	Nobody can tell which answers went stale	3, `context`
Parties known when the act happens (R9)	Whose law was that?, 5 and 4.4	Incident response starts by asking what the record should have said	3, 4
Integrity
Hash-chained, signed, registered, by an independent recorder or at a declared trust level	Logging: recommendations	Weak evidence of its own contents; a record whose weight cannot be judged	2, the chain and the public anchor
Integrity is not enough by itself	Logs, 4	Tamper evidence makes a wrong answer harder to find	3, readings fixed as given
Retention and deletion
Retention, access and location settable per jurisdiction (R8)	Whose law was that?, 5 and 3.1	What to log has no single answer	3, `retention`, `location`, `demand`
Digests in the action record, content in a governed evidence store	Logging: recommendations; Whose law was that?, 4.5	A record that cannot be retracted is the wrong home for content	2, 5
The evidence store lives as long as the log needs it	Logging: jurisdiction signals	The auditor cannot check the record	6, each payload until its `delete_by`
Who holds and reads
A field for who may demand the record	Logging: recommendations (AI Act Art. 21(2))	No consequence stated	3, `demand`
Held apart from the processing system	Evidence, class 9 (Swiss DPO Art. 4)	No consequence stated	2, a separate store
Held in-country	Evidence, class 1 (CERT-In Directions)	No consequence stated	3, `location`
Reporting clocks
The jurisdiction answerable before an incident	Logs, 5	A reconstruction exercise under a statutory deadline	3, 7
Protocols and time limits for out-of-profile events	Declared, checked, held, 5.3	An alert nobody answers is a log, and a block nobody reviews is an outage	7, unresolved conflicts go to a person

Two tensions the papers name are settled here rather than chosen between. The logging analysis keeps content out of the record for privacy, while an auditor needs to trace what happened: here the content is kept, in the payload store, for exactly as long as its class allows. And the evidence document sets the content-out rule beside SAFE, the compact of the Open Secure AI Alliance, whose evidence list asks for prompts, tool results and files to be preserved: here those are payloads, preserved with an end date.

Most of the parts of this design already exist somewhere. What none of the works below does, read on the dates given, is put the three together: a date pair fixed per record from each party's jurisdiction, a deletable payload under keys that expire with it, and a signed record of each destruction in the chain. Each work is described by what its own current text says; a work that changes after the date given may say more.

Work	Read	What it shares with this design	Where it differs
IETF SCITT architecture (published as RFC 9943)	Working group text, 7 September 2026	An append-only log whose sequence "cannot be modified, deleted, or reordered": the public anchor of section 2	It registers whatever signed statement an issuer submits. Here only a checkpoint digest, or a keyed commitment, ever reaches it
COSE Receipts (RFC 9942)	Draft -18	A proof format a checkpoint can carry	None for this purpose
AgenTrust trace-registry	28 October 2026	An operating append-only Merkle log of signed claims, whose entries are not removable on request	Its leaves are digests of whole signed claims, which can name a subject

Work	Read	What it shares with this design	Where it differs
Checkpointed local log (IETF individual draft)	-02, 14 October 2026	A private append-only log of digests, of which only a signed checkpoint leaves; "Erasure of the content an entry commits to is a separate act on separate storage"	No retention dates, keys or holds
Agent Action Capsule (IETF individual draft)	-05, 27 September 2026	Identity kept out of the record entirely; a `retained_until` floor and a `not_retained_after` ceiling, the closest match to `keep_until` and `delete_by`	The dates are "declared, not attested". Here the key service's receipts attest that the ceiling was kept
Agent evidence layer (IETF individual draft)	-00, 5 October 2026	Payload commitments in a durable header, and a per-record `retention_state` that includes `DELETED` and `LEGAL_HOLD`	A state, with no dates, jurisdiction or keys
Agent evidence request and evidence bundle (IETF individual drafts)	-02, 31 October 2026 and 1 November 2026	The production side of section 6: a request, a signed refusal when a retention commitment has lapsed, and a bundle that shows each category's deletion state	Who may ask is out of their scope; here `demand` records it per record
Canonicalization and payload binding (IETF individual draft)	-06, 26 October 2026	A canonical form for what a record commits to	It leaves erasure tombstones to a companion profile; sections 5 and 6 are one such
Agent audit trail (IETF individual draft)	-09, 26 October 2026	A hash chain with signed tombstones for erased entries and stated retention periods	One jurisdiction value per record (R1), the principal's identifier in the chain, and a content fingerprint with no salt (section 5)
TRACE (AgenTrust), and the OWASP GovOps profile of it	TRACE v0.2 and the GovOps profile, 24 October 2026 to 28 October 2026	A signed record with a transparency proof, a per-producer chain, and a pointer to an applicability assessment held elsewhere; GovOps adds `geography`	The anchored unit is the whole signed record, which can carry a subject's identifier; the one retention field is an undertaking that "nothing in this specification enforces". `geography` is where a system runs, which matches `location` here, not the per-party `readings`
AgenTrust telemetry, cMCP and agent manifest	28 October 2026 to 30 October 2026	Metadata-only events; an audit chain inside an enclave; a manifest that commits an audit-chain root and names a minimum log retention, with guidance to keep private payloads apart from shareable commitments	No per-record dates, holds or deletion events. cMCP's own limitations note that payload hashes in its log can reveal predictable values
AAIF Observability and Traceability working group, use case E4	5 November 2026	A declared retention basis for each record, and a typed tombstone when an identifier is removed under policy	A basis rather than a date pair; no keys or holds
agentgateway	Configuration reference, 5 November 2026	A request log with a mode that keeps prompt and completion content out of the stored record	No chain or retention settings. A gateway is the component that holds the signals (R2), so it is where an envelope would be written

Work	Read	What it shares with this design	Where it differs
FINOS AI Governance Framework, mitigation MI-21, and the FSI agent card	3 November 2026 and 9 October 2026	Tamper-evident logging, retention periods per regulation, and records a competent authority can verify; the card declares retention days, permitted regions, legal basis and applicable regulations	Declared once per agent, not fixed per record; the card asks for a write-once audit trail
A legal context document, such as the Legal Context Schema the AAIF Governance, Risk and Regulatory Alignment working group has under discussion	Not yet published	States which constraints counsel approved for a deployment, including what to record and what to leave out	This proposal's retention policy table is the part of such a document that sets dates; `context` names its version
SAFE, the compact of the Open Secure AI Alliance	Version 1.0, 21 October 2026	A list of evidence its participants preserve	It states no retention period and no deletion rule; here every preserved item has both
OpenSSF Global Cyber Policy working group, its Cyber Resilience Act materials	10 October 2026	A retention floor (technical documentation kept at least 10 years) and records made available to competent authorities on request, of the kind sections 6 and 7 carry	Guidance on a law, not a record format
Agent Name Service	3 November 2026	A registry log, and trust-index entries that carry a jurisdiction	It records agent registrations, not agent work; a registry entry could supply a counterparty's establishment reading

Work	Read	What it shares with this design	Where it differs
Model Agentic AI Evidence and Black-Box Accountability Law, a draft model law by Pavan Duggal, offered for comment	Draft, 21 October 2026	An event record for each material autonomous action (s. 18); a legal hold under which "automated deletion or retention policies shall be appropriately suspended or modified" (s. 34); a chain of custody that runs to "destruction where legally permitted" (s. 31); and inferences against an entity required to preserve evidence that "failed to preserve or produce it without lawful justification" (s. 27)	It sets no retention period: a provider documents its "retention arrangements" (s. 59). Here each record carries its own dates, and a destruction on time is an event in the chain with its authority, so the reason a record is gone can be shown
Compromised, Hijacked and Defending Agents, a paper by Pavan Duggal	v0.1, 18 October 2026	A "minimum operational record" of nine fields, one of them "retention period and custodian", and a rebuttable presumption against a deployer that cannot produce it (section 4.5); each step of the response to a compromise recorded with "the time and reason for it" (section 4.4)	The presumption sets aside a record an attacker destroyed "despite reasonable preservation measures", and does not say how a record whose retention period ran out is treated. Here that record leaves a dated destruction event with the key service's receipt

Two neighbors of this proposal. The proposal Jurisdictional context carries each party's reading from hop to hop; this proposal records those readings as given and computes the record's dates from them, and adds nothing to the carrier. Per-subject encryption with key deletion, often called crypto-shredding, is widely used; this proposal uses it inside a retention structure, and not as the erasure itself (section 8).

11What this proposal does not do

It does not decide which law applies to a record, which period binds it, or how a conflict between periods resolves. The policy table is counsel's.
It does not make any deletion meet a law's requirements. It records what was destroyed, when, and on what authority.
It does not make the envelope anonymous by declaration. The envelope is designed to hold no personal data, and each deployment assesses whether it does.
It does not reach a copy already produced to someone else, or a copy made outside the payload store.
It does not replace a record of processing, an impact assessment, or a hold procedure; it gives each of them a record to point at.
It does not name a cipher, a key manager or a log product. Those are profiles (open question 3).

12Requirements met

The requirements are stated in the paper Whose law was that?, not here. Each number below links to its statement.

Requirement	How this proposal meets it	What it leaves to someone else
R1	Dates are computed from each party's reading, and the envelope keeps every reading (3, 4).	Which law reaches each party and which period binds. The policy table is counsel's (11).
R2	The envelope is written at the act, by the component that took it, and never rewritten (3).	The check that makes a reading.
R3	The envelope holds readings; no IP address, location or digest of either (3).	How coarse a reading must be before it stops singling anyone out (open question 4).
R4	An unknown reading takes the class the policy names for it (3, 4).	Which class that is, which the policy table sets.
R5	The payload store and the envelope's commitment (2, 5).	Who may see the evidence, and the store's own access rules.
R6	The actor field carries the delegation chain; each subagent's act is its own record under the same work (3).	The delegation chain itself, written by the framework that starts the subagents.
R7	Readings are copied as the work carried them in (4).	Carrying them from hop to hop, which is the proposal Jurisdictional context (10).
R8	The retention, demand and location fields, per record, from the readings (3, 7).	The values themselves, which the policy table sets.
R9	The dates, the location and any conflict are fixed at write time (3, 4, 7).	What the parties were, which comes from whoever made each reading.

13Open questions

Epoch length. One day per class gives precise dates and many keys; a week gives fewer keys and earlier destruction. What length should a profile set?
The default for an unresolved conflict. Until a person decides, does the record keep its payload (favoring the floor) or lose it (favoring the ceiling)? This draft leaves it to the policy table and asks for a stated time to decide.
Profiles. A keyed hash (HMAC) is common and cheap; a perfectly hiding commitment is what paragraph 53 of the EDPB's guidelines describes. Which should a profile require, and with which ciphers and key sizes against the longest periods in section 7?
Coarseness. How coarse must a reading be before an envelope with a time and an act stops singling anyone out in a small jurisdiction?
Bindings. How the envelope maps onto the works in section 10: as a SCITT signed statement carrying only digests, as a TRACE record with the subject left out of what is anchored, as the Agent Action Capsule's retention fields with attestation added, as the evidence layer's retention_state with dates added, and as a log record in an observability pipeline.
Produced copies. Should a production export carry its own delete_by, and how would a recipient be asked to honor it?
Requirements. Three ideas this design relies on are stated in no paper as requirements: the record's dates are decided at write time; deleting content leaves the record verifiable; a destruction is itself evidence. Should they be?

14Status, how to take part, and disclosure

Status: Draft 1, 5 November 2026. Not yet before any standards body.
Comments: open@lexlint.io. There is no repository yet; one is opened the day a second organization wants to edit the text.
License: Creative Commons Attribution 4.0. Adopt it, fork it or improve it, with credit, without asking.
Disclosure: LexLint publishes a law library that could be one source of a retention policy table. The proposal assumes no product, and any source of counsel-approved dates will do.

About this proposalDraft 1, 7 November 2026ShowHide

Proposed by LexLint; written by Sean McDermott, Co-Founder and CEO, with AI assistance.

Draft 1 sets out the layers of the record, how it is written, how it expires and is erased, what can be shown afterwards, and how far the European Data Protection Board's reading of blockchains reaches each layer, and it puts seven questions to readers. It relies on the requirements the paper Whose law was that? states, and on the proposal Jurisdictional context for how a reading travels.

© 2026 UnGovr, publishing as LexLint. This proposal, its text and its figure, is licensed under Creative Commons Attribution 4.0: adopt it, adapt it, translate it, carry it into another document or a standards body, including commercially, with credit to LexLint (UnGovr). Logos and wordmarks belong to their owners.