Welcome. Make it yours.
This is the implementation kit to Designing Coherence. The book gave you the framework. This is what to do on Tuesday — the diagnostics, templates, checklists, and playbook a real installation needs.
The book argues that AI changes what it means to operate a company, and presents a framework — six personas plus a Conductor, three Convergence Points, the Book of Record, the Band, the Coherence Layer — for how to operate inside that change. That argument is theory. It is clean by design.
The work of installing it is not clean. You need to know who to speak to first and what to say. Which questions land and which harden the room. What to do when the first Selection Point sends back the CEO's favourite project. What to measure. What not to measure. How to know whether the model is actually working or only performing.
This kit is built for that work. It is generous on purpose. Every template is filled in once with a real example, then left blank for you. Every checklist is annotated. Every section names the trade-off you are actually facing, not the textbook version. If you came here looking for one diagnostic and one template, you will leave with a working operating instrument that you can use, adapt, and run for a year.
How this kit is structured
The kit is built as a working tree on the left side of your screen — your Company, the Bands inside it, and the Initiatives inside each Band. You build out the tree as your real operating structure, and the kit fills in around it.
- Top of the tree: Company. Your name, your one-line description. Everything below is about how you actually deliver against it.
- Each Band is a team that holds all six personas plus a Conductor for one product surface. It carries its own personas, KPIs, and purpose.
- Each Initiative is a Book of Record. A living document — Selection parameters, every persona's commitment, every Convergence Point held, change management, the Conductor's daily reads, weekly meeting notes, adoption numbers, escaped bugs, decisions, risks, the full timeline. The complete life story of one piece of work.
Around the tree there are a small number of cross-cutting instruments — the Readiness Diagnostic, the Stakeholder Map, the Installation Playbook, Drift Detection, the CEO Scorecard — that operate at company level rather than per-initiative.
Two branches in the tree
The tree on the left has two branches. The first is Example — a fully populated worked example of a fictional company called Acme Software, a Band, and three initiatives at different stages (Selection, Produce, Validation). The example is read-only, with teaching notes that explain what to notice in each section. Read it on your first pass; come back to it as a reference. It exists to show what every section of the framework looks like once filled in for real.
The second branch is Your company — empty, editable, yours. Build out your own company, Band, and initiatives here. Everything you put in is saved locally to your browser; nothing ever leaves your device.
This kit is a map of what to track during a coherence pilot. It shows you the structure — what a Book of Record looks like, what each persona needs to maintain, when Convergence Points happen, what the Conductor reads weekly. It does this so you can see, concretely, what an operating model built around the framework looks like.
It is not your operating system. The idea at this stage is not to make you change your tools. It is to give you a coherence management layer — a shared vocabulary and a discipline for what gets tracked across your work. Once that layer is real in your company, the implementation choice (existing tools vs. agents vs. something custom) is downstream.
The kit gives you the Conductor's Queue — the surface where agent proposals land for accept / amend / reject. From day one, you can feed the queue by pasting LLM output. After the pilot, the real Coherence Layer reads continuously — either inside the tools you already use, or as a custom agent system. See Tier 6 — Custom Coherence Agent in Talk to Ruth.
How to use this
Start with the Readiness Diagnostic. Twelve questions. The score tells you whether to install now, prepare first, or wait. Even if you already know the answer, the questions surface what your senior team disagrees on — which is the most useful information you will get all quarter.
Then explore the Example branch in the tree. Walk through Acme Software's three initiatives at different stages. Read the teaching notes. Get a feel for what a populated Book of Record looks like.
Then click your company at the top of Your company. Set your name and description. Add a Band — give it a name, a purpose, and the people who hold each persona. Add an Initiative under it. The Initiative opens its Book of Record, and the work begins. Most companies start with one Band and one Initiative. Add more only after the first one is running cleanly.
This is a downloadable HTML file. It runs locally on your machine. Open it in any modern browser and it works offline, with no server, no account, nothing leaving your device. Your work saves automatically into this browser, tied to this file at this location.
Three things to keep in mind:
- Keep this file in one place. Saved work is tied to the file's location on disk. If you move the file to a different folder, your saved work doesn't follow — it's still in the browser, just keyed to the old path. Decide where the file lives, leave it there.
- Use Export Work to back up. Browsers occasionally clear local storage — clearing cookies does it, switching browsers does it, low disk does it. Once a week, or after a serious work session, click Export work in the sidebar to download a JSON snapshot. Keep it somewhere durable.
- Future versions don't replace this one. The file you downloaded is yours. If a new version ships, it's a separate download — your work stays here, untouched. To migrate forward: Export from this file, Import into the new one.
Full saving instructions are at the bottom of the sidebar in Saving & data.
What this is not
It is not the book. The framework is not re-derived. If the personas, Convergence Points, or Book of Record feel unfamiliar, return to the book before going further — you will find this kit thin without it.
It is not industry-specific. Software, financial services, healthcare each get their own playbook. This one assumes a software company. The templates adapt; the politics rarely do.
It is not a prescription. Most decisions inside a real installation involve trade-offs only you can weigh. Where the operator's instinct is clear, this kit states it. Where reasonable people disagree, it names both moves and what each one tends to cost. You decide.
One last thing. If the kit does its job, you will have more questions at the end than the beginning — sharper ones, about your specific company. That is the design. The CEO and COO who finish this kit and want to talk through their installation are the people I most want to meet. The "Talk to Ruth" tab at the bottom is how to do that. No pressure either way.
— Ruth Amichay
Readiness Diagnostic
Twelve questions across four dimensions. Score honestly. The pattern of low scores tells you what to fix before installing — and which sections of this kit to read first.
Score each question on a scale of 0–3. 0 not at all · 1 partly · 2 mostly · 3 clearly yes. If you can, score with two or three other senior leaders independently. The disagreement is more informative than the score.
Stakeholder Map
Before any conversation, the map. Who gains, who loses, who is mixed. The framework redistributes authority — this is where you find out whose authority is moving, and how they are likely to respond.
Fill privately, not in a meeting. The honesty needed here is rarely the kind senior teams practice in groups. Three columns matter most: what the person gains, what they lose, and your best read of their current posture.
Sponsor — actively carries it. Likely ally — will support if asked. Mixed — depends on framing. Cautious blocker — won't oppose publicly but won't carry. Active blocker — opposing. Unknown — you don't know yet, name what you'd need to learn.
Your Company
The top of the tree. Set your company name and a one-line description. The Bands below carry the actual operating work — each Band is a team that holds all six personas plus a Conductor for one product surface.
Band Detail
A Band holds the personas, KPIs, and purpose for one product surface. The initiatives below — each its own Book of Record — are how the Band delivers against its KPIs.
Book of Record
The complete record of one initiative — Selection parameters, each persona's commitment and current state, Convergence Points held, change management, decisions, risks, operational metrics, the Conductor's reads, the timeline. Everything that matters about this initiative lives in this Book.
The Book is the contract the work is held to. It is what every Convergence Point reads aloud, unedited. It is what the Conductor reads daily. Six tabs, each holding a different facet of one piece of work — together they are the initiative's truth.
The Book of Record is not a document you write once. It is a living surface, and the Conductor is its keeper. The daily and weekly cadence below is what makes the framework actually run.
- Open the Conductor tab. Read the Queue. Triage anything new (raise / decline / watch).
- Add a one-line entry to Daily reads — what the room said today that no tool will surface.
- Open Follow-ups. Anything overdue? Anything sitting too long in one column?
- Read each persona's now / changed / open in the Personas tab. Note any field older than two weeks.
- Walk through any held CPs in the Convergence Points tab — are partials closing on schedule?
- Run the weekly Band meeting from this Book. Log notes in the Conductor tab. Update Drift signals if any pattern is starting.
- Check the Dashboard. Is the current phase tracking? What is the next CP date?
- Currency over completeness. A Personas tab where every "now" is two weeks old is dead, even if every field is filled. A tab with three honest, fresh entries and three blanks is alive. The Book's value is that it tells you what is true today.
- The kill threshold cannot be edited. Set in Scope at Selection. Read aloud at Validation. If you find yourself wanting to soften it, log a Change with the rationale — do not rewrite the original.
- Decisions go in the Conductor tab, with the forum named honestly. A pattern of "hallway" or "Slack" in the forum column over time tells you the framework is drifting into Coherence Theatre.
- Every Partial needs a date, a name, and a persona column. Without all three, the partial is a wish, not a follow-up. The kit warns you when one is missing.
- The Dashboard is a read, not a deliverable. Don't optimise for the percentages — optimise for what they're surfacing. If "Personas updating" is 2/6, the answer is to talk to the four silent owners, not to ask them to fill the field.
The Queue inside the Conductor tab is where agent proposals appear for accept / amend / reject. Until a Coherence Layer agent runs continuously against your live tools, the queue is fed manually or by pasting LLM output using the documented schema. See Tier 6 — Custom Coherence Agent in Talk to Ruth.
Installation Playbook
A sequence of phases, not a calendar. Each phase is entered when its predecessor's success criterion is true and exited when its own is true — at whatever pace the team's reality allows. The phases name what to do, what to watch for, what tends to fail, and what success looks like. Move through them at the cadence your company can hold; pacing imposed from outside is the first thing that drifts.
The playbook assumes you have completed the Readiness Diagnostic, the Stakeholder Map, and Persona Mapping. If readiness scored below 18, do not start the playbook — fix what scored low first.
Drift Detection
A monthly scorecard for the five patterns that indicate the framework is being absorbed back into the old shape. Run this once Build is well underway and continue monthly. Catching a pattern early is fixable; catching it late is a re-installation.
This is the scorecard — a quick monthly read on whether each pattern is starting. The deeper read on every pattern — how to spot it, how to correct it, what causes it — lives in . Read those once when you install. Score this monthly. The agent-detectable triggers for each pattern live in .
CEO Coherence Scorecard
Quarterly self-assessment for the CEO. Eight questions about your own behaviour. The framework can be installed perfectly and still fail because the CEO never let go of being the decision-maker. This is the mirror.
The Signal Catalog
A specification of what a Coherence Layer agent is built to recognise. Thirty-five patterns across three tracks — operational, structural, coherence — written in framework vocabulary so an agent built around any tool stack can implement them. The catalog is the contract; the implementation is per-customer.
Read the preamble and Three tracks first — they define what counts as a signal in this catalog's sense, and how the three tracks differ. Then browse the patterns by track. Each pattern has the same shape: framework description, observable trigger, target, confidence rule, skip rule, notes.
The catalog is the authored content of the framework's agent layer. The implementation — the per-tool prompts, the schedulers, the per-customer extensions — is built in a Tier 6 engagement. See the bottom of this section for what Tier 6 produces against the catalog.
Preamble
The book introduces an architecture in which an agent watches every channel, surfaces signals, and proposes updates to a single Book of Record. The Conductor curates those proposals — accept, amend, reject. The Book of Record stays current because something is doing the watching.
This catalog defines what that something is built to watch for.
It is not a list of every event a tool can produce. Tools produce far more than the framework cares about, and an agent that surfaces everything is not an agent — it is a feed. The catalog is the filter. It names the small set of patterns that matter to the Coherence Layer, because each one carries a specific meaning inside the framework, points to a specific field of the Book of Record, and earns the Conductor's attention.
A signal, in this catalog's sense, has four properties.
It is observable — visible in a tool, in a transcript, in a log, in a state change. The agent can detect it without judgment.
It is interpretable — the framework gives it meaning. A ticket estimate doubling is not interesting because the ticket is bigger. It is interesting because the Builder's commitment may have shifted, which is a Selection-level fact whose home is the Book of Record.
It is targeted — the signal points to a specific field that should change. The catalog is precise about this. A Builder estimate slip targets personas.builder.now (and possibly risks if it threatens the Shipment date). It does not target personas.builder.commitment, which is set once at Selection and never edited.
It is actionable — the Conductor can do something about it. A signal that proposes no change, surfaces no question, and asks no decision is noise. The catalog excludes those by design.
Three things the catalog deliberately is not.
It is not a replacement for the Conductor. The agent surfaces; the Conductor frames; the room reveals. The catalog tells the agent what to surface. It does not tell the Conductor what to think. The book is precise on this — the Conductor holds no attachment, asks the question no attached person will ask, and is the only role that can tell whether what the agent saw is the question that matters now. Every signal in this catalog is a candidate for accept, amend, or reject. The catalog never overrides judgment.
It is not exhaustive. The framework speaks in vocabulary; this catalog translates that vocabulary into observable patterns. Every customer's stack will need additional patterns specific to their tools, their KPIs, their compliance regime. What the catalog provides is the shape — what a well-formed signal pattern looks like — so customers can extend it safely.
It is not the implementation. Every pattern below is described in framework terms, with one or two implementation illustrations to make it concrete. The full implementation library — every tool, every API call, every threshold — is built per customer in a Tier 6 engagement, against the customer's specific stack and the customer's specific Book of Record.
Three tracks
The catalog is organised in three tracks. The tracks differ in what they watch, how often they fire, and what part of the Conductor's working surface they feed.
The operational track watches the tools the personas work in — issue trackers, CRMs, compliance platforms, customer-success systems, marketing and design tools, communication channels. Operational signals fire frequently, often many times per day. They feed the Conductor's Queue. Most of this catalog is operational signals.
The structural track watches the framework's installation itself. It detects the five drift patterns the book describes — Convergence Point Erosion, Conductor Capture, Book of Record Fossilisation, Persona Collapse, Coherence Theatre. Structural signals fire slowly, often weekly or monthly. They feed the Drift Signals section of the Conductor's working surface. There are five.
The coherence track is the meta-layer. It watches the Book of Record itself, and the Queue that has been accumulating against it, and surfaces the cross-impacts a single-tool agent cannot see. Coherence signals require an agent that reads everything together — typically a single LLM call against current state. They fire on a daily or per-Convergence-Point cadence. They feed the Conductor's Queue, but with a distinct origin tag. There are eight.
The total catalog at v1 is thirty-five patterns. That number is deliberate. Fewer would leave gaps the Conductor would have to compensate for by hand. More would dilute the discipline that says every surfaced signal must be worth the Conductor's attention.
Track One — Operational Signals
Operational signals come from the tools the personas use to do their work. Each pattern below has the same shape:
- ·Pattern name. The signal's name in framework vocabulary.
- ·Framework description. What this pattern means inside the operating model. Why it matters.
- ·Observable trigger. What the agent watches for. One or two implementation examples.
- ·Target. Which field in the Book of Record the resulting proposal points at.
- ·Confidence rule. When the agent emits high, medium, or low confidence.
- ·Skip rule. When the pattern matches but should not be surfaced.
- ·Notes. Context the agent should hold while emitting.
The patterns are grouped by source category, because in practice each agent watches one source.
Issue tracker patterns
The issue tracker is the Builder's primary surface. It is also where Builder commitments crack first. An estimate that doubles, a blocker that appears, a ticket that has been "in progress" for three weeks — these are the early shape of a Selection-level commitment becoming unrealistic. The tracker also occasionally surfaces decisions and risks that should propagate into the broader Book of Record.
The most common operational signal in software organisations. A ticket that was scoped at one size is now visibly larger, and the Builder's now — what the Builder has committed they can deliver, by when — is no longer accurate to the field.
In Progress or In Review. Jira: status is past To Do. GitHub Projects: the ticket has been moved to a column past Backlog.personas.builder.now. Optionally also risks — see confidence rule.A ticket entering an active state has gained a dependency on something not yet ready — another ticket, an external party, a decision that has not been taken. The Builder has surfaced a real impediment, and the Book of Record's open field is the right home for it.
blocked label, a blocked-by link to another ticket, or a comment matching dependency-language patterns ("waiting on", "blocked on", "needs decision from"). Linear: the blocked-by relation is added or a blocked label applied. Jira: an is blocked by link is created.personas.builder.open. Optionally risks if the blocker has been outstanding for more than five working days.A new ticket has been created and tied to an Initiative whose Selection has already been committed. New work is appearing inside a contract that was supposed to be closed.
produce or later. The ticket is not a bug, not a follow-up to an existing ticket, and not in a backlog state.personas.builder.open initially. The proposal should explicitly ask whether this is a Selection-level scope change. If the Conductor accepts as a true scope change, it propagates to decisions.A ticket has been in an active state long enough that the framework should hear about it. Either work has stopped and the Builder hasn't said so, or the work was scoped wrong and never had a chance.
In Progress (or equivalent) for more than fourteen calendar days without a status change, comment, or commit reference. GitHub: no commits referencing the ticket ID in the last two weeks.personas.builder.now. The proposal asks whether the Builder's now still matches reality.The Builder is making a Selection-level decision in a comment thread, where the framework cannot see it. The decision belongs in the Book of Record.
decisions. The proposal asks whether this should be promoted from a Builder-internal decision to a logged Initiative-level decision.CRM patterns
The CRM is the Dealmaker's primary surface. Customer commitments live here, and customer commitments are framework signals — when an enterprise customer's renewal moves, when a deal closes contingent on a feature, when a champion changes role at the customer's company, the Book of Record needs to know. The CRM also occasionally surfaces resistance the Dealmaker is carrying that the room hasn't seen.
A deal in the pipeline has gained a condition tied to product delivery — most commonly, a renewal contingent on a feature shipping by a specific date. This is a hard schedule pressure that the Book of Record may not yet reflect.
change.resistance initially. If the Conductor accepts and the contingency threatens the Shipment date, propagate to risks and surface to Visionary, Builder, Storyteller.The Dealmaker has revised when a deal will land, and the revision crosses a framework-relevant boundary — moving into or out of the Initiative's launch quarter, or aligning explicitly with the Shipment date.
personas.dealmaker.now. If the deal is contingent (see O-6), the change also propagates to risks.A lost-deal record has been filed with a reason that names something the company does not yet build. The Visionary has a customer signal, in the book's exact sense — what we heard, from whom, how often.
closed-lost and the loss-reason field, or the closing notes, names a feature, capability, or product gap. The pattern looks for capability-language: "they wanted", "missing", "did not have", "competitor offered".personas.visionary.now for the Initiative the named capability is closest to. If no current Initiative is close, propose a new entry under selection.signal for an Initiative not yet selected.A customer who is contingent on or referenced in the Initiative has had their named contact change role, leave the company, or otherwise become unreachable.
selection.signal, in change.resistance, in operations.custom, or as a cited reference for the Initiative's signal.risks. The proposal names the change and asks whether the customer's commitment to the Initiative still holds.Compliance and security patterns
The Guardian's primary surface. Compliance platforms produce a particular kind of signal that the framework cares about — an obligation aging without resolution, an audit finding without a deadline, a deadline approaching without an owner. Each one is a Guardian risk that the Book of Record's risk register is the right home for.
A compliance control or audit item has been open longer than the framework tolerates without a named owner and a resolution date. The Guardian's open is becoming a Guardian risk.
at-risk or failing for ≥14 days. Jira security project: an issue with the security or compliance label and no assignee.risks. The proposal names the control, the days open, and that no owner is set.An audit or pen-test finding has surfaced something the product needs to change — not just a configuration, but an actual product behaviour. This is a Selection-level fact that the framework needs to see.
risks first. If the Conductor accepts as Selection-level, propagate to decisions with a question about whether the finding changes Initiative scope.A regulatory or audit deadline is within the Initiative's Shipment window, and the framework hasn't seen this surfaced yet.
risks or personas.guardian.now.personas.guardian.now. If the deadline is before Shipment with no margin, also risks.personas.guardian.now and the latest changed note references it. The agent should not re-surface what has already been surfaced.Customer success patterns
The Advocate's primary surface, and also one of the Visionary's. Customer success platforms produce the post-Shipment signals the framework cares most about — the adoption numbers, the escaped bugs, the NPS shifts that test the kill threshold from Selection. They also produce churn-risk signals before deals are formally lost.
A customer named or implicated in an Initiative has crossed a churn-risk threshold. This is the pre-cursor to O-9 — a champion still in role, but no longer happy.
risks. The proposal names the customer, the previous and new state, and asks whether the Initiative's customer-signal evidence still holds.operations.nps rather than risks.The Initiative is past Shipment and the adoption numbers are running below the kill threshold defined at Selection. Validation is approaching, and the room may not have noticed.
selection.success, selection.kill, and operations.adoption from the Book of Record itself.personas.visionary.now and operations.adoption. The proposal frames the question Validation will be asking, surfaced early.now has updated in the last seven days with reference to the metric. The agent yields to the persona's own attention.The Initiative has shipped, and the rate of customer-reported issues tied to the released capability is above whatever baseline the company tracks.
operations.bugs for tracking, personas.advocate.now for Advocate awareness.Storyteller and Marketing patterns
The Storyteller's primary surface is harder to define than the others, because narrative work happens across more tools — Notion, Figma, marketing automation platforms, the press kit. The patterns that matter are about the story being public before, during, and after Shipment.
A planned narrative asset — video, blog post, press release, customer page, sales deck — has not changed status in long enough that the Shipment date is at risk for narrative reasons.
change.comms or in the Storyteller's now) has not had a status change, edit, or comment in fourteen days. The Shipment date is within sixty days.personas.storyteller.now. The proposal asks whether the asset is on track or whether the launch comms timeline is at risk.now referencing the asset within the last seven days. Skip launch assets whose dependencies haven't shipped yet — there is no point chasing the press release before the feature works.The company's public messaging about the Initiative has shifted in a way the Book of Record hasn't seen yet. A blog post draft, a deck, a website page mentions the Initiative with different framing than selection.signal describes.
now or from the Initiative's selection.signal. This requires the agent to compare, not just detect.personas.storyteller.now. The proposal asks whether the public framing has evolved and whether the Book of Record should reflect it.selection.signal (the customer the signal cited, the metric the signal claimed, the urgency the signal asserted).Communication channel patterns
The hardest patterns to tune, and the highest-value when they work. Slack threads, email, meeting transcripts — the channels where decisions get made before the framework sees them. Coherence Theatre (the fifth drift pattern) is a structural-track signal of these channel patterns going untreated.
A persona has used decision-language in a public channel — committed to a path, named a trade-off, declared something out of scope — and the Book of Record's decisions log does not yet have it.
decisions. The proposal asks whether this should be promoted to a logged decision.Someone in the room is voicing concern about the Initiative, and the concern hasn't made it into risks yet.
risks. The proposal asks whether this concern should be logged.risks with the same owner. Skip rhetorical worry — "I'm worried we're being too conservative" is not a risk in the framework's sense.Someone in this Band has committed something to another Band — or vice versa — that the Book of Record's change.comms or decisions should reflect.
decisions or change.comms. The proposal asks whether this is a Band-level commitment that should be logged.The Initiative's named kill threshold is being discussed in a channel — usually because someone has noticed the trajectory and is voicing it.
selection.kill field. The agent reads the kill threshold from the Book of Record and looks for substring or numerical-comparison matches.personas.visionary.now. The proposal flags that the threshold is being discussed and asks whether Validation should hear of it.now or risks within the last seven days.Cross-tool patterns
A handful of signals are tool-agnostic — they fire when the same kind of thing appears across more than one source. The agent watching them is typically a coordinator that reads multiple tool exports together, or a per-tool agent with awareness of other tools' outputs.
A theme is appearing in multiple sources — the issue tracker, the CRM, the support platform — within a short window, even though no single source crossed its own threshold.
personas.visionary.now typically, with the proposal naming the theme and the sources.selection.signal — those are the Initiative working as intended, not a new signal.Track Two — Structural Signals
The five drift patterns the book describes are signals about the framework's installation, not about any specific Initiative. They unfold over weeks or months, not minutes. Each one has triggers that an agent can detect, and each one feeds the Drift Signals section of the Conductor's working surface — distinct from the Queue.
The five patterns and their agent-detectable triggers follow. The book's deep read on each pattern remains in the kit's Field Notes — the catalog only adds the agent-detectable trigger and the proposal text.
The Selection Point becomes a rubber stamp. No initiative has been rejected or sent back. Success criteria pass into Produce vague rather than crisp.
cps.held, the agent computes: percentage of items marked pass versus partial or fail; average duration of held CPs; presence of any rejected or sent-back proposals. Trigger when all of these hold simultaneously: zero rejections in the last quarter, average CP duration below 20 minutes, and over 90% of checklist items marked pass.driftSignals with pattern cp-erosion.The Conductor is no longer reading across personas; they are doing the work themselves. The role's value is collapsing.
dailyReads over the last fourteen days are predominantly status-tracking, problem-solving, or unblocking language rather than cross-persona reading. The agent reads the Conductor's actual dailyReads text and classifies. Trigger when over 70% of the last 14 days' reads classify as project-management language.driftSignals with pattern conductor-capture.weeklyMeetings.followups for "unblocking" within a fortnight.The Book of Record is no longer the current state of the Initiative. Persona sections are stale. Convergence Points run by reading other things.
now and changed. Trigger when the median age of the six personas' now fields exceeds fourteen days, or when more than two personas' changed fields are empty for more than two weeks.driftSignals with pattern bor-fossil.A persona is no longer being held distinctly. Their section of the Book of Record is being updated by another persona's owner, or it isn't being updated at all, and no one notices.
driftSignals with pattern persona-collapse.change.comms.Decisions are being made outside the room. The CPs are ratifying what was already decided. The Book of Record is updated, but the substance has left.
driftSignals with pattern coherence-theatre.Track Three — Coherence Signals
These are the signals a single-tool agent cannot produce. They require reading multiple sources together — the Book of Record, the accumulated Queue, the persona sections cross-referenced. They are the work the book describes as the Conductor's daily read, lifted into a meta-agent that runs once a day or before each Convergence Point.
There are eight, and they are higher-value per signal than any operational pattern. Each one is the kind of thing the Conductor would otherwise have to hold in their head.
Two personas' sections are saying things that cannot both be true.
now and changed fields and looks for contradictions — date claims that don't reconcile, scope claims that conflict, dependency claims one persona depends on that another denies.personas.[the persona whose claim is most likely wrong].now. The proposal names both claims and asks the Conductor which to believe.The accumulated accepted Queue items, read in aggregate, suggest the Initiative's selection.signal no longer matches what is being built.
personas.builder.now and personas.visionary.now, and compares the implicit Initiative shape against selection.signal and selection.success. Trigger when more than 30% of accepted updates implicitly redefine scope.selection.signal with the proposal asking whether Selection should be re-opened.Per O-3, a tally of scope additions per Initiative. When the tally crosses a threshold, the Conductor needs to be asked whether a Selection-level conversation is required.
selection.signal and decisions. The proposal frames the Selection-level question.Multiple customer-side commitments (per O-6, O-7) have clustered near or on the Shipment date in a way that turns the date from a target into a contract.
risks and change.resistance. The proposal names the cluster and asks whether the Shipment date has become commercially un-moveable.A Convergence Point is approaching, and one or more personas have not contributed material that the CP's checklist requires.
checklists and compares against the personas' now, changed, and commitment fields. Trigger when within seven days of a CP, any persona's section has not been updated in the last fourteen days.now. The proposal asks the Conductor to surface the absence.Per O-14, but operating across the Initiative as a whole rather than on a single metric. The agent reads selection.kill and all operations data, and surfaces whether Validation is going to be a clear call.
personas.visionary.now. The proposal asks the Conductor to clarify what the room will use to decide at Validation.A high volume of decisions appears to have been made (per O-18, O-20 and accepted Queue items targeting decisions), but the Book of Record's decisions log shows few formal entries.
decisions. The proposal lists the channel-decisions and asks the Conductor whether they should be promoted en masse.The Initiative's accumulated signals, read together, suggest a reversal — work that was on track is now off track, or vice versa, but no single signal has crossed a threshold.
personas.visionary.now. The proposal frames the reversal as a question, not an assertion.Anti-patterns
A short list of things that look like signals but are not. The agent should not surface these, and customer extensions to the catalog should not include them either. They produce noise that erodes the queue's discipline and the Conductor's attention.
A high volume of activity in a tool, by itself, is not a signal. Velocity is not coherence. A Builder shipping fifty tickets in a sprint is doing their job, not surfacing a framework concern.
A persona's section being short is not a signal. Concision can mean clarity. Length is not a quality measure for now or changed.
A persona being silent in a particular channel is not a signal unless that channel is named as their primary surface. The Storyteller not posting in the Builder's tracker is irrelevant.
A bug count rising during pre-launch QA is not a signal. That is QA working as designed. The signal is bugs escaping post-launch, which is O-15.
An initiative running over its original timeline is not, by itself, a signal worth surfacing. The framework's gates handle this — the Validation Point is where over-time becomes a Kill conversation. Surfacing slip every week between Selection and Validation produces a stream of useless agitation.
A decision the agent doesn't understand is not a signal. The agent's confidence rules exist precisely so that low-confidence noise does not enter the queue.
The same signal twice is not two signals. Deduplication is the agent's responsibility, not the Conductor's.
What the catalog deliberately does not cover
A few areas the catalog stays out of by design.
Customer-specific KPIs. Every company has metrics that matter to it specifically — a particular conversion rate, a particular cost-of-goods structure, a particular regulatory regime. The catalog provides the shape of how those become signals; the customer or Tier 6 engagement adds them by extension.
Industry-specific compliance and risk. Healthcare, financial services, defence procurement, and regulated industries all have signal patterns specific to them. The catalog covers the cross-industry compliance patterns; vertical-specific patterns are customer extensions.
Internal HR and people signals. Personnel changes, performance management, and team dynamics are explicitly outside this catalog. They are signals in the company's broader sense, but the framework's Conductor is not their right home. They belong in HR's surface, not the Coherence Layer's.
Financial and revenue signals not tied to Initiative commitments. General financial health is not a framework signal. Revenue against an Initiative's selection.success is. The catalog draws this line carefully.
Strategic signals outside any active Initiative. A market moving, a competitor launching, a regulatory environment shifting — these are real signals to a company, but the framework's unit is the Initiative. Strategic signals not pointed at any current Initiative belong in the Visionary's pre-Selection work, which the framework deliberately leaves unstructured.
These exclusions are the catalog's edges. A Coherence Layer agent that respects them will be useful and well-bounded. An agent that doesn't will turn into a feed.
Implementation notes for Tier 6
The catalog is the IP. The implementation is per-customer.
A Tier 6 engagement begins with the catalog and produces, against the customer's specific stack:
The per-tool agent prompts that translate each pattern in the catalog into an LLM-callable instruction set, parameterised against the customer's tool schemas. There will typically be one prompt per tool category, with the operational patterns relevant to that source.
The scheduling and infrastructure that runs each agent at the appropriate cadence — operational signals on a fast cadence (hourly to daily depending on the tool), structural signals on a slow cadence (weekly to monthly), coherence signals before each Convergence Point.
The customer extensions to the catalog — the company-specific signal patterns that the catalog deliberately does not cover. These are produced collaboratively in the engagement and remain the customer's intellectual property.
The observability and tuning loop. The Conductor's reject rate per pattern is the tuning signal. A pattern with a reject rate above 30% in its first month is poorly tuned. A pattern with a reject rate below 5% has either fired too rarely to know, or — concerning — the Conductor has stopped reading carefully. The Tier 6 engagement includes a quarterly tuning review where the patterns are evaluated against their reject rates and the customer's evolving operating model.
This catalog, version 1, represents the framework's authored content as of May 2026. It will evolve. Subsequent versions will add patterns, retire patterns that proved unworkable, and refine confidence rules based on what customers' Conductors actually accept and reject. The version history will be tracked deliberately, because the framework's evolution is part of the offering.
End of Signal Catalog v1.
Every pattern in this catalog produces a signal in the same JSON shape — the agent contract. To see the schema and the ready-made LLM prompt, open any Initiative's Conductor's Queue and click "View schema & example prompts."
For a custom agent built around your specific stack, with the catalog operationalised continuously against your live tools — see .
Politics & Problems
The framework is not a logistical project. It is a quiet redistribution of authority. Until that is named, the people whose authority is moving will not know they are resisting something. They will only know that the new model feels off — and they will find sincere, plausible reasons to slow it down.
This section is not interactive. It is the part of the kit you read when something is going wrong and you cannot name what. Most installation failures are political, not operational — and most of them are recognisable in advance if you know the shape of them.
What people say vs. what people protect
Every objection has two layers. What is said: "this adds process," "we already do this," "it will slow us down." What is protected: my authority to start things without asking, my team's exclusive claim on a domain, my ability to ship without commercial sign-off, the visibility I get from controlling the roadmap, my informal role as the company's coherence-holder.
Both layers are real. Treating either as the whole story is what gets transformations stuck. Answer the surface objection without seeing what is being protected, and you win the argument and lose the person. Name what is being protected without acknowledging the surface, and you sound like you are accusing them of bad faith. The work is to do both — acknowledge the legitimate version of the surface concern, then address the underlying interest directly enough that the person feels seen but not exposed.
The five archetypal blockers
Across enough installations, the same five archetypes appear. Not villains — each is responding to a real concern from inside their own role. The PMO Defender protecting their work. The "we already do this" CTO pattern-matching to the last framework that came and went. The Demoted PM hearing "Visionary" and reading it as title shrinkage. The Founder who agrees in the room and reverses in private. The Middle Manager who erodes by absence rather than confrontation.
The deep read on each of these — surface objection, what's actually being protected, what tends to land, what tends to harden them — is in . Read those once before the first stakeholder conversation. Recognising them early is the difference between resistance you can work with and resistance that quietly compounds.
Five drift patterns that swallow installations
Most installations do not fail dramatically. They fail by transforming into something else. There are five recognisable patterns the framework drifts into over months 6–18 — Convergence Point Erosion, Conductor Capture, Book of Record Fossilisation, Persona Collapse, and Coherence Theatre. Each one starts subtly and compounds. Each one has a specific signal that catches it early and a correction that works.
The deep read on each pattern is in . The monthly score on whether each pattern is starting belongs in . Read the patterns once. Run the scorecard monthly.
KPIs & Measurement
What to measure, what not to measure, and the trap most installations fall into. Coherence has its own measurements — they are not the same as productivity, velocity, or output.
The most common KPI mistake in a coherence installation is using the framework's vocabulary while still measuring the previous regime's outputs. You install Selection Points and continue to track features-shipped-per-quarter. You name a Conductor and continue to track engineering velocity. The framework is then measured by metrics that are blind to what it actually changes — which means it appears to be doing nothing while in fact it is fixing the things those metrics never showed.
Measure these
The five measurements below are coherence metrics. They are about whether the framework is doing its job — whether decisions are holding, whether conflicts are surfacing, whether validation actually happens.
1. Selection-to-Validation rate
Of initiatives that passed Selection in the last quarter, what percentage hit their Validation Point on the originally committed date? Not "has Validation happened yet" — was it on the date set at Selection. Target: 80%+ at month six. Below 50% means Selection is not setting realistic dates, or Validation is being skipped.
2. Kill rate at Validation
Of initiatives that reach Validation, what percentage are killed or substantially evolved versus simply continued? A healthy installation has a 20–35% kill rate. Zero kills means Validation is theatrical. Above 50% means Selection is not doing its work.
3. Conflicts surfaced at Convergence Points
Count the number of explicit disagreements named in the room at each Convergence Point. Track the trend. A healthy installation surfaces 2–5 conflicts per Selection Point in the first months, dropping to 0–2 as the team learns to surface earlier. Zero conflicts ever is the warning sign — the framework is performing, not operating.
4. Time-to-decision-reversal
When a decision made at a Convergence Point is reversed, how long until the reversal is visible to everyone affected? Target: same week. Reversals that take a month to surface are the signature of Coherence Theatre — decisions are happening, but the Convergence Points are not the channel they pass through.
5. Conductor handoff index
What percentage of Convergence Points in the most recent month ran without the CEO physically present? Target: 60%+ by month four. Below 40% means the framework is in danger of becoming Conductor Capture in reverse — the Conductor cannot hold the room without the CEO standing behind them.
Don't measure these
These metrics will all look reasonable but actively work against the installation.
- Number of Convergence Points held. Easy to game. Rewards ceremony.
- Number of personas filled in the Book of Record. Rewards completeness over truth.
- Velocity, story points, features shipped. Not what the framework changes. Track them separately if you must, but don't tie them to the installation's success.
- Survey-based "framework adoption" scores. Measures comfort, not coherence. People learn to give the right answers.
- Conductor-led metrics dashboards. Conductor's job is not to produce reports. The moment the Conductor is producing weekly metrics, they have become an analyst.
What old metrics map to what
If you are coming from an OKR or KPI culture, here are the most common mappings. The old metric on the left tends to be replaced — or quietly demoted — by the coherence metric on the right.
How to introduce coherence metrics without dropping the old ones
You cannot retire the old metrics on day one. The board, the investors, and most of the senior team are still using them. The trick is to track them in parallel for the first two quarters — the old metrics for external reporting, the coherence metrics for internal review. By month six the senior team should be reaching for the coherence metrics first when asked "how is it going." By month nine, the board can be introduced to one or two of them.
The coherence metrics that translate best to a board are kill rate at Validation (which boards love because it is evidence of discipline) and Selection-to-Validation rate (which boards love because it is a predictor of forecast quality).
If a board member asks for a single metric to track the installation, give them kill rate at Validation. It is the hardest to fake, the most informative, and the one that directly reflects whether the framework is doing its job. Resist the pressure to give them an "adoption score" — adoption is not the goal. Coherence is.
Talk to Ruth
If this kit opened doors, here is how to take it further. Most readers will not need a follow-up — and the ones who do usually know it by the time they reach this page.
The book and this kit together are meant to be enough for most teams to install the framework, run the playbook, and adapt it to their company. The structure is here. The patterns are here. The hard conversations are scripted.
But there are three situations where a conversation tends to compress months of work into hours.
1. The diagnostic surfaced a disagreement at the top.
Two senior leaders scored the readiness diagnostic and disagreed on three or more questions. That disagreement is the most useful information your senior team has — and the hardest to work through alone. A single facilitated conversation, run with the diagnostic in front of everyone, often resolves more than weeks of meetings.
2. The framework is installed but something is off.
You are partway through Build, or several months past Shipment, and one of the failure-mode signals from the Politics section is starting to show. You can see it but you cannot quite name it, and you do not want to discuss it with the people inside it. An outside conversation — half-day or one-day — usually surfaces what the room cannot.
3. You are about to start and you want to walk through it once.
You have read the book, completed the diagnostic, and are about to begin Phase 1 of the playbook. A 90-minute call to walk through your specific stakeholder map, persona coverage, and chosen sequencing — and to name the three things most likely to go wrong in your company — is usually the highest-leverage hour you will spend in the whole installation.
The six tiers
One 90-minute call. You bring the questions; I bring the framework and the patterns. Best for a CEO or COO walking into installation, or a senior team that has read the book and wants to pressure-test their plan once before starting.
Run the readiness diagnostic with your senior team, work through the disagreements, build the stakeholder map together, and produce a one-page installation plan tailored to your company's specific situation. Ends with a senior-team session where the plan is presented and committed to.
I work alongside your COO or chosen Conductor through the full Naming, Selection, Build, and Shipment phases of the playbook. We design the first Band together, run the first Selection Point and Shipment Point jointly, debrief regularly, and hand off cleanly once Shipment has held and adoption tracking is running. The first Validation Point sits beyond this window — reading the kill threshold honestly takes whatever time the data needs — and your Conductor runs it without me. The handoff is at the operating rhythm, not at Validation itself.
For companies past the first Band, expanding to two or three more. The political topology is different at this stage — the Coherence Layer becomes the leadership team, and the failure modes shift. We co-design the multi-Band model, install the second and third Bands, and build the company-level Coherence Layer.
For companies treating coherence as a multi-year operating-model shift. Embedded engagement, board-level reporting cadence, and the work of redesigning compensation, governance, and external reporting around the framework. Rare but where it goes deepest.
The framework, operationalised as a custom AI agent system inside your company. Designed and built together — six specialist agents mapped to the six personas, an orchestrator playing Conductor, the Book of Record as shared state, the Convergence Points as scheduled rituals. The system reads your actual Book of Record continuously, surfaces drift the moment it forms, prompts the right human at the right time, maintains the decision log and risk register, and produces the weekly Conductor's agenda automatically.
What it is not: a Conductor replacement. It does not make decisions. It does not run Convergence Points. It surfaces, prompts, tracks, and reports — so the humans in the room can spend their attention on judgment rather than on remembering what to ask.
Why this is different from generic AI tooling: the agent is built around the framework's vocabulary and structure — personas, Convergence Points, the Book of Record, drift patterns, override naming. It does not need to be taught what coherence means. It already knows.
How this connects to what you've already done in the pilot: the Conductor's Queue you have been running — pasting LLM output into, deciding accept/amend/reject — is the contract Tier 6 implements continuously. The schema is the same. The decisions are still yours. What changes is that the agent is wired to your live Linear, Salesforce, Slack, Notion, your data warehouse — surfacing the moment drift forms rather than the morning after.
A new offering, currently in design with founding customers. If your installation has reached the point where the Conductor is the bottleneck — or where you want the framework to keep operating reliably as the company scales — this is the conversation to have.
If something here opened a door,
let me know.
Write to me with what you filled out, what you found surprising, what is currently in your way — or any idea worth sharing. Information about the engagements, or just a conversation about the framework, are equally welcome.
A note. The kit saves your work locally — none of it ever leaves your device. If you want to bring something from the kit into a conversation, use Export work in the sidebar to download a JSON of everything you have filled in. You can send that to me, share with your team, or simply keep it for yourself.
Book of Record (Excel)
One Excel file. Nine tabs that mirror the Book of Record inside this kit. Create one per initiative — that is the artifact your team actually fills in, prints, and shares.
A clean Excel workbook with the same structure as the in-kit Book of Record. Save as BoR_[Initiative_Name]_[YYYY-MM-DD].xlsx for each initiative.
The Book of Record is the framework's central artifact — the complete record for one initiative. The version inside this kit is for thinking, exploring, and trying out the structure. The Excel file is for actually running an initiative — what your team fills in, week to week, and reads aloud at every Convergence Point.
Two things to know:
Each initiative gets its own Book of Record. That is by design — the framework treats each initiative as a separate piece of work with its own Selection contract, its own personas' commitments, its own Convergence Points, its own kill threshold. Mixing two initiatives into one file is the most common way the discipline silently softens.
The tabs in this Excel are the same as the tabs inside any initiative's Book of Record in the Your company tree on the left: Overview · Personas · Convergence Points · Change Mgmt · Conductor · Operations · Decisions · Risks · Timeline. The Personas tab includes a deliverables link field per persona — point it at the Jira epic, Linear project, Figma file, or Notion page where that persona's actual work lives.
What's in the file
Nine tabs. Each one mirrors the equivalent panel inside this kit's live Book of Record. Brand-styled to match — gold uppercase labels, italic prompts, bordered fillable cells. Dropdowns where they help (status fields on the Risks log, Pass/Partial/Fail on Convergence Point checklists, drift pattern names on the Conductor tab).
| Tab | What it holds |
|---|---|
| Overview | Initiative metadata — name, owner, Conductor, status, Selection / Shipment / Validation dates, kill threshold, success threshold. The contract for this initiative. |
| Personas | Six persona sections (V / B / G / D / S / A), each with owner, commitment at Selection, where I am now, changed this week, open questions, and deliverables link (URL where the actual work lives). |
| Convergence Points | Log of held CPs plus the master checklists for each type (Selection 8 items, Shipment 7 items, Validation 7 items) with Pass / Partial / Fail dropdowns, due dates, and named responsibles for partials. |
| Change Mgmt | Political impact of this initiative, communications log (when, audience, message, messenger, channel, status), resistance log (surface vs. what's protected, mitigation, status). |
| Conductor | Daily reads, weekly meeting notes, drift signals (which of the 5 Drift Patterns is starting, what was observed, status, correction). |
| Operations | Adoption, escaped bugs, NPS / customer signal, custom metrics. The numbers that feed Validation against the kill threshold. |
| Decisions | Running log of decisions taken — date, decision, by whom, in what forum, with rationale. |
| Risks | Risk register with owner and mitigation. Status: Open · Monitoring · Mitigated · Hardened · Closed. |
| Timeline | Manual timeline notes — customer calls, milestone moments, external events that affect the work. Append-only. |
The Your company tree on the left is for working inside this kit — exploring the structure, trying out persona commitments, seeing how the parts connect. Auto-saved locally to your browser. Useful for first reading and for solo prep before a meeting.
The Excel file is for actual operation — what your team fills in together, what gets shared in your company drive, what gets read aloud at Convergence Points. Most teams settle into using the in-kit tree for first reading and the Excel file for ongoing operation.
The Five Blockers
Every installation faces the same five archetypal blockers. Each one has a surface objection that's not the real one — and an underlying concern that mitigations have to address. The pattern isn't whether you'll meet them; it's whether you recognise which one you're meeting.
For each blocker: the surface objection (what they say), what's actually being protected (the underneath), what tends to land (mitigations that address what's protected), and what tends to harden them (well-intentioned moves that make it worse). When you recognise a blocker, work the underneath, not the surface.
This is the deep read. The political frame around it — why every operating-model change reads as a power redistribution, even when it isn't — lives in . Read that first if you haven't yet.
Usually the COO, Chief of Staff, or PMO leader. Has spent years building the operating cadence the company runs on today. Sees this as a threat to the system they own.
Senior engineering leader. Often three-time-CTO. Has seen Lean, SAFe, OKRs, NoEstimates, RICE prioritisation. Pattern-matches this to the last framework that came and went.
A product manager who hears "Visionary" and thinks: that's my job, but now there's a Conductor above me, and a Storyteller eating part of my role. Feels demoted by the framework's vocabulary.
Founder/CEO. Agrees in the room. Reverses in private the next day. Or in front of the next investor. Or in front of a customer who pushes hard.
Functional middle manager. Doesn't openly object. Just doesn't show up to Convergence Points fully prepared. Or sends a deputy. Or "couldn't get to the Book of Record this week." Erodes by absence rather than confrontation.
25 Objections Handbook
The most common objections, organised by who says them. For each: what's actually being asked underneath, and the response that lands. Most objections are not problems to be solved — they're requests to be understood.
Objections are not arguments — they're invitations. Each one is a person asking "do you really understand my situation?" The response that lands is the one that names what's underneath. The response that hardens is the one that defends the framework.
From the CEO (5)
From Engineering Leadership (5)
From Product (5)
From Sales / GTM (5)
About the Conductor (5)
5 Conversation Scripts
The five hardest conversations in any installation. Word-for-word language for each — to be adapted, not read. The point is not the exact phrasing, but the moves each script makes: what to name, what to leave unsaid, where to invite, where to hold.
These are templates for hard moments, not magic words. Adapt them to your voice. The hard part isn't language — it's holding language while the person you're talking to is uncomfortable. The scripts try to give you something to hold onto.
First leadership meeting where you're naming the Conductor. The room may hear it as a power move. The script's job is to land the role's function before it gets read as politics.
"There's a role I want to name today, and I want to be clear about what it is and what it isn't.
We've been operating with a hidden Conductor — me, in most rooms. Holding cross-impacts in my head. Catching the contradictions between what product committed to and what sales is selling. Most of the time it works, sometimes it doesn't, and increasingly it doesn't scale.
Lena is going to hold the Conductor role for the Editor Core Band. What that means: she reads across all six persona sections of the Book of Record daily, surfaces drift between them, and runs the weekly Band meeting. What it does not mean: she does not decide. She does not overrule. When personas disagree, she makes sure we see the disagreement, name it, and resolve it knowingly — but the call is still ours.
She's equal in voice with the rest of you. Different in function. Six players, one Conductor — same room, different work.
If something feels like a power move from this — say so directly. To me or to her. The role only works if it doesn't accumulate authority by accident."
Watch for: the senior person who nods publicly and goes quiet privately. Follow up with them within 48 hours.
VP Engineering hears "you're the Builder for the Editor Core Band" and reads it as demotion — "I run engineering, not one team's build." The script's job is to clarify what's also still theirs.
"You still run engineering. Nothing in the framework changes the org chart. What I want to be specific about is: which engineering judgment shows up in which room.
For Editor Core, you hold the Builder persona. That means you're in the room at every Convergence Point for any initiative inside that Band. You commit to technical readiness. You sign the architecture decisions. The Builder is your judgment, named.
For other Bands, you'll appoint Builder owners — likely your senior architects or tech leads — and they hold that persona for those rooms. You don't sit in every Band's CPs. That's the point. Your time goes to the rooms where the technical commitment is yours; for the rest, your senior team carries that judgment.
Across the company, you still run engineering. You hire, fire, set technical strategy, allocate resources between Bands. That doesn't move. The framework tells the company whose judgment is whose for any given decision — it doesn't tell you how to run your function."
If they're still uneasy: "What feels like it's moving that you don't want to move?" Listen for the actual concern, not the surface one.
The Validation reading shows the kill threshold was met. The team is attached. The CEO is in the room. The Conductor's job is to hold the criteria — not soften the moment.
"At Selection, we wrote: 'If by 120 days, fewer than 15% of paid accounts have used the feature AND trial conversion has not improved by 2 points, we retire.' I'm reading that aloud now because we agreed at Selection that it would be read aloud unedited.
It's day 121. Adoption is 11%. Trial conversion has moved 0.4 points.
Both numbers are below threshold. By the criteria we set, we retire.
Before we move to retirement plan, I want to say something the framework asks me to say: the team did the work. The numbers being below threshold is information about the bet, not about the team. We made a Selection that turned out to be wrong. That's what Validation is for — to catch this before it becomes a year of zombie maintenance.
If the room wants to argue Evolve instead of Kill, the bar is: name the specific change to the bet that would get us to threshold, and the new Validation date. 'More time' is not Evolve; it's Keep with a softer threshold, and we agreed not to do that.
Builder, what does retirement look like? Advocate, what's the customer-comms? Storyteller, what's the public narrative?"
If the CEO pushes for Keep without meeting the Evolve bar: "I hear you. I want to make sure we log this as a CEO override, not a Validation outcome — that's how the framework holds." Most CEOs back off when faced with logging.
The founder/CEO has a thing they want done. The Selection Point reveals a persona who can't commit. The Conductor has to hold the line — without humiliating the founder.
"Diana, I want to come back to what you said. You said you can't commit to the security review timeline as scoped. The Selection Point can't close until every persona can commit. That's the rule we agreed to.
Diana, what would you need to be able to commit?
[Diana names what she'd need.]
Sarah — that affects scope. Marcus — does this change your commitment? Tom — does the customer commitment we've made to Globex still hold if we shift on this?
[Round-robin. Either the room reshapes the Selection in real time and re-commits, or one persona still can't commit.]
[If the room can't reshape:] We don't have a Selection. The work doesn't start today. We can pick this up next Tuesday with the changes in scope, or we can name an alternative initiative for this window. Either is fine — but we don't pass a Selection Point with an unreconciled commitment, because we agreed not to.
[To the CEO, after the meeting:] I know this is the project you wanted greenlit. It's not killed — it's not selected today. There's a difference. If you want, we can talk through what the path to Selection looks like."
The Conductor's job is to make the no about the criteria, not about the founder. If the framework holds here, it holds everywhere. If it bends here, it never holds.
Rare. The mid-installation reset reveals the conditions aren't right — too much resistance, too little sponsorship, the wrong first Band. Continuing would damage the framework's credibility for years. Pausing is legitimate. The script's job is to do it without humiliation.
"I want to share what I'm seeing, and propose we pause this installation for now.
What I committed to at the start was: by week 12, we'd see real Convergence Points running with personas committing in front of each other. What we have at week 12 is: meetings being held, the language being used, but the moments of actual commitment — where someone says 'I can't commit to my part as scoped' — aren't happening. We're using the framework as a vocabulary, not as an operating discipline.
I think there are three things underneath that. [Name them honestly. E.g.: the first Band is too cross-functional and authority is unclear; the senior team hasn't backed the Conductor visibly; we're trying to install during a reorg that has eaten attention.]
My recommendation is: we pause the formal installation. We continue using the framework's vocabulary — Selection, Validation, Conductor — because that's already added clarity. We don't pretend we're running it. We come back to a real installation in [Q2/H2/after the reorg]. Some teams will push for "let's just do it half-way" — I think half-way installation does worse damage than honest pause.
I'd like the senior team's read on whether you agree with what I'm seeing."
Pausing well preserves the framework. Pushing through a doomed installation kills it for a generation.
The Five Drift Patterns
Once installed, the framework drifts. Not because of bad intent — because of entropy. Five recognisable patterns. Each one: how to spot it early, how to correct it, what tends to cause it. The Conductor's deeper work over time is watching for these.
This is the deep read on each pattern — read once when you install the framework, then come back when something feels off. The monthly score on whether each pattern is starting belongs in . Read these pages slowly; the score is fast.
The drift patterns show up in months 6–18, when the installation has stopped being new and the discipline starts to soften. The surfaces — from the CEO's side of the mirror — which of these is starting.
The Selection Point becomes a rubber stamp. The Visionary presents, everyone nods, the work passes. Within six months, no initiative has been rejected or sent back. The criteria are technically answered but never genuinely challenged.
The Conductor stops being the cross-coherence reader and becomes the project manager. They start tracking deliverables instead of cross-impacts. They start solving problems instead of surfacing them. The role's value collapses.
The Book of Record was a living document at the start. Now it's frozen at Selection. Persona sections haven't been updated in weeks. The "Where I am now" fields are months old. The Book has become an archive of decisions, not a record of current state.
Two personas merge. Usually: the Storyteller gets absorbed into the Visionary (or back into Marketing, outside the Band). Or: the Guardian gets absorbed into the Builder. Or: the Advocate becomes a function of CS-leadership and stops being in the room. The Band now has 5 personas instead of 6.
The hardest one to spot, because everything looks right. The rituals run. The Convergence Points happen. The Book of Record is updated. The Conductor is in place. But the substance has left. Decisions are made elsewhere — in Slack, in 1:1s with the CEO, in the parking lot — and the Convergence Points ratify what was already decided.
Saving & data
How your work is stored, how to keep it safe, and what this kit is — and isn't — meant to be.
This page covers how your work is stored, how to keep it safe across browser sessions, and what to do after the pilot. The framing of what this kit is — and is not — lives in ; if you skipped it, read it once before getting deep into the work.
How your work is saved
Everything you fill into the Your company branch is saved automatically to your browser's local storage on this device. Nothing is sent anywhere. Nothing is shared with Ruth, with Anthropic, or with anyone else.
This has two implications you should know about:
How to save your work safely
- Export work (button in the sidebar footer) downloads a complete JSON of everything you have filled in. Save this somewhere durable — a Notion page, a Drive folder, a Git repo, an email to yourself. The first time you do this, decide where it lives, and stick to that location.
- Re-export weekly while the pilot is active. The Book of Record changes constantly during Produce — daily reads, weekly meetings, decisions, risks. The version you exported two weeks ago is already stale.
- Before any major change (a new browser, a new laptop, a clearing of cookies), export. The exported JSON is enough to fully restore your state if needed.
- If you want others on the team to see the Book of Record, the simplest path right now is: export the JSON, and share a snapshot. Real multi-user editing is a Tier 6 conversation, not a kit-level capability.
After the pilot
The point of running the pilot using this kit is to learn — concretely, in your specific company — what coherence management actually requires. You will discover which of the framework's sections matter most for your operation, which need adapting, what is missing, what is overkill.
Once that learning is in hand, the kit has done its job. What comes next:
- Adapt the operating model. The framework gives you the architecture; your company tells you which beams need reinforcing. Your second pilot, on a second Band, should already feel different from the first.
- Choose where the real coherence layer lives. The Conductor's Queue gives you the contract; the agent feeding it is your choice. Today, most teams paste LLM output into the queue manually using the schema. Once the rhythm is real, the agent runs continuously — either as a flow inside the tools you already use (a Notion automation, a Slack bot, an n8n pipeline) or as a custom system built around the framework's vocabulary (Tier 6).
- The framework outlives the kit. The personas, the Convergence Points, the Book of Record, the Coherence Layer — these stay. The web page is just the scaffolding to get you there.
For the conversation about what comes after the pilot — adapting the model, building the real coherence layer, or commissioning a custom agent system — see Talk to Ruth.