Products

A product is anything your organization builds and maintains: a product line, an application, a service, a shared library, a published tool. The catalog is one tree covering all of them, so "what do we own?" is a single question with a single answer.

Products are durable. A project is the funded, temporary effort to change a product; the product itself persists across many projects, and across none.

The Product Tree

Products nest by containment: a Product Line contains Products, which contain the Applications and Services that implement them. A product with no parent is a root.

The catalog offers two views of the same list:

• Tree (the default) shows the hierarchy, so you can see where a product sits.
• List shows every product as one flat list with a Parent column, which is better for filtering and sorting across the whole catalog.

The switch between them is the pair of icons above the catalog — a hierarchy icon and a list icon. They carry no visible label, so hover for a tooltip if it is not obvious which is which.

Filtering in either view searches the whole catalog rather than the current branch.

The Product Page

A product's page is divided into sections:

• Overview — tiles counting its Products (direct children) and how many of those are Releasable Products, plus, on a releasable product, Releases (90d): the versions that shipped in the last 90 days, counted on the day each shipped, beside the total. Below them sits the dependency map.
• Products — the products directly beneath it, with the count on the tab.
• Dependencies — what it relies on and what relies on it; see Dependencies.
• Releases — the releases announced under it. A release spanning product lines names no product, so it is not listed here. Shown only with Permissions.Releases.View.
• Versions — the versions cut against it. Shown only on a releasable type, where a version can exist.
• Status History and Activity — see Status History and Activity.

Product Types

Every product carries a type, which is what the organization calls that kind of thing. Types are data rather than a fixed list, so the vocabulary can match how your organization already talks.

Wayd seeds a starting set:

Type	Releasable	Meaning
Product Line	No	A logical grouping of products
Platform	No	A technical foundation other products are built on
Product	Yes	A commercial offering, presented to customers as one thing
Application	Yes	A deployed user-facing application
Service	Yes	A deployed service or API implementation
Tool	Yes	Something published to a registry and installed by consumers you do not control
Library	Yes	Published with its own version and consumed as a dependency
Module	No	Code with distinct ownership that ships inside another node
Interface	No	A surface a node exposes — OpenAPI, GraphQL, gRPC, MCP

Releasable is the flag that carries real weight: it decides whether versions can be cut against a node. Grouping nodes like Product Line and Platform are not versioned in their own right — the versions are cut against the services beneath them.

Retyping is constrained by versions

A type cannot be changed to a non-releasable one once versions exist against the product. Those versions would otherwise be left describing something that cannot be versioned.

Releases do not constrain retyping. A release is an announcement and is deliberately not gated on this flag — it usually sits under a product line, which is normally not releasable.

Types are deactivated rather than deleted, because products already using a type still need to resolve it. Deactivating one stops it being chosen for new products without disturbing existing ones.

Types have no screen of their own: an organization adds or changes them through the product types API, with the Permissions.ProductTypes.* permissions. The seeded types are system types — they cannot be renamed, have their releasability changed, or be deleted, only deactivated — so an organization wanting different naming or releasability adds its own beside them. A type of its own can be deleted only while no product uses it.

Product Status

A product's status says where it is in its own lifecycle — not how a project to change it is going.

Status	Meaning
Concept	Proposed but not yet in use
Active	Live and in use
Sunset	No longer offered, still supported
Retired	Withdrawn from service

Statuses are customizable through the status workflow rather than fixed in code, so these are a starting point.

Status History

Every status change is recorded, and the Status History section on a product shows them newest first: what it moved from and to, who made the change, when, and any reason given.

Each entry reports the status names as they were at the time. Renaming a status, or moving the product to a different workflow, does not rewrite what past entries read as — so a history stays a truthful account of what happened rather than a re-description in today's vocabulary.

Switch the section to Diagram to see the product's workflow drawn, with its current status and the path it has taken highlighted. See Seeing a workflow as a diagram.

A change made by a bulk import names the account that ran the import, and the product's Activity labels the actor Import — the import did this, rather than that person having edited each row by hand. A change whose author is no longer linked to an employee record shows as Unknown.

Changing a product's status requires your account to be linked to an employee record, because the change is attributed to the person who made it. This is the one product action that does — editing, retyping, moving, tagging and linking externally need only the permission.

Dependencies

The Dependencies section records which products a product needs in order to work — Storefront Web relying on Identity Service to sign users in. It is not the product tree: the tree says what a product is made of, dependencies say what it relies on elsewhere. A product cannot depend on itself, or on anything above or below it in the tree.

The section has two lists, switched at the top of the grid:

• Depends On — the products this one needs.
• Used By — the products that need this one.

Its tab counts both.

Recording the specific product

Record a dependency on the most specific product you know — the service, not the platform it belongs to. If Storefront Web needs Core Platform's identity service, record Storefront Web depends on Identity Service, not on Core Platform.

You never lose the wider picture by doing so. Both lists already include the dependencies of everything beneath the product:

• On Storefront, Depends On lists every dependency recorded on Storefront Web, Storefront Mobile and the rest of Storefront's products, with a From column naming which one.
• On Core Platform, Used By lists every product depending on any of Core Platform's services, with a Via column naming which service.
• A dependency between two products inside the same branch — Gateway Service on Identity Service — does not appear on Core Platform at all. From outside, that is Core Platform depending on itself.

Nothing is stored twice: the rolled-up rows are worked out when the page is read, so moving a product never leaves them out of date.

The map on Overview

A product with dependencies gets a Dependencies map on its Overview: what relies on it to the left, what it relies on to the right, and the product itself in the middle. A solid line is a hard dependency and a dashed line a soft one, and every product on it links to its own page.

Every product is drawn inside whatever contains it, on both sides, however deep the catalog goes. A dependency recorded against a product beneath this one starts at that product, nested in a box for each thing it belongs to; a product depended on is drawn under its own platform, so a row reading "Accounts API" says whose service that is. The box is containment — what a product is made of — which is why it is a box and not another line: a line always means "relies on". So Storefront's map shows Storefront Web inside the Storefront box with its own line out to Identity Service, rather than crediting Storefront with a dependency it does not hold.

A product line that holds products on both sides appears as a box on each side, because the columns are what carry the meaning: on the left is what relies on this product, on the right what it relies on. The same is true of a pair that depend on each other — each appears in both columns rather than as one node with a line doubling back.

The map draws the dependencies that hold today. Ended ones are left off however the Dependencies section's Show ended switch is set. A busy product's map shows the first few products per side, with a +N more at the foot of the column: click it to draw the rest in place. View all in the card's corner opens the Dependencies section.

To see what stops working if a product goes down, switch the control in the canvas's top-right corner from All to Hard only. The map is redrawn from hard dependencies alone: a product left with nothing but soft links drops off, and so does any box left empty. The first few products per side are then the first few with a hard link, and +N more hard counts only the hard ones left off — the Dependencies section itself is not filtered, so it still lists every strength. A product whose dependencies are all soft keeps its map, which says there is nothing hard in either direction. The choice holds as you move between products in the same browser tab, and is forgotten when the tab is closed. A map saved as an image while filtered is not marked as such, so say so wherever you paste it.

Following a dependency further out

Every product on either side has a + on its outer edge. Click it to follow that product's own dependencies one step further, without leaving the page: on the right, what that provider relies on in turn; on the left, what relies on that consumer. The products it finds appear in a new column beyond it, and you can keep going from any of them. That is how far an outage reaches — if Identity Service goes down, what breaks is everything that relies on it, and everything that relies on those.

• An expanded product is outlined, and its + becomes −. Click it to collapse, which takes away everything that expansion brought in, including anything you expanded beyond it.
• An expansion follows only the dependencies the product holds itself. A platform's services are not included — open the platform's own map to see those.
• Dependencies on this product, or on anything beneath it, are not drawn again: the map already shows them.
• A product appears once on each side, in the column where it was first found. When a later expansion reaches it again, the line goes back to where it already is — running back toward the middle, or curving round within a column — rather than drawing it twice.
• Each expansion shows the first few products it finds, with its own +N more for the product it came from.
• A product with nothing further out says so when you point at its button.

There is no limit on how far you can go. What you have expanded is kept for each product separately, in the same browser tab: come back to a product's page and its map is as you left it, while other products' maps start fresh. Hard only and the image export both apply to everything expanded.

Every product on the map — including the boxes — links to its own page. The controls down the left of the canvas zoom, fit the map back into view, open it full screen (Esc closes it), and save it as an image. PNG pastes anywhere; SVG stays sharp at any size. The image is drawn from the map rather than captured from the screen, so it holds the whole graph whatever you had panned to, and the controls are left out of it.

Strength

Every dependency is either Hard or Soft, and there is no default:

Strength	Meaning
Hard	The product stops working without it.
Soft	The product degrades or loses a feature without it, but keeps working.

The choice matters beyond the label. When Wayd shows a provider's outage against the products that rely on it, only a hard dependency will count — so a guessed strength misstates impact in one direction or the other.

Interaction

A dependency can also record how the two products talk — Synchronous, Asynchronous, or both:

Interaction	Meaning
Synchronous	The product waits for an answer, so the one it depends on has to be up at that moment.
Asynchronous	The product sends or receives messages and carries on, so an outage becomes delay rather than failure.

Strength says whether a product breaks without the other; interaction says whether it breaks at the same moment. Both can be ticked, for a pair that calls for what it needs now and subscribes for what it needs eventually.

Interaction is optional. Left empty, the Interaction column reads Not recorded — which is not the same as there being no interaction, so it is never shown as blank.

Adding a dependency

1. Open the product that has the dependency, and go to Dependencies
2. Click Add Dependency
3. Choose the product it Depends On and its Strength, and optionally its Interaction and a Description of what it is for
4. Leave Started empty to start it today, or backdate it to the day the dependency actually began

The picker hides the product's own children, and shows its parents without letting them be chosen, so the branches beneath them stay reachable.

A product can hold only one open dependency on another product. It can depend on the same product again later, once the earlier dependency has ended, but not over any part of the period the earlier one covered.

Ending, changing and removing

Each dependency has its own actions:

• Edit rewords its description, and records its interaction where none was recorded — writing down what was always true changes nothing, so the dependency keeps one period. Allowed on an ended dependency too. Interaction already recorded cannot be changed here.
• Change Terms changes its strength, its interaction, or both. It records a new dependency on the new terms from the First Day you choose, and ends the current one the day before. The old one stays in the list under Show ended, because the time before the change is still judged by the terms that held then. A dependency that started today can change terms from tomorrow; if it was recorded on the wrong terms, remove it and add it again. Recording an interaction on a dependency that had none, with the strength unchanged, is the exception: the dialog becomes Record Interaction Styles and fills it in place without starting a new dependency. An ended dependency cannot change terms.
• End records the last day the dependency held. It stays in the list — turn on Show ended to see it — and still counts for the days it held.
• Remove deletes a dependency that was never true, such as one recorded against the wrong product, and asks why. Do not use it for a dependency that has simply stopped: removing erases the record of when it held.

Dependencies are recorded by the day, and a dependency's Last Day counts as a day it held — so one that started and ended on the same day held for that day. Dates cannot be in the future, and a dependency cannot end before it started. Because the last day counts, a later dependency on the same product starts the day after the earlier one ended, not on it.

Every change is recorded in the Activity of both products — see Activity.

Activity

The Activity section on a product shows its full recorded history — not status changes alone, but every change the product raised an event for: details edited, type changed, moved, retagged, linked externally, dependencies added, ended, changed or removed. A product moving in or out also appears on both its old and its new parent, and a change to a dependency also appears on the product depended on, each marked with the product it was made on. See Activity Log.

Tags

Tags carry the classifications that do not change how Wayd behaves — platform, tech stack, compliance scope. They are grouped into categories, each category being one axis of classification.

Grouping matters: ios, react-native and pci-scope are different kinds of statement. In one flat list, "what platform is this?" requires you to already know which values are platforms. Grouped, it is just a question.

A category may allow one value or several. Tags display as Category | tag — the category dimmed — so a bare gold reads unambiguously as a tier rather than a support level.

Wayd seeds one category, Platform — what a product runs on or targets — which allows several values and holds web, ios, android, desktop, cli and server. Like the seeded types it is a system category and read-only; any other axis, such as tech stack or compliance scope, is added alongside it.

Manage a product's tags from the tag icon in the page header, or from Manage Tags in the actions menu.

The categories and tags themselves are administered in Settings → Product Management → Product Tags — see Administration.

Actions

The actions menu on a product's page is grouped by what each action does:

Edit and Delete change or remove the record.

Change Status, Change Type and Move each change one facet, and each enforces its own rule — separating them means a refusal tells you which rule stopped it.

Manage Tags and Link Externally attach context to a product rather than changing what it is.

Moving a Product

Moving changes a product's parent, or promotes it to a root by clearing the parent.

The parent picker is a tree, so you can see the hierarchy you are moving within. It omits the product being moved and everything beneath it — a product cannot become its own ancestor, and offering the move would only produce a refusal.

A move is also refused when it would put a product above or below a product it has an open dependency with, counting everything beneath the product being moved. Moving Core Platform beneath Storefront while Storefront depends on Identity Service would turn that dependency into part of Storefront. End the dependency first if the move is right; an ended dependency does not block it.

Linking Externally

The external link points a product at the record that owns it in another system: a repository, a pipeline, a registry package.

It is its own action rather than a field on Edit, because it answers a different question from what a product is called — and because renaming a product should never disturb the link. Clearing the value unlinks the product.

Nothing consumes the link yet. It exists so that a later automated feed can be matched against hand-curated products rather than re-authored over the top of them.

Common Tasks

Creating a Product

1. Navigate to Product Management > Products
2. Click Create Product
3. Choose a Parent (leave empty for a root product), a Type, and a Name
4. Optionally add a Description and set the initial Status

To create a child directly beneath an existing product, open that product and use Add Product on its own page — it pre-selects that product as the parent.

To stand up a whole catalog at once rather than product by product, see Bulk Import.

Reorganizing the Catalog

Use Move on the product that is in the wrong place, rather than recreating it. Moving preserves the product's history, its tags, and anything referring to it; recreating loses all three.

Retiring a Product

Set the status to Retired rather than deleting it. Deleting removes the record; retiring keeps the history of something that genuinely existed and shipped.

Deletion is also refused outright once anything depends on the product, and each reason is reported separately:

• it has child products — move or remove them first
• it has versions
• it appears in a release package manifest — checked separately, because a carried-forward manifest line often names a product with no version row at all
• it has dependencies recorded, or other products depend on it — ended dependencies included, because what a product relied on, and when, is history. Remove a dependency recorded by mistake first

In practice that leaves deletion for a product created by mistake and never used. Anything that has shipped is retired, not deleted.

To purge a retired product's history entirely, delete from the bottom up: any release that lists its versions or packages, then those packages, then its versions (each takes its deployments with it), then its dependencies, and finally the product. The activity history and audit trail are kept throughout. See Can I delete any of this?.

Permissions

Action	Permission
View the catalog and product details	Permissions.Products.View
Add a product	Permissions.Products.Create
Edit, retype, move, tag, change status, link externally, and add, change, end or remove dependencies	Permissions.Products.Update
Delete a product	Permissions.Products.Delete
Bulk import products and their dependencies from CSV	Permissions.Products.Import
Manage the type list	Permissions.ProductTypes.*
Manage the tag categories and their tags	Permissions.ProductTagCategories.*