Item Lifecycle

Overview

An item is a single unit of data submitted to Truestamp for timestamping. Every item moves through a small, well-defined set of states. It begins as created, becomes processing once it is picked up for inclusion in a block, and reaches committed when its hash has been included in a finalized block. committed is the normal resting state: from there the item is verifiable. Beyond that a committed item can be redacted (its content removed while its proof survives) or scheduled for deletion, ending in one of two deletion states depending on why it is being removed. Throughout, ownership (not authorship) decides who is allowed to act on the item at each stage.

The three main states

An item advances through three states on the way to being verifiable. The names are exact and are the same everywhere the item’s status is reported.

created: the initial state, set the moment the item is submitted. Its hashes have been computed, and its timing fingerprint already names the witnesses that open the submitted-after edge of its submission window, so that edge is fixed before the item goes anywhere. It has not yet been placed in a block. Nothing further is needed from the user; the item simply waits to be picked up.
processing: the item has been assigned to a block that is being built. This is a brief, automatic stage. The user does not trigger it and does not need to act on it.
committed: the item’s hash has been included in a finalized block through that block’s Merkle tree. This is Item Commitment, and that block is the submitted-before edge of the item’s submission window: the block could not have been finalized before the item was in hand. committed is the normal end state and the point at which a proof can be generated and verified.

The forward path is created -> processing -> committed. An item that hits a transient problem while being placed in a block can be returned to created and retried; this is an internal recovery step, not a state the user drives.

How an item advances to committed

Advancing to committed is fully automatic. A user submits an item and then waits; no further user action is required.

At submission the item’s timing fingerprint records a hash for each public record it is being submitted after: the block then at the head of Truestamp’s internal ledger, which is always present, plus the newest observation captured from each external entropy source that had one. A source with nothing captured is simply left out and never holds up a submission.
Newly submitted items sit in created until the block-building process collects the current batch of unassigned items.
Each collected item is assigned to the block being built and moves to processing.
When the block is finalized and each item’s hash has been placed as a leaf in the block’s Merkle tree, the item moves to committed.

At committed the item has an inclusion proof against a finalized block, which is what makes it verifiable. Reaching committed closes the item’s submission window at the later end; the earlier end was already fixed at submission by the witnesses in the timing fingerprint. Neither edge says anything about when the underlying data was created. For the guarantee the two edges add up to, see the submission window. Separately, the block’s own hash is later recorded on a public blockchain (Block Commitment), which is what lets an outside verifier confirm the submitted-before edge without taking Truestamp’s word for it; that step is about the block, not the individual item’s state.

Redacted items

A committed item can be redacted. Redaction removes the item’s content (its claims data) while keeping every hash intact, so the item’s inclusion proof remains valid. This supports privacy and “right to be forgotten” needs without breaking the cryptographic record: the proof still shows that something was submitted in that window, even though the original content is no longer stored.

Only a committed item can be redacted, moving it to the redacted state.
A redacted item can be restored to committed only if the caller supplies content that cryptographically matches the preserved hash. This makes unredaction verifiable rather than a blind overwrite.
Redaction does not delete the item. A redacted item still exists and can still be verified; it has simply had its human-readable content withheld.

Deletion states

Deletion is a separate lifecycle from redaction. Both committed and redacted items can be scheduled for deletion, which moves the item into one of two terminal states that record why it is being removed. In both cases the item is not erased instantly: it is marked for a later permanent sweep, and until that sweep runs the item can be recovered.

deleted_user: a user chose to delete the item. It is scheduled for permanent deletion after a grace period (currently 7 days), during which the user can cancel and restore the item.
deleted_expired: the item was scheduled for removal because it exceeded a free-plan retention window. It also carries a grace period (currently 7 days) and can be cancelled and restored. Moving back onto a paid plan before the grace period runs out restores the items still waiting in this state automatically; items a user deleted deliberately are never restored that way.

Cancelling a pending deleted_user or deleted_expired deletion returns the item to whatever state it held before (either committed or redacted) and clears the pending-deletion marker. A user who wants a scheduled deletion to happen sooner can instead expedite it, which gives up the rest of the grace period and hands the item to the next sweep. Once the scheduled time passes, a background sweep permanently removes the item’s row.

An item that has not reached committed never enters either deletion state. In created or processing it is not yet a leaf in any block’s Merkle tree, so there is no proof to preserve and no reason to keep the row around: it is destroyed outright, with no grace period. That is true both when a user destroys it and when it passes a free-plan retention window before it was ever committed.

Deleting the owning account is a separate path from these deletion states, and it does not treat every item the same way. An item the account personally owns is permanently removed immediately, with no deletion state and no grace period, so that removal is not recoverable. Team-owned items go the same way when the departing account created the team and that team leaves ownership with the person who submitted the work; if instead the team is one that keeps ownership of its items, account deletion is refused outright until those items or the team itself are dealt with. An item the account merely authored, and that somebody else owns, is not deleted this way: it survives under its owner, with the authorship record replaced by a generic placeholder so it no longer identifies the departed account. See the life of a Truestamp account for the full account-deletion process.

Ownership governs who can act at each stage

Every rights decision at every stage keys off ownership, never authorship. Authorship (who first submitted the item) is a permanent, audit-only record and is never consulted to decide who may act. Ownership is transferable and is what determines who can read, update, redact, or delete an item. This distinction is covered in depth in item ownership versus authorship.

In practice this means:

Reading an item depends on its visibility and the reader’s relationship to the owning team, not on who submitted it.
Redacting or restoring an item, scheduling, cancelling or expediting its deletion, and destroying it while it is still uncommitted are all gated the same way, by who owns the item. On an item a user owns, only that user holds these rights. On an item the team owns, the team’s admins and owners hold them. A team admin or owner has none of these rights over an item a member owns personally, even though they can read it and change its settings. The one exception is redacting and restoring: a Truestamp system administrator who is also an admin or owner of the item’s team can do both.
These controls are on the item’s page, and the page shows each one only to someone who holds that right for the item in its current state, so a team admin looking at a member’s personal item sees none of them (a system administrator in that role sees only redact or restore).
Reassigning an item’s ownership is more restricted: it is limited to team admins and owners only. A user who merely owns an item cannot reassign it.
When a member leaves a team, items follow their owner, not their original author. An item the departing member owns moves with them to their personal team; an item the team owns stays with the team, and the departing member simply loses access.
When a team is dismantled altogether there is nothing left to stay with, so every item goes to a personal team: user-owned items to their owners, and team-owned items to the personal team of whoever created the team.

Because ownership can change while an item keeps the same hashes, transfers and reassignments never invalidate an item’s proof: a committed item stays verifiable across any ownership change.

Limitations

The lifecycle states are the authoritative product facts, but the exact timing of automatic transitions (how quickly a created item becomes processing and then committed) depends on the block-building cadence and is not a fixed guarantee.
Deletion grace periods are configured values (currently 7 days for user-initiated and expiration deletions) and can change. Two paths are defined as having no grace period at all: account deletion, and destroying an item that never reached committed.
Reaching committed fixes the submitted-before edge of the item’s submission window. It says nothing about when the underlying data was created, and it does not by itself confirm the submitted-after edge, which rests on the witnesses the item committed to at submission.

Knowledge Base