Product records
Solutions, the features under them, the models and fields below those, and the handlers, rules and screens around them. Each one is a real record with a name, an owner, notes and where it stands, so the shape of your product is something a person can open and read instead of something you re-explain every time somebody asks.
Product records, close up
Comes from
The tree
Hangs off it
What is travelling those lines
This is the same map as the one on the front of Solutions, zoomed into one surface. The tree runs down the middle. What feeds it is on the left, what hangs off it is on the right, and the one place work waits is you.
What it does
A solution, the features under it, the models under those, the fields on them. Each is a real row with a name, notes, an owner and where it stands, on its own page, searchable by name across every kind at once. Nothing has to be redrawn when something changes, because there was never a drawing to keep in step.
A row shows the statuses of what is attached to it: a solution shows its features and every model under them, a model shows its fields, its handlers and its moments. It is a picture of where the parts have got to. Nothing is worked out from it, and the record's own status stays a value a person set.
Each segment of a bar is one record, and clicking it opens that record, so the bar is a way in rather than a decoration. A segment for a moment takes you to where moments are edited, because that is where it actually lives.
A field pointing at another model records the target, how many of each there are, and the naming on both sides, then says it back in plain words: this belongs to many of those. That is what lets the data diagram draw the line the right way round instead of guessing.
A handler carries the rules that guard it and the roles allowed to reach it, each rule with its own settings. All of it is a record of your product's access model. None of it changes who can do what inside this workspace, which is decided somewhere else entirely.
A decision, a design note or a release note attaches to the thing it is about: a solution, a feature, a model, a handler, a page, a shell, a block, a rule, a role, a hook or an interceptor. Fields are the one exception. It is a short list of one, and you should hear it from us.
One request returns every record and every join for the brand, and the same answer is drawn several ways: everything at once, the architecture layer by layer, the data and its relations, and the chain from a model to a handler to a moment. Different conversations, one set of records underneath.
Every kind here carries a version that travels with your save, so two tabs, two people, or an agent and you cannot land on top of each other in silence. Walking away from a record with unsaved changes asks first.
The layers
The tree nests: a solution holds features, a feature holds models, a model holds fields. Around it sit the handlers that act on a model and the screens that render it. Every layer is optional, and an empty one is not a gap the product will nag you about.
The spine, each one inside the last
One product, or one large area of one. Its row shows where its features stand, and where every model under them stands.
A unit of what your product does. Delete the solution above it and this keeps its own record instead of going down with it.
A thing your product stores or reasons about: an order, a subscriber, a device. Fields, handlers, hooks and moments all point here.
A field on a model. One that points at another model records which one, which way round and how many, and says it back in plain words.
Attached to a model
Rules and roles here are a record of your product. They have no effect on who can do what inside this workspace.
Beside the tree, not under it
None of these hang off a model, so you can write down the screens of something without creating a model first.
Where this sits
The tree is worth keeping on its own. The reason it stays current is that the rest of the workspace points at it: the boards it gets thought up on, the notes that explain it, the moments it will report, and the drafts written about it.
Where a lot of this is thought up. A note becomes a real record on the tree through a confirm you drive, and records already here drop back onto a board as live cards showing their current status.
Read WhiteboardsThe decisions and notes that explain the tree. They attach to the record they are about, that record's tab lists them, and its row shows how many are on it.
Read ArtifactsThe moments your product will report, agreed here before the code that reports them exists, attached to the model they are about and to the handlers that will report them.
Read EventsA draft can name the feature it describes from inside its own body, and the link is a checked row rather than a phrase. It is written from the draft side today.
Read ContentWhat an agent may do with all of it, under your permissions and your brand limits, and what it is structurally unable to do.
Read Your agentYours to keep
Every one of these we would choose again.
Where something stands is a value a person sets, checked against the workspace's own status list before it is stored. No parent is calculated from its children, and no colour on any row will ever tell you something moved on its own.
They keep their own records and simply stop naming a parent, so a reorganisation cannot quietly take a month of writing with it.
Use the layers that fit what you are building. A hook does not need a model above it, the screen layer needs nothing above it at all, and nothing here nags you about a layer you left empty.
An agent can work this tree all day. There is no delete for it to call, so what disappears is what you chose to remove.
One status list covers the product tree, your writing, your files and your notes, so a word means the same thing wherever you meet it, and the list itself is yours to change.
The roles and rules you record here describe your product. They are never quietly turned into controls over this workspace, and that is a promise worth making out loud rather than leaving to the word.
Questions
Keep reading
Where the tree usually gets thought up before it is written down.
The tasks and decisions that hang off every record here.
The moments your product reports, named before the code exists.
What an agent is allowed to do with all of it.
Open the workspace, do one real piece of work in it, and the joins will show you the rest.