Deletion and Data-Retention Posture: A Proposed Axis for What an AI Builder's Generated App Actually Removes (August 2026)

Quick answer (August 2026). Deletion and data-retention posture measures what an AI app builder's generated application actually does when a record, or a whole account, is removed. It is a proposed BuilderProof axis, drafted August 27, 2026, scoring six weighted signals read from the emitted schema and the emitted delete path: declared referential semantics, identity-deletion completeness, retention-aware exemptions, soft-delete coherence, third-party fan-out, and residue disclosure. This page is a pre-registration. No builder has been scored against it, and no placements are published here.

Every builder in this cohort will give you a delete button in one prompt. The row disappears from the list, the toast confirms it, the demo works. The interesting question is what else was supposed to go with it, what was legally supposed to stay, and whether anyone can tell the difference by reading the output.

Why we are proposing this axis

Deletion is the only operation in a generated application that is simultaneously a data-integrity problem, a legal obligation, and an irreversible action. Most axes measure whether something works. This one measures whether something stops existing, which is a much harder property to observe and a much easier one to fake.

Searching for prior work returns the same two disconnected literatures we found when scoping the upload path. One is general engineering guidance on building GDPR deletion pipelines, written for teams with a data map and a retention schedule. The other is AI-builder comparison content scoring speed, price and looks. We found no reproducible, tool-by-tool measurement of the deletion path these tools actually emit, and no rubric that treats a delete button as a scoreable artifact.

There is a second reason, and it is specific to this cohort. The platform layer has largely converged on the correct primitive and documents it plainly.

Supabase's own guidance for tables that reference an authenticated user tells you to "Specify on delete cascade in the reference", and shows it: id uuid not null references auth.users on delete cascade. It also fences the practice, warning that you should "Only use primary keys as foreign key references for schemas and tables like auth.users which are managed by Supabase", because "Primary keys are guaranteed not to change" while other database objects "may change at any time" (Supabase, Managing User Data, 2026).

So the primitive exists, it is documented, and it is one clause long. That is exactly why the axis is worth building. When the correct answer is a single clause, the question stops being whether the platform can do it and becomes whether the generated schema wrote it, wrote it on every relation, and wrote it on the relations where it is the wrong answer.

What "deletion and data-retention posture" means here

The scope is narrow on purpose, and three fences keep it honest.

It is read from the untouched output, at the moment of generation. Not after a human adds a retention schedule, and not from a vendor's compliance page. If the emitted schema leaves every foreign key at its default action, that is the posture, whatever the documentation says is possible.

It covers rows, identity and declared residue, not stored objects. Binary objects have their own trust boundary and their own axis. We score whether the emitted delete path is coherent across the relational schema, the authentication record and the external services the app writes to. Where storage appears below, it appears only because it can block a deletion, not because we are scoring the bucket.

It scores declared behaviour, not verified absence. Nobody can prove from the outside that a byte is gone from every replica. What is checkable is whether the emitted application makes a claim about what survives, and whether that claim is consistent with the platform's documented behaviour. An app that says nothing scores lower than an app that says "this is kept for thirty days", even though the second one deletes less.

The proposed rubric

Six signals, each anchored to published documentation or published law, each independently checkable. The weights are a starting point for community revision, not a settled formula.

Declared referential semantics carries the most weight because its failure is unbounded in both directions at once. A schema that cascades nothing accumulates orphan rows that keep referring to a person who asked to be forgotten. A schema that cascades everything destroys records the operator is required to produce on demand. Both are silent, and neither is visible in the interface.

Residue disclosure carries the least weight because its consequence is a documentation defect rather than a data defect. It is on the list because it is the only signal a reader of the generated app can check without a database, and because it is the signal most reliably absent.

The four posture levels

For legibility, the weighted score maps to one of four levels.

Level 0, no exit. There is no deletion path in the generated application. Removing a person means someone opens the database console.

Level 1, local delete. A delete removes the row it was pointed at. Child rows, the authentication record, and every external service the app wrote to are unhandled. This is the level a working demo produces.

Level 2, coherent local erasure. Foreign key actions are declared per relation rather than left at the default, the authentication record goes with the profile, and if soft delete is used it is applied consistently to queries, constraints and re-registration. The delete path has been exercised by a second account.

Level 3, declared and bounded. Level 2 plus retention exemptions honoured for records under an independent duty, propagation to external services with the semantics stated, and a written statement of what survives and for how long.

Cascade is the right answer to one duty and the wrong answer to another

This is the tension the axis is really built around, and we have not seen it stated for this cohort.

PostgreSQL documents the choice precisely. The default is not deletion and it is not protection, it is failure: "The default ON DELETE action is ON DELETE NO ACTION; this does not need to be specified. This means that the deletion in the referenced table is allowed to proceed. But the foreign-key constraint is still required to be satisfied, so this operation will usually result in an error." Against that, "CASCADE specifies that when a referenced row is deleted, row(s) referencing it should be automatically deleted as well", while RESTRICT "prevents deletion of a referenced row" and, unlike NO ACTION, "does not allow the check to be deferred until later in the transaction" (PostgreSQL, Constraints, 2026).

Now put the legal duty next to it. The right to erasure is not open-ended. Article 17(1) gives a data subject "the right to obtain from the controller the erasure of personal data concerning him or her without undue delay". Article 17(3) then removes that right in named cases: "Paragraphs 1 and 2 shall not apply to the extent that processing is necessary", including "for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject", and "for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes" (GDPR, Article 17, Right to erasure).

Those two documents describe one schema and two incompatible instructions for it. Invoices, tax records and payment history are exactly the rows a controller commonly must keep, and they are also, in almost every generated schema we have read the shape of, direct children of the user row. A blanket on delete cascade from auth.users is therefore not a safe default. It is a correct answer to orphaning and a wrong answer to retention, applied uniformly to relations that need opposite treatment.

This is why the rubric does not score the presence of the word cascade. It scores whether the action was chosen per relation. A schema with cascade on session tokens and preferences, restrict or a nulled tenant reference on invoices, and a documented reason for the split, is doing the actual work. A schema with cascade on all fourteen relations has typed one clause fourteen times, and a schema with none has typed it zero times. The two failures look nothing alike and score the same, because neither one made a decision.

The storage layer can veto the erasure path

The second signal has a failure mode on this stack that turns a deletion path from incomplete into non-functional, and it arrives through a door nobody opens deliberately.

Supabase's user-data guidance carries a plain caution: "You cannot delete a user if they are the owner of any objects in Supabase Storage", and states the consequence directly, that "You will encounter an error when you try to delete an Auth user that owns any Storage objects" (Supabase, Managing User Data, 2026).

Compose that with the observation from our file-upload and media-handling axis, that every builder in the cohort will wire up an avatar picker in a single prompt. The composition is the finding: adding a profile picture to a generated application can convert a working account-deletion path into one that throws. Not degrade it, not leave residue. Throw. And the two features are typically requested weeks apart, by different prompts, with no reason for anyone to connect them.

That axis and this one meet at the same seam from opposite sides. It asks whether the object survives the row. This one asks whether the object prevents the row from going. A build can fail both, and the first failure is what causes the second, because an object with no emitted cleanup is an object that is still owned when the erasure request arrives.

Soft delete quietly converts a unique constraint into a permanent lockout

The fourth signal is where a reasonable instinct produces a defect that is invisible for months.

Soft delete is often the correct design. It preserves audit trails, it makes accidental deletion recoverable, and it is the honest way to keep records that Article 17(3) exempts while still removing them from the product. The problem is that it is half a change, and generated code reliably ships the half that is visible.

Adding a deleted_at column changes the meaning of every query, every uniqueness rule and the sign-up path, all at once. The queries are usually noticed, because a deleted row reappearing in a list is a visible bug that shows up on the first test. Uniqueness is not noticed, because its failure needs a sequence nobody performs during development.

Consider a users table with a plain unique index on email and a deleted_at column. A person deletes their account. The row stays, retaining the address. They come back a month later and sign up again with the same email, and the insert violates the unique index. The emitted handler, which was written for a form-validation failure rather than a database constraint, surfaces it as a generic server error. The person is now permanently unable to use the product with their own email address, and the operator has no signal that this is happening, because from the server's perspective it is a duplicate-key error on a sign-up attempt, which is what an ordinary already-registered user also produces.

PostgreSQL documents the fix, and it is not obscure. A partial index "is an index built over a subset of a table; the subset is defined by a conditional expression", and the docs name this exact use: "The idea here is to create a unique index over a subset of a table... This enforces uniqueness among the rows that satisfy the index predicate, without constraining those that do not" (PostgreSQL, Partial Indexes, 2026). A unique index on email predicated on deleted_at is null restores the intended rule. It is one line, and we have not yet seen it emitted by default.

Why the delete path is structurally under-tested

It is worth naming the mechanism, because it is not carelessness and it is different from the ones we have named on other axes.

On the upload path we described a predicate that is correct in form, checks the wrong thing, and is indistinguishable from the correct predicate when there is only one account. On the sending path we described a tested population and a failing population that do not overlap. This is a third mechanism: the action is destructive, so the developer cannot afford to run it on the only account that exists.

Deleting your own account during development locks you out of the application you are building. So the delete button gets clicked once, on a throwaway row in a list, and the account-level path, the cascade behaviour, the storage veto, the constraint interaction and the third-party fan-out are collectively exercised zero times before launch. The first full execution of the most irreversible code path in the application is performed by a real person on real data. No amount of iteration on the happy path moves this, because the happy path and this path share no code.

The fan-out is destructive in one direction and incomplete in the other

The fifth signal covers the services a generated app writes to that are not its own database, and here the correct behaviour is genuinely ambiguous rather than merely unimplemented.

Stripe documents its customer deletion in three clauses that pull in different directions. It "Permanently deletes a customer. It cannot be undone. Also immediately cancels any active subscriptions on the customer." And then: "Unlike other objects, deleted customers can still be retrieved through the API in order to be able to track their history. Deleting customers removes all credit card details and prevents any further operations to be performed" (Stripe, Delete a customer, 2026).

Read that against the two flows a generated app usually conflates. A "deactivate my account" flow that calls this endpoint has just irreversibly cancelled a paying subscription, which is not what deactivation means anywhere. An "erase my data" flow that calls it has removed the card details and left a retrievable object bearing the person's history, which is defensible under Article 17(3)(b) and is not the same thing as erasure, and the app almost never says which one it is claiming.

The far more common failure is neither. It is a delete path that never contacts Stripe at all, leaving an active subscription attached to a customer whose local account no longer exists. The person cannot log in to cancel, the operator sees a charge against an unresolvable user, and the first report arrives as a chargeback. The axis therefore scores whether the emitted delete path touches the external services the emitted app created records in, and whether the semantics of that call are stated. It deliberately does not score a particular choice, because deactivation and erasure genuinely warrant different calls.

A delete is not an erasure while the history window can reconstruct it

The sixth signal exists because the honest answer to "is it gone" is a duration, and generated applications never state one.

Neon documents a retained change history that instant restore reads from: "Neon retains a history of changes for your branches, with defaults of 6 hours on Free plan and 1 day on paid plans", configurable "up to 7 days on Launch or 30 days on Scale plans", governed by a project-wide history window that "controls how long that change history is retained, which sets how far back instant restore and the other features can reach" (Neon, Instant restore, 2026).

This is a good feature and the axis does not penalise it. What it means is that a committed DELETE is reversible for a documented period, which sits directly against Article 17(2)'s language about controllers taking reasonable steps to inform others of a request for the erasure of "any links to, or copy or replication of, those personal data". The row is gone from the query and reconstructable from the history for somewhere between six hours and thirty days, depending on a billing plan the generated application has no knowledge of.

We are not proposing that a benchmark require builders to purge backups. That would be an unreasonable ask and a dishonest signal, because no entrant could pass it and a signal everyone fails measures nothing. What is reasonable, cheap and currently near-universal in its absence is a statement: the generated app or its generated documentation naming the window, so that a person who asks to be erased is told when erasure completes rather than told that it already has.

The cost that shows up later

One measurement worth recording even though it did not earn its own signal, because it cuts across the first one.

PostgreSQL is explicit that a cascade is not free and that the obvious index is not created for you: "Since a DELETE of a row from the referenced table or an UPDATE of a referenced column will require a scan of the referencing table for rows matching the old value, it is often a good idea to index the referencing columns too. Because this is not always needed, and there are many choices available on how to index, the declaration of a foreign key constraint does not automatically create an index on the referencing columns" (PostgreSQL, Constraints, 2026).

So a generated schema that does the right thing on signal one, declaring cascades across a dozen relations, and does not index those referencing columns, has produced a correct delete that scans every child table once per parent row removed. On the ten rows in a demo this is instant. It is also the shape of a statement that gets slower in proportion to how successful the application becomes. We record it under signal one's evidence rather than scoring it separately, because a rubric that rewards declaring the action and ignores the cost of executing it is measuring intent rather than output.

How to reproduce it

The protocol is deliberately boring. That is the point.

1. Generate a fixed reference app from the standard prompt suite, one generation per builder, no manual edits. The reference prompt asks for accounts, a parent-child relationship, one billed item and a profile picture, described as product features, and never mentions deletion, retention or compliance.
2. Export the emitted schema verbatim. Record every foreign key and its declared ON DELETE action, and record which of those actions were written explicitly against which were left at the default.
3. Record whether any referencing column carries an index, per relation.
4. Locate every emitted delete path: the row-level delete, any account-level delete, and any administrative delete. Record which of the three exist.
5. Create a second account, populate it with a child row, a billed item and an uploaded avatar, then execute the account-level delete as that account. This is the step that separates level 1 from level 2, and it is the step a builder's own workflow will never perform, because performing it on the only account destroys the development environment. It is the most important instruction in this protocol.
6. After the delete, query for: child rows referencing the removed parent, the authentication record, the uploaded object, and the external customer record. Record what survived and whether the delete reported success.
7. Attempt to sign up again with the same email address. Record the status and the exact error surfaced to the user.
8. Search the emitted application and any generated documentation for a statement of what deletion removes and what it retains, and record the statement verbatim or record its absence.
9. Publish the full schema extract, the request and response log and the survival table next to the score, so the arithmetic is auditable, in line with our reproducibility-first methodology.

Fairness guardrail. A tool that emits front-end components only has no schema and no delete path, and a tool with no authentication has no identity record to remove. Those are recorded as out of scope for the signals that presuppose them, not scored as zero. Scoring absence as failure is how a rubric quietly punishes a product for being a different kind of product.

A second guardrail, specific to this axis. Retention-aware exemptions must be scored against what the generated app's own domain implies, not against a jurisdiction we pick. A note-taking app has no invoices and no retention duty, and a schema that cascades everything from the user row may be entirely correct for it. The signal asks whether records with an independent duty were treated differently, and it is not applicable where no such records exist.

Why we are naming a pattern and not publishing placements

In August 2026 this lab withdrew its June output-quality result set and the composite that depended on it, because the underlying runs could not be reproduced from retained evidence. That withdrawal has a consequence we intend to honour consistently.

An axis proposal is a pre-registration, not a report. The rubric above has not been executed. No builder has been assigned a level. No score exists. Where this page describes cohort behaviour it describes a pattern that vendor documentation makes possible, never a measurement of who does what. A reader should not infer from the specificity of the protocol that a run has happened. It has not.

How this relates to our existing axes

This axis is adjacent to published work, and we want the boundaries stated rather than assumed.

It is not our file-upload and media-handling work. That axis scores the upload path and includes lifecycle coupling, whether an object outlives the row that owned it, at a small weight. This one starts one step later and asks the inverse question, whether the object blocks the row from being removed at all, and it does not score bucket policy, content verification or serving posture.

It is not our concurrent-write-safety work. That axis asks whether two overlapping writes preserve both intentions, and it mentions foreign keys that cascade in passing as one shape of schema-level integrity. This one is not about interleaving. A delete path can be perfectly serialised, transactional and race-free, and still leave an authentication record and a live subscription behind.

It is not our input-validation and data-integrity work. That axis asks whether an emitted write endpoint rejects a malformed body at the server boundary. Deletion has almost no payload to validate. Its failures are in the schema and in what the path forgets to call, not in what it accepted.

It is not our database-migration and schema-change-safety work. That axis is about changing the shape of the data while the application runs. This one takes the shape as given and asks what the shape does when a row leaves.

It is not our rollback-safety work. Rollback is about reverting a deployment. The history window discussed above is a database-level recovery mechanism that happens to be the reason a deletion is not final, which is a different property of a different layer.

Limitations and open questions

• Single-generation variance. One export is one sample. A builder that is inconsistent between generations needs a multi-run design before scoring is fair.
• Prompt sensitivity. A prompt mentioning GDPR or account deletion would measure instruction-following rather than default posture. The reference prompt describes features only, deliberately. It also means the axis measures what a builder does when nobody asks, which is the interesting case and not the only one worth measuring.
• Jurisdiction. The retention signal is anchored to Article 17 because it is published, stable and specific. That is a European anchor on a global cohort, and a reasoned argument for scoring against a different or a plural standard would change the signal. We would rather have that argument now.
• Declared versus actual. Signal six scores a statement. A builder could earn it with an accurate sentence and delete nothing, and the rubric would reward the honesty. We think that is the correct trade for a documentation-derived axis, and we accept that it is arguable.
• Weight subjectivity. The 25/20/15/15/15/10 split is a proposal. A reasoned case that third-party fan-out should outweigh identity-deletion completeness, on the grounds that one costs money and the other costs a login, would change the ranking, and we would rather have it before scores exist than after.
• Anonymisation is deliberately unscored. Replacing personal data with a pseudonym in place is a legitimate alternative to deletion and, done properly, a better one for referential integrity. We left it out because no builder in the cohort documents it and a signal on which every entrant scores zero makes a total look more thorough than it is. If that changes, it should be added.

Comments, counter-rubrics and reproduction attempts are welcome. A run of this protocol that contradicts what this page predicts is the single most useful thing you can send us. So is a reasoned argument that a signal here is wrongly weighted, or wrongly present.

BuilderProof Editorial Team. "Deletion and Data-Retention Posture: A Proposed Axis for What an AI Builder's Generated App Actually Removes (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/deletion-data-retention-posture-axis-proposal-august-2026.

@misc{builderproof-deletion-data-retention-posture-axis-proposal-august-2026,
  title  = {{Deletion and Data-Retention Posture: A Proposed Axis for What an AI Builder's Generated App Actually Removes (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/deletion-data-retention-posture-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}