Workspace

Origin & evolution

Workspace in this sense is native to the Unified Product Graph and to Entopo, the tool built on it. The lineage is the canvas tradition: the infinite, spatial surfaces popularised by whiteboarding and diagramming tools, where ideas get room to spread out before they are filed. The Unified Product Graph takes that surface and makes it structured underneath, so the loose arrangement on the canvas is already typed graph data rather than free-floating shapes.

The reason to name the workspace as its own concept is the gap between thinking and committing. A product graph is a clean, queryable record of what a team has decided about its product. Thinking is messier: half-formed personas🎭PersonaUserAn archetype representing a user segmentView reference →, edges drawn and undrawn, two competing strategies held side by side until one wins. The workspace is where that mess is allowed to live. It holds the in-progress state, the alternatives under consideration, and the spatial layout that helps a person reason, while the product graph holds what survived the reasoning. Separating the two keeps the graph trustworthy without making the thinking feel premature.

Skelton and Pais argue in Team Topologies that unmanaged cognitive load — the total weight of what a team must hold in mind to do its work — is the primary constraint🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference → on how effectively a team can move. The workspace addresses a version of that problem at the individual level: by giving a product creator a bounded surface to externalise competing ideas, partial structures, and discarded alternatives, it reduces the cognitive burden that would otherwise have to be carried mentally or scattered across notes and documents.

How it works in practice

A founder opens a workspace to map a new feature⭐FeatureProduct SpecificationA product capability or featureView reference →. She drops a persona, three jobs🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →, and a rough feature, and draws edges between them by hand. Two of the jobs turn out to be the same job seen twice, so she merges them on the canvas. She lays out two pricing options spatially, left and right, and sits with them for a week before deleting the one she rejects. Throughout, she is moving real entities around a surface, not doodling. When the shape settles, the decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → she reached gets recorded through the workspace, and the surviving personas and feature become part of the product graph. The discarded pricing option never enters the record, but the workspace remembers that the choice was made.

Workspace vs. its neighbours

• Product is what the workspace is about; the workspace is where you think about it. One is the subject, the other is the surface. A product can be reasoned about across several workspaces over its life.
• View is a saved, filtered lens onto graph data, built for reading. The workspace is the surface for making and changing that data. A view answers "show me the personas"; the workspace is where a persona is born and wired up.
• Decision is an outcome🏆OutcomeStrategyA desired business or user outcomeView reference → the workspace produces. The workspace is the deliberation; the decision is what crystallises out of it and gets kept. The surface is transient by design; the decision is permanent by design.

Kersten's Project to Product makes a related distinction at the organisational level: work organised as temporary projects — bounded, output-focused, disbanded on delivery — tends to destroy the continuity of understanding that a product requires. By that reading, the workspace occupies a deliberate middle position: it is allowed to be temporary and messy in the way a project is, but it feeds a persistent product graph rather than a final deliverable, so the continuity is preserved in the graph even when the workspace is discarded.

In the graph

In the Unified Product Graph, the workspace is the surface a product🧬ProductStrategyThe product being created, the root of the graphView reference → is thought through, captured by product_thinks_in_workspaceProductthinks inWorkspacehierarchy. It arranges the entities placed on it through workspace_arranges_node, and what it produces is captured by workspace_produced_nodeWorkspaceproducedany entitycausal, widened from the decision-only edge it began as, because a workspace produces personas and features as readily as it produces decisions. Modelling the workspace as a node, distinct from the product graph it generates, draws the line between the place structure emerges and the structure that survives. That separation is what lets the graph stay a clean source of truth while the workspace stays a forgiving place to think: neighbours such as view read from the committed graph, while the workspace feeds it.

A workspace and a composition🖼️CompositionWorkspaceA published arrangement of graph entities that has an identity of its own: a gallery, a board, a deck. Membership can be derived by running its query, position is authored by a person, and both are stored because both are real.View reference → are two halves of one pair, and at 0.33.0 they were given the same two fields. member_query makes membership derived rather than placed: members arrive by running the query instead of by someone dragging them onto the canvas. presentation carries advisory rendering intent, which a consumer may ignore entirely and stay conformant. Both had been declared only on the published half, and that was the wrong place for them. A canvas is query-driven while it is being thought through, not at the instant somebody publishes it, so declaring the query only on the composition made it a fact invented at publish time rather than one recorded. A canvas with no member query is authored, which is what every workspace written before this is.

Both fields tightened at 0.34.0, and a canvas feels the change before a published view does, because a canvas is where a selection is still being argued with. presentation gains orphan_disposition, either root or hide, which finally lets an author say what should happen to a member the query admitted but the nest_by relation cannot reach. Absent means root, and that default is chosen so that ignoring the field is safe: a consumer knowing nothing about it draws every admitted member somewhere rather than dropping the ones it cannot place. The measurement behind the choice is blunt. On an imported tracker graph of 1,118 nodes and 3,685 edges, one tree admits 218 members and renders a single card under hide, because tracker-imported work hangs off cycle and project relations, which are reference-axis edges rather than nesting. A default that hid them would turn a full canvas into an empty one with nothing to say why.

The other change moves no bytes. A clause inside member_query is now a discriminated union on dimension, so a clause on the type axis carries entity types and a clause on any other axis carries strings. The JSON is identical, which means no workspace file written before this needs🫀NeedUserA user need, pain, desire, or constraintView reference → migrating; what narrows is what a TypeScript author is allowed to write. The round-trip rule is untouched and still normative, because a union constrains authors and not the JSON arriving from a file. The clause list is authoritative, the named fields are its positive-only readable projection, and a tool that rewrites clauses into shorthand and back must refuse rather than silently drop a negation it has nowhere to put.