Retention is an operational control

What the public implementation shows

Guevara includes scheduled cleanup workers for transaction retention and monitoring history rather than leaving growth to ad hoc database maintenance.

Retention decisions operate on typed platform records under application scheduling and configuration. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleData removal is safe only when operational, financial, and investigative needs have been resolved first.

The decision behind the mechanism

Dedicated workers make removal criteria, timing, batching, and failure visible to the same operational environment that created the data.

Unbounded retention degrades cost and performance; aggressive deletion can destroy settlement, incident, or participant evidence. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Define retention by record purpose and authority.
• Exclude unresolved financial and investigative records.
• Delete in bounded, observable batches.
• Record run counts, failures, and next schedule.

How the control should be operated

Each record class needs an approved retention period, legal or institutional basis, archive rule, deletion batch size, and observable run result.

The platform can control storage growth without turning cleanup into invisible evidence loss. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.