Playbooks, lenses and workshops

The memory of where you hesitated is the most valuable part of the record. Choose the shape first: a sequence when the steps are followed in order, a checklist when all of them have to be done in any order, and a flowchart when the next step depends on what you find. File it under the part of the business that runs it.

Write the trigger before anything else. Nobody browses a playbook library under pressure, so write use this when as the sentence a colleague would recognise in the moment. If you cannot state it in one sentence, the procedure is probably two procedures.

Each step is one instruction, with room for the details, a screenshot of what a good result looks like, and the exception that bites at that step. A playbook with no stated exception gets followed once into a situation it was never written for.

Fresh, ageing, overdue and never reviewed are measured from the record's review date. Growth-OS does not watch anybody work, so it cannot know when a playbook was last followed, and a playbook with no review date is its own bucket rather than a fresh one.

Generated insights read the playbook and propose changes you apply one at a time. Each reading names the revision it read and says so when the playbook has moved on. The automation verdict is a judgement about the procedure as written, not a claim that anything is connected.

The lens library holds reusable ways of looking at a problem, shipped with the build as reviewed files and grouped by family. Nothing on that screen adds, edits or removes a card, which is why every project reads the same library. Every card carries where it breaks, because a lens with no stated failure mode is a slogan.

Your own lens records are different: they are what happened when somebody applied a lens to a real decision in this project. When it applies, the questions to ask and where it breaks are all required, and the record links to the decision it came from.

The multi-lens workbench takes one idea and up to twelve lenses, runs each perspective independently against matching project records, and keeps the disagreements in the final comparison rather than smoothing them away. Results are exploratory hypotheses that clear when you leave, so copy what you want to keep.

A workshop turns one imported card into a session this project keeps: the preparation, what every step produced, the outputs and the next actions. Choose how you will run it first, because solo, facilitated and async are three different sessions rather than three labels, and the mode is saved so a later reader knows how the answers were produced.

Finishing is deliberately harder than saving. Completing asks for every step checked, an output written down and at least one next action, so a session marked complete is one somebody else can act on. A saved session is stored as a meeting, which is why it can be quoted as evidence.

A brainstorm starts from a central question and shows the same ideas as sticky notes, a mind map or an outline. AI suggests possibilities without saving them; you select what to keep. Turning a selection into a decision poll makes the reviewed question and options visible to the workspace, and the rest of a private board stays private.

Nothing on these pages chases an action for you. Put each one in Commitments, where an owner and a date make it checkable. Write what the session settled as a decision with the alternatives it weighed. Turn a workshop you keep running into a playbook somebody else can follow.