Every behavioral field should expire by default

I think every behavioral-data field should carry an explicit retention deadline in its schema: purpose, owner, collection time, TTL, downstream stores, and what happens to derived values. A CI check should reject fields without one, while storage policies enforce it at runtime. Retention should be treated more like a security requirement than a sentence in a privacy policy.

Recommendation events, analytics SDK data, and account activity often start as “useful later” and quietly become a permanent profile. A delete button may remove the primary record without proving that features, warehouse copies, backups, or training snapshots are gone. Real expiry mechanisms already exist: TTLs and object-lifecycle rules can delete data automatically, with logs for the event. Debugging and model training need exceptions, but those should be narrow, approved, access-controlled, and dated. Would teams actually accept this discipline, or would it make diagnosis and experimentation too painful?

The CI part is the strongest proposal. Runtime deletion alone is easy to miss in one replica, export job, or versioned bucket. I’d require the schema to name every downstream sink, then make the pipeline fail closed when a sink has no expiry policy. Not glamorous, but neither is chasing stale data through six systems.

The distinction between policy and mechanism matters. Storage limitation is an established privacy principle, but there is no universal retention period for every field. A deadline in metadata would not solve every deletion problem, yet it would make the organization’s claim testable rather than merely aspirational.

I’m sympathetic, though product teams will ask what “behavioral data” includes. A recommendation impression, a support note, and a fraud signal have very different useful lives. The answer probably isn’t one global TTL; it’s making the tradeoff explicit before collection instead of after the profile has accreted.

Exceptions need an expiry too. Otherwise “incident investigation” becomes a permanent bypass with a respectable label. I’d want the exception owner, reason, access list, and end date recorded, plus an alert before it lapses. That is the retention equivalent of rotating an emergency credential.

The nasty implementation detail is derived data. Deleting the clickstream does not automatically tell a feature store, warehouse aggregate, or model artifact to forget its contribution. TTLs help, but each layer needs a deletion contract. Otherwise the button is mostly a UI promise.

I’m not convinced every field belongs in CI. Some deadlines depend on legal holds, active disputes, or an incident that is still being reconstructed. A hard build failure could encourage teams to choose absurdly long defaults. Maybe CI should enforce a documented decision and expiration, not insist on a particular number.

For debugging, a separate diagnostic retention class seems workable: limited fields, limited access, short approval window, automatic cleanup, and an audit trail. The important thing is not pretending production telemetry is harmless just because engineers might need it someday.

“Useful later” is how software acquires a memory it never planned to maintain. Give the data a birthday and a retirement date. If the team cannot explain who renews that date, the field probably should not be permanent.