Overview

Everything you do while signed in happens inside a single active team. A team is the unit of tenancy in Truestamp: the items you submit, the teammates you work with, and the features you can reach are all resolved against the team you are currently acting in. Every request carries your identity plus one active team, and Truestamp uses that pair to decide what you may read and change. Your rights come from your role in that team, and the features available come from the plan attached to your account. This document describes the product model that is the same for every signed-in user; it is not tenant-private information.

Two independent things determine what you can do at any moment: your role in the active team (owner, admin, member, or viewer) and your plan tier (free, starter, pro, enterprise). Roles govern who can act on teams, memberships, and items; plans govern which features and limits apply.

Teams as the unit of tenancy

Work is partitioned by team. Each item you submit belongs to exactly one team, and reads and writes are always evaluated in the context of your active team, so you only ever see and touch the items of a team you belong to. Switching teams switches the entire working context: the items list, the members, and the feature set all change to match the newly active team.

Membership is the gate. You can read a team, and the items and memberships within it, only if you are a member of that team in some role. People become members by accepting a team invitation. Someone who is not a member of a team cannot see its items at all. This is enforced at the data layer for every read and write, not just hidden in the interface.

For how ownership of an individual item behaves as people join and leave a team, see item ownership versus authorship. This concept covers who can act within a team; that concept covers who owns a given item and what happens to it on membership changes.

Team roles and what each can do

Every membership carries exactly one role. The four roles form a strict hierarchy from most to least privileged: team owner, team admin, team member, team viewer.

• Team owner - full control of the team. Owners can update team settings, manage every other membership (grant, change, or remove owner, admin, member, and viewer roles), change the team’s ownership model, and delete the team. A team can have more than one owner.
• Team admin - can update team settings and manage member and viewer memberships, but cannot manage owners and cannot change the team’s ownership model or delete the team.
• Team member - a full working participant. Members submit and work with items in the team but do not manage other people’s memberships or team settings.
• Team viewer - read-only. Viewers can see the team and its items but cannot submit items or make changes.

Membership management authority is hierarchical and layered on top of the role. The person who originally created the team (the creator), while they still hold an owner membership, sits at the top and can manage every role including other owners. A plain owner who is not the creator can manage admins, members, and viewers but not other owners. An admin can manage only members and viewers. This means you can only grant or remove roles that sit at or below your own authority, so no one can escalate a teammate (or themselves) above their own level.

Some team operations are deliberately not exposed on any programmatic API and are reachable only through the web interface, because they are high-consequence. These include changing membership roles, removing members, changing the team’s ownership model, and deleting a team. Deleting a team never destroys its items: the items are first transferred to personal teams, then the memberships and the team record are removed. User-owned items follow their owner to that owner’s personal team, keeping their owner. Team-owned items (on a team-retains team) go to the team creator’s personal team, with their ownership flipped to the creator as a user-owner. Creating a team and reading teams and memberships are available across the product’s surfaces to a signed-in, authorized user.

Personal teams

Every user has a personal team, and it is created automatically the moment the account is created. You never have to set it up. Your personal team is named “Personal”, you are always its owner, and it always uses the creator-retains ownership model, meaning items you submit there stay with you.

The personal team is your always-available home base. It cannot be deleted the way a regular team can (it is protected from ordinary deletion), and it is the fallback the product lands on whenever no other team is selected. If for any reason a personal team is ever missing when the product needs it, it is recreated on the spot, so a signed-in user always has one.

Regular (non-personal) teams are the ones you create to collaborate with others. Whether you can create additional teams beyond your personal team depends on your plan (see plan-based feature gating below): the free tier allows only the personal team, while paid tiers raise the number of teams you may own.

How the active and default team are resolved

At any moment you are acting in exactly one team. When the product needs to pick which team is active (for example on sign-in, or when a request does not name a team explicitly), it resolves it through a fixed preference order:

1. The team already selected for this session. If you have switched to a team during your session and you still belong to it, that team stays active.
2. Your default-team preference. If you have set a preferred default team, the product uses it, but only after checking that you still have a write-capable role there (owner, admin, or member). A read-only viewer role is not enough to land on a team by default. If the preference points at a team you have left, been demoted to viewer on, or that no longer exists, the stale preference is cleared and resolution continues to the next step. On the interface you are shown a brief notice when this cleanup happens.
3. Your personal team. If neither of the above applies, the product falls back to your personal team, the one guaranteed to always exist and to always have you as owner.

You can change the active team at any time using the team switcher, which lists every team you belong to. Marking a team as your default makes it the team you land on when you next sign in, subject to the write-capable check above. Because the default resolves the same way everywhere, the team switcher can show a star next to whichever team is currently your effective default: the explicitly preferred one if you set a preference, or your personal team if you did not.

Switching or defaulting to a team never changes your plan or the features you have. Those come from your account, not from the team, so moving between teams keeps the same entitlements and limits.

Plan-based feature gating

Alongside your role, your plan tier decides which features you can use and the numeric limits that apply. There are four tiers, from lowest to highest: free, starter, pro, and enterprise. Each tier carries a set of feature entitlements and a set of limits, and both are attached to your account and travel with you into whichever team you are acting in. The tiers, their limits, and their entitlements are detailed in plans, limits, and entitlements.

Plans gate features in two ways:

• Feature entitlements - named capabilities a tier does or does not include. For example, the ability for a team to retain ownership of its items (rather than items following their creator) is a plan-gated entitlement available on the paid tiers, and priority support is an enterprise-tier entitlement.
• Limits - numeric ceilings such as how many items you may submit per month, how many teams you may own, how many members a team may have, how large your custom item metadata may be, and how many outgoing webhook endpoints you may configure. Higher tiers raise these ceilings. Some capabilities are expressed as a limit being above zero: for instance, being able to own more than just your personal team means your team ceiling is greater than one, and being able to attach custom metadata means your metadata size ceiling is above zero.

When you hit a limit, the product tells you which limit you reached and how to resolve it, rather than failing silently. Downgrading a plan can be blocked when your current usage or configuration depends on a higher tier (for example a team that retains ownership of its items cannot be left on a tier that does not include that entitlement), so downgrades are checked against what you are actually using.

Limitations

• Being a member of a team is what grants visibility into it. There is no way to read another team’s items or memberships without holding a membership in that team.
• A viewer role is intentionally never enough to make a team your active default; the default resolves to a team where you can actually do work, or to your personal team.
• Plan tier applies at the account level, not per team. Switching between teams does not change your entitlements or limits.
• The highest-consequence team actions (role changes, member removal, ownership- model changes, and team deletion) are performed only through the web interface, not through the programmatic surfaces.