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 hash has been computed but 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: proof that the item existed within the block’s submission window. 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.

1. Newly submitted items sit in created until the block-building process collects the current batch of unassigned items.
2. Each collected item is assigned to the block being built and moves to processing.
3. 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 proves the item was submitted within that block’s window; it does not prove when the underlying data was originally created. For the timing guarantee this establishes, see the submission window. Separately, the block’s own hash is later recorded on a public blockchain (Block Commitment), which strengthens the external timing evidence; 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.

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. Once the scheduled time passes, a background sweep permanently removes the item’s row.

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 owns is permanently removed immediately, with no deletion state and no grace period, so that removal is not recoverable. An item the account merely authored but does not own 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 an item and scheduling or cancelling its deletion are gated on being the item’s user-owner, or a team admin or owner of the owning team.
• 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 or a team is dismantled, items follow their owner, not their original author. An item owned by a departing user follows that user; an item owned by the team stays with 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; only account-deletion is defined as having no grace period.
• Reaching committed proves submission timing within a block window, not the original creation time of the underlying data.