Heatrail
Sign in Create account

Chapter 11

Forgetting on schedule

Most retention commitments are sentences. They describe an intention, and they are true the way a resolution is true. This article is about the other kind, a command on a schedule, and then the two questions a careful reader asks next: what happens to what the system inferred, and how a history that is never deleted sits alongside data that is.

The property

Signal data is deleted after 90 days by a scheduled job, and so are the graph nodes and edges that only those records supported. Records tied to an active fraud or chargeback incident are held as evidence while the incident is active, and a reversed label stops protecting them. The ledger keeps its integrity proof while the personal data it referenced is gone.

Why it holds

A command, not a paragraph

A policy statement and a scheduled job are different kinds of object, and the distance between them is the distance between a promise and a mechanism. A policy has to be remembered and applied by somebody, and it quietly stops being true the first quarter nobody gets to it. A job runs at a fixed hour whether anyone is thinking about it or not, and it deletes rows.

Heatrail's nightly purge runs at 03:30 UTC and deletes the signal records that have passed the retention window. The categories it covers, and the window for each, are on the trust page. What makes that checkable is not the quality of the description. A scheduled command either exists on the schedule or it does not, and a shop can ask to see the entry.

What was inferred leaves with what was received

A record deleted on its own would leave a shadow. Checks do not only accumulate records, they build structure: traits that appeared together in confirmed harm stay linked, and it is that structure a later check reads. If the records expired and the structure they created stayed, the limit would reach what was received and not what was inferred.

So the purge deletes both. When every record supporting a node or an edge has passed the window, that node and that edge go with them, and what survives is what other, unexpired records still support. A summary of nothing is nothing.

One inferred thing keeps a separate clock, and it is published rather than folded into this one. Heat a confirmed fraud or chargeback label created counts towards a score for up to 400 days, at full weight for the first 90 and then falling to a third by day 365 (heat, and what cools it). The signal records and the graph structure still leave at ninety days.

The exception, stated narrowly

There is one exception, and its edges matter more than its existence. A record tied to an active fraud or chargeback incident is held past the window, because it is evidence for a claim that is live. Three things bound it.

The hold attaches per incident rather than per category: it covers the records one active incident rests on, and the weighing that justifies keeping them is recorded at the time rather than assumed.

A real label creates no exception at all. A shop marking an order legitimate extends nothing and holds nothing. Only the two labels that assert harm can keep a record past the window, which ties the exception to the thing that justifies it.

And a reversal ends it. The incident stops being active, the hold falls away, and the ordinary window resumes. A correction is not a note appended to a file that stays open anyway. It restores the normal course, and the record it had been protecting then leaves on the ordinary schedule like any other.

Figure 1

An ordinary record ends at day 90, an active incident holds one past it, a reversal pulls the hold back, and the ledger runs on unbroken.A horizontal timeline runs left to right with two dashed vertical guides, one marked day 0 and one marked day 90. In the first lane a solid bar labelled signal data for one order starts at day 0 and breaks into blocks that grow fainter until it has disappeared at day 90. In the second lane a solid bar runs from day 0 to day 90 and continues past it as a heat coloured band labelled incident active. A heat coloured mark further right is labelled label reversed, and a heat coloured arrow runs from that mark leftwards back to the day 90 guide. In the third lane a thin sunken bar labelled ledger and audit log runs unbroken from day 0 past day 90 to the right edge of the drawing, carrying a short hash prefix in a monospace face and nothing else.day 0day 90A record with no active incidentsignal data for one orderGone at the window, and with it the graph nodes and edges that only this record supported.A record tied to an active incidentsignal data for one orderincident activelabel reversedThe reversal ends the hold, the ordinary window resumes, and the record leaves on the ordinary schedule.Ledger and audit log9f2c1b…identifiers, hash prefixes, order references, event metadataThe proof runs on past the window because it never held the data it points at.
The window is a schedule rather than a policy. An active incident extends it, a reversal shortens it back, and the proof outlives the data because it never contained it.

How immutable history and deletion are both true

This is the point a careful reader tests, so it gets the space. The ledger and the audit log are append-only, and they are also the two tables the purge never touches. The question is how a history that is never deleted lives in the same system as a commitment to delete personal data on a schedule.

The answer is what those tables contain, and it works only because the decision was made in advance. They carry identifiers, hash prefixes, keyed digests of order references and event metadata: that a check happened at a moment, that a label was applied and later reversed, the chain value binding each entry to the last. They do not carry the hashed contact values, the network address, the device characteristics or the order characteristics. Those live in the signal records, and the signal records are what the purge deletes.

Proof and data are therefore separate objects with separate lifetimes. After the window, the history still shows that an event occurred, in what order, and that nothing in the chain has been altered since. What it can no longer show is anything about the person the event concerned, because those rows are gone and the history never held a copy. The proof outlives the data because it never contained it.

How it is verified

The purge is a command registered on the nightly schedule. A test suite ages records artificially and asserts that they, and the graph structure only they supported, are gone after the window.

Requests from people follow the same route, and it is a short one. A data subject request reaches Heatrail through the shop, because the shop is the controller and we are the processor. A person who writes to us directly is not turned away: they are told in writing to route the request through the shop, and the shop is notified the same day. Heatrail then assists, and the decision belongs to the shop. The procedure is written down and carried out by an operator, which is what makes every step of it attributable afterwards.

Verify it

Two published pages describe the same schedule to two different readers, and comparing them is the check. The trust page lists each category with the window that applies to it, in the form a procurement questionnaire asks for, and names the nightly purge. The disclosure page says the same thing in the words a shopper reads:

curl -s https://api.heatrail.eu/disclosure

Read them side by side. Neither needs an account, and both name the same windows for the same categories.

Then ask for the schedule entry. A shop under an agreement can ask to be shown that the purge is registered as a command rather than described as a practice.

Storage limitation, Article 5(1)(e) GDPR, implemented as a scheduled job rather than as a policy statement, the only form of it that can be shown rather than asserted. The evidence exception is Article 17(3)(e), the establishment, exercise or defence of legal claims, applied per active incident with the weighing recorded rather than assumed for a class of records. Deleting the graph structure that only expired records supported is what makes the limitation reach derived data as well as received data. Erasure under Article 17 and rectification under Article 16 are exercised through the shop as controller, with Heatrail OÜ acting as processor under Article 28 and assisting under Article 28(3)(e). See what we hold and for how long and the data processing agreement.

Heatrail

This site is not public yet

Heatrail is in a private pre-launch period. Enter the access password to continue.

Enquiries: hello@heatrail.eu