In AT Protocol, a record is a schema-defined data object stored in an account's repository. A mutable ATProto record can change its contents while keeping the same stable record address, called an AT URI.
If an ATProto application has approved or admitted that record, an edit raises a policy question: does the old approval apply to the new contents?
This page belongs to the wiki's AT Protocol section. It examines the question in the specific setting of Nick Gerakines's proposed ATProto forum design, where a forum-owned wrapper admits a member-owned post. The underlying permissioned-data protocol is still a draft, and the approval policies discussed here are application choices rather than protocol rules.
ATProto makes the version problem explicit because a record has both a stable address and a fingerprint of its exact contents. This page explains those identifiers, three possible approval policies, and the edge cases an ATProto implementation should test.
Address versus version
An AT URI is the address of a record in an ATProto repository. The author can update the record while keeping the same URI.
A CID, or content identifier, is a fingerprint of the record's exact encoded contents. Change the record and the CID changes.
ATProto often combines them in a strong reference:
{
"uri": "at://did:plc:alice/community.example.review/3abc",
"cid": "bafy..."
}The URI means “Alice's review at this address.” The CID means “this exact version of Alice's review.”
For more detail on those identifiers, see ATProto Records and Provenance. The important point here is simply that the address can stay fixed while the version changes.
Hypothetical example: a forum edit
Imagine a moderated neighborhood forum:
- Alice publishes version A of a restaurant review.
- The forum creates an admission wrapper, a separate ATProto record that includes version A in its Restaurant Reviews category.
- Alice edits the review, producing version B at the same address.
- The service that assembles the forum displays the current record at Alice's address.
The forum reviewed version A. Readers now see version B.
If the forum does nothing, an old decision silently governs new content. This is approval drift.
Nick Gerakines's experimental article “Permissioned Data Shapes: Forums” preserves the CID of the version first admitted while using the URI to recognize the logical post after edits. That records useful history, but it does not decide whether later versions inherit approval. The draft ATProto permissioned-data proposal leaves this kind of application policy to the application.
Three reasonable policies
There is no universal answer. The right policy depends on what approval promises to readers.
1. Approve an exact version
The forum keeps the approved CID. If the current record has a different CID, the wrapper becomes pending or inactive until someone reviews the edit.
This is the clearest policy when approval implies that a moderator actually reviewed the visible content.
It creates friction. Fixing one typo triggers the same review path as replacing the whole post. An implementation can reduce that cost with quick re-approval, but it should not pretend to know that a change is harmless without checking.
If history matters, the wrapper can preserve both the CID originally admitted and the CID most recently approved.
2. Approve the evolving record
The forum approves the URI rather than a fixed CID. Future edits remain visible until a moderator removes the record.
This favors author control and low moderation overhead. It may be appropriate for casual communities where posts are expected to evolve.
It also permits bait-and-switch edits. The interface should not claim that the current words were reviewed. The forum approved an evolving record owned by Alice, not every future version individually.
3. Make every revision a new record
Instead of editing in place, Alice publishes version B at a new address and links it to version A.
Approval remains attached to an immutable revision. The history is clear, but the product becomes more cumbersome. Links, replies, and search results must decide whether they refer to one revision or to the continuing work as a whole.
A useful default
When admission conveys review, approve the exact version.
An active forum wrapper should ordinarily mean that the version readers see is the version the forum admitted. If the content changes, the system should visibly move it back to pending or request re-approval.
Approving the evolving record is still a valid choice. It just makes a different promise: “we include whatever Alice currently publishes at this address.” That should be stated plainly.
Deletion is another version problem
ATProto allows an author to delete a public record without leaving a tombstone inside the repository. An approval record can therefore outlive the content it points to.
The application needs distinct behavior when:
- Alice deletes the review;
- Alice later creates new content at the same record path;
- the forum has a stale cached copy;
- a moderator deactivates the wrapper while Alice edits the review.
Under exact-version approval, recreated content does not inherit approval because its CID differs. Under evolving-record approval, it might. Again, the policy must be explicit.
The interface should also distinguish “deleted by Alice” from “removed by the forum.” Those events come from different authorities.
Test the promise
The rule should be executable, not left in a product document. A small test suite can cover the important cases:
- approve A, then edit to B;
- edit while a moderator is approving;
- deactivate, edit, then reactivate;
- delete the record;
- recreate the same path with different content;
- display a stale cached copy.
Each test should assert which version readers see and what the interface claims was approved.
The governing principle is straightforward: if a decision was made about version A, the system needs an explicit reason before applying that decision to version B.