Overview

Every Truestamp Item carries two separate identity facts that are easy to conflate but must stay distinct. Authorship records who ran the action that submitted the Item. Ownership records who currently holds the rights over it. Authorship is a permanent part of the Item’s audit trail, never rewritten by any transfer, reassignment, plan change, or team move, and deliberately kept out of every cryptographic hash; the one narrow exception, covered below, is what happens to an authorship record when the author’s own account is deleted. Ownership is transferable and is the single thing consulted whenever the system decides who may read, update, delete, redact, or reassign an Item; for reads it works together with the Item’s visibility setting, which widens who may see the Item without granting any rights to change it. Keeping the two axes separate lets an Item move between people and teams over its lifetime while its proof of submission stays valid and unchanged.

Authorship: the immutable creator record

Authorship answers “who submitted this Item?” It is set once, from the authenticated actor performing the submission. No action lets anyone reassign it afterward; there is no “change author” operation anywhere in the system. It exists purely as an audit-trail fact: it tells you who was at the keyboard when the Item was submitted, and nothing more.

Two properties make authorship trustworthy as a historical record:

• It is immutable to every ownership event. No transfer, reassignment, plan change, or team move ever rewrites it. Once written, it stays, with the single exception described in the next section.
• It is never consulted for rights. Anything that asks “is this actor allowed to do X to this Item?” reads ownership, not authorship. A person can be the original author of an Item and have no current rights over it, or hold full rights over an Item they did not author.

Because authorship is audit-only, the interface presents it as a distinct “Created by” fact, kept separate from who currently owns the Item.

Authorship after the author’s account is deleted

Deleting an account does not delete every Item that account authored. Ownership decides an Item’s fate, not authorship, so an Item the departing account no longer personally owned, for example one owned by a team under the team retains model, or one previously reassigned to someone else, survives the account’s deletion and keeps proving exactly what it always proved.

A surviving Item’s authorship still has to point at a real account, and the deleted account no longer exists, so that Item’s authorship is repointed to a single, shared, anonymized account reserved for this purpose. The Item’s audit trail still shows it was authored by an account that has since been deleted; it no longer identifies which one, and the same shared marker is used for every account that has ever been deleted this way. This substitution is the only circumstance in which an Item’s authorship ever changes, and it never changes who owns the Item.

This is the same separation carried to its limit: even once the account behind an authorship fact ceases to exist, ownership already determined the Item’s fate, so nothing about who currently holds rights over the Item needs to change.

Ownership: the transferable rights holder

Ownership answers “who has rights over this Item right now?” The owner is either a single user or a whole team. This is the axis every rights decision keys off. Reading the Item, updating its mutable fields, redacting its contents, restoring redacted contents, scheduling or cancelling its deletion, and destroying an uncommitted Item are authorized against either the current owner or a team admin or owner of the owning team. Authorship plays no part in any of these checks.

Two rights are more restricted and are not available to a plain user-owner:

• Moving an Item between teams is limited to team admins and owners of the owning team. A user who merely owns an Item cannot relocate it to a different team; updating an Item as its owner never changes which team it belongs to.
• Reassigning an Item’s ownership (handing it from a user to the team, or from the team to a specific user) is likewise limited to team admins and owners. A user who merely owns an Item cannot reassign it.

Ownership is transferable by design. An Item can be handed from a user to the team, from the team back to a specific member, or relocated to a different team, all without touching authorship. The Item details view shows a distinct “Created by” row for authorship, rendered when the creator is present, separate from an always-present “Ownership” row for the current rights holder. That ownership row reads “Creator-owned” in the common peer case where the owner is the same user who authored the Item, “Team-owned” when the Item is owned by a team, and “Owned by” followed by the owner’s name only when the Item has been reassigned to a different user. The two rows coincide in meaning only in the peer case; in every other case they describe different parties.

Why the two are separated

Collapsing authorship and ownership into one field works for peer-style collaboration but breaks for organizations. Consider a company that wants the evidence its employees timestamp to belong to the company. If “who authored it” were the same as “who has rights,” an employee leaving would carry the company’s proof with them, and the company could lose access to evidence it has a legitimate claim to. The mirror problem hits peer collectives: a contributor who leaves a group should not lose the evidence of work they personally authored.

No single global rule serves both cases. Splitting the axes lets each Item record an unchangeable authorship fact while its rights follow a separate, transferable owner. Membership changes, team deletions, and account deletions then route Items by owner rather than by author, so evidence lands where it should in each model.

Choosing an ownership model per team

Teams decide the default owner for the Items submitted within them by picking one of two ownership models when the team is set up:

• Creator retains (the default): each new Item is owned by the person who submitted it. This matches peer collaboration; Items follow the person if their membership ends.
• Team retains: each new Item is owned by the team itself. This matches the corporate case where work product belongs to the organization; Items stay with the team when a member leaves.

The team retains model is a paid-plan feature. Because it changes who owns a member’s work, a person invited into a team-retains team must explicitly acknowledge the ownership terms before joining, so the ownership arrangement is consented to rather than silent. Personal teams always use the creator retains model. A team may switch from creator retains to team retains only while it holds no Items, and the reverse switch is never allowed, which keeps every existing Item’s ownership arrangement stable once Items exist.

Because the team retains model depends on that paid entitlement, choosing it also guards the plan behind it. While an owner still has one or more team-retains teams, a plan downgrade that would strip the entitlement the model requires is blocked; the block message names the affected teams. To downgrade, the owner must first move those teams off the team retains model or delete them, so a live team-retains arrangement can never be left standing on a plan that no longer grants it.

Authorship is not in any hash

Authorship is a database and audit-trail fact only; it is excluded from every cryptographic hash Truestamp computes for an Item. The Item’s hashes are built from the user’s submitted claims, the temporal metadata, the Item’s own identifier, and the id of the signing key, and none of the ownership or authorship fields participate. See hashing and domain separation for how those hashes are composed.

The practical consequence is important: transferring ownership, reassigning an Item between a user and a team, moving it between teams, or repointing authorship when an author’s account is deleted, never alters the Item’s hashes. Any proof that was valid before any of these changes remains exactly as valid after it. Ownership can move freely, and authorship can be substituted in that one account-deletion case, without ever weakening or invalidating the timestamp proof, precisely because authorship and ownership live outside the cryptographic commitment while the submission-window guarantee lives inside it.