Use Case · Compliance

Data retention on the Software Lifecycle Cloud

Data retention on KERNSTACK turns deletion and freezing duties into declared mechanics: every subject-related table carries the fields that govern a record’s life — subject id, retention date, hold flag — a scheduled workflow finds records whose time has come, deletes or anonymises them, and writes a proof entry for every action. A subject access or erasure request becomes a query plus a job, not an excavation.

NoSQL TablesContainer WorkersApproval WorkflowsObject Buckets
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Privacy leads must delete or freeze a subject’s data on request and discover nobody can enumerate where that subject’s data lives: three tables, a bucket of uploads, an export somebody emailed in March. The request’s deadline does not care. Teams respond with heroic manual searches that cannot be repeated for the next request and cannot be proven afterwards.

Architecture on the Software Lifecycle Cloud

The discipline is declared per table at design time: which field identifies the subject, which date ends retention, which flag freezes instead of deletes. The retention workflow walks those declarations on schedule and on demand for a named subject, acting identically in both cases — delete from tables, delete or anonymise bucket objects, and log subject, scope, and timestamp into a proof table that itself contains no personal payload.

Freezing is a state, not an exception

Legal holds and disputes mean some records must stop ageing without disappearing. Because hold is a field, the same job that deletes a million expired rows skips the frozen thousand and says so in its log. The privacy lead’s answer to “is this subject frozen everywhere?” is a query over flags, not a round of emails to service owners.

  • Erasure for a named subject and nightly expiry are the same code path with different scope
  • Proof entries record what was deleted, when, and under which request — without retaining the deleted content
  • Bucket objects follow the same subject fields, so uploads stop being the forgotten copy

The design-time price

This only works for tables designed with subject fields from the start; legacy data without them needs a backfill before the job can see it. That backfill is real work and this page will not minimise it — it is also one-time, while manual request handling is forever.

FAQ

Frequently asked questions

Run the retention workflow scoped to the subject id: it deletes or anonymises the subject’s rows and objects across every table that declared a subject field, then writes the proof entry. The requester gets the proof entry, not a promise.

Exports inside the project live in buckets the same subject scan covers. Anything that left the project — an emailed spreadsheet — is outside any platform’s reach, which is an argument for keeping exports as expiring bucket links instead.

Yes. Retention dates live on the records and rules live per table: invoices keep their statutory years, support attachments expire in months, frozen subjects override both. The workflow enforces the per-table declaration uniformly.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · DataTablesServerless key-value and document tablesService · ComputeWorkersContainer workers for long jobsService · OrchestrationWorkflowsDurable workflows with human pausesService · DataBucketsObject storage with presigned uploadIndustry SolutionHealthTech Cloud SolutionsHealthTech products on KERNSTACK hold care-adjacent data — patient documents, encounter records, consent forms — in one declared project in a European zone on named infrastructure. The needs that dominate are unglamorous and absolute: know exactly where every document lives, who touched it, how consent was captured, and how a record can be frozen the day a legal hold arrives.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →