How Trace.Space is organized

Trace.Space keeps everything your team writes about a product in one tree of items and links those items with traces. This article names the pieces you meet in the app and says what each one is for. It contains no procedures; follow the links for the how-to. For one-line definitions of the same terms, see the Glossary.

An organization is a self-contained workspace with its own items, item types, members, settings and AI configuration. Nothing is shared between organizations. You can belong to several and switch between them with the organization dropdown in the settings menu at the top of the left sidebar; see Switching Organizations. Every new organization starts with the Sample set.

Everything you write is an item: a requirement, a test case, a chapter heading, a folder. Items live in one tree, shown under Items in the left sidebar, and the main area shows the item you open together with everything below it. The position of an item in the tree is itself a trace (parent/child), so moving an item changes its traces.

Every item has a short ID made of its type's identifier and a code, for example REQ-ABCD, and a version number that goes up with every change. Earlier versions stay available in the item's history. See Creating items and project structure and Using the Tree View.

An item type says what kind of thing an item is and which attributes it carries. A type has a name, an icon, an Identifier that becomes the short ID prefix, a list of attributes, optional AI Instructions, quality check settings per attribute and traceability rules. Org admins define types under Organization settings > Item types; see Item types. An item can also have No type, and any item can get extra attributes of its own from the + in its details sidebar.

Attributes come in eight kinds. All of them appear in the item details sidebar and as columns in the table view; an attribute also appears in the document view when Show in document View is on for it.

A trace links two items so you can see what depends on what. Every organization has the built-in trace types Parent/Child, Related and Duplicate, and org admins can add custom types such as verifies / is verified by under Organization settings > Trace types. A trace type is Directed (it has an upstream and a downstream end), Undirected (both ends are equal) or Either, and each direction has a verb that the app uses to read the trace as a sentence.

Traceability rules live on the item type. A rule says that items of one type should trace to items of another type with a given trace type, whether that trace is Required, and whether a change to the upstream item Triggers suspect on the trace. Rules give traces three states: Missing (a required trace does not exist yet), Suspect (the other item changed since the trace was made) and Invalid trace (the trace matches no rule and the type does not allow traces outside its rules).

You see traces in the Traced to section of the item sidebar, as edges in the graph view, in the traceability matrix and in analyses. See Traceability and the article Trace types and traceability rules.

A baseline is a snapshot: a set of items, each pinned at the version it had when it was added. Baselines are Editable, Frozen or Archived; every change to a baseline creates a new baseline version, and baselines are the usual starting point of a review. See Creating Baselines.

A variant is a baseline used as a lens. Any baseline can be chosen with the Filter by variant icon in the Items tree header. While a variant is active, every view shows the versions pinned in that variant, and members of the variant are marked with a dot. See the article Variants.

A parameter is an attribute of parameter kind on one item that other items reference from their text with $. When its value changes, every reference is flagged until someone clears it. The Parameters page (marked Beta) lists them all, and a baseline can pin parameters as well as items.

A review is a fixed set of item versions that participants read and mark as Approved, Needs work or Rejected, with comments. Required participants must give feedback; optional ones may. When items change during a review, a new revision picks up the latest versions. Reviews are Open, Closed or Archived, and an AI reviewer can pre-read the items. See the article Reviews.

A test run groups test cases (items with a Test steps attribute), pins each at its current version, assigns testers, and records Passed, Failed, Blocked or Skipped for every step and every case. Runs are Not started, In progress, Ended or Archived. See the article Test management.

The items do not change; how you look at them does. The Document, Table and Graph views show one branch of the tree (View modes). Saved filters are live lists of items that match a filter, the Traceability Matrix crosses two sets of items to show and create traces, Saved analyses (marked Beta) follow traces across several hops, and the dashboard collects activity, statistics and your own panels. All of these are reached from the left sidebar.

Everyone who joins the organization is a member. Members of the Organization Administrators user group are org admins, who manage types, settings and people. Other user groups carry access levels (Deny, View only, Edit, Manage) per item, inherited down the tree, so you can hide or protect any branch. See the articles User groups and access control and Roles and permissions reference.