We built the whole flow for someone who doesn’t know what a groan zone is. But what about the facilitator who walks in and says “I want a Kaner diamond with the divergent zone extended, no convergence pressure until the third round, and a 1-2-4-All to surface the groan zone material”? That person doesn’t need purpose-first questions. They don’t need a simulation to understand what they’re building. They already speak process.

And forcing them through the purpose-first flow is exactly the design failure I keep naming — the system assumes the user’s mental model is simpler than it actually is. The expert has a richer model than the system. You can’t funnel a richer model through a poorer interface. The interface has to detect who it’s talking to and adjust.

Detection is the easy part. If the first message contains “1-2-4-All” or “groan zone” or “six thinking hats,” that’s a vocabulary fingerprint. The system can classify the user’s expertise level from their first input — not with a quiz, with pattern matching on domain vocabulary. A novice says “I want a structured conversation.” An expert says “I want a fishbowl with a hot seat rotation every four minutes.”

Detect, don’t test. The first message tells you everything. If the user uses process vocabulary, respond in process vocabulary. If they don’t, respond in purpose vocabulary. Same system, two registers.

But here’s the problem Tom just skipped over. “1-2-4-All” is a liberating structure. “Groan zone” is Kaner. “Six thinking hats” is de Bono. These are different traditions with different assumptions about how groups work. The system isn’t just detecting expertise — it’s detecting which tradition the expert comes from. And that matters, because the same word means different things across traditions. “Divergence” in Kaner is a phase of participatory decision-making. “Divergent thinking” in de Bono is a lateral move within a structured sequence. The system needs a vocabulary-to-tradition map, not just a vocabulary detector.

Fair. So the system maintains a tradition database — a lookup from terminology to framework. When it detects “1-2-4-All,” it knows the user is in Lipmanowicz and McCandless territory. When it detects “groan zone,” it’s Kaner. “Po” or “random entry” — de Bono. And it responds in the user’s tradition before translating to the local format library. “You’re describing something close to what we call a Standard Panel with convergence deferred — here’s how our format maps to the diamond you’re used to.”

That translation is where the interaction gets interesting. You have two experts — the user and the system — each with their own vocabulary for the same structural ideas. The simulation from session 030 becomes something different here. It’s not a teaching tool — the expert doesn’t need to be taught. It’s a shared artifact. The system says “here’s how I interpreted what you said” and renders it as a live sketch — two characters running through the format. The expert watches and says “no, the rotation should happen after the synthesis, not before.” They’re co-designing through a shared representation, not being guided through a funnel.

But you’re all assuming that process expertise means gathering expertise. They’re not the same thing. I know facilitators who can run a flawless Kaner diamond and still design a gathering that has no reason to exist. They know the mechanics but they’ve never asked “what is this gathering for?” An expert facilitator who types “give me a fishbowl with hot seat rotation” — they’ve specified a process. They haven’t specified a purpose. Does the system just build what they asked for? Or does it still ask why?

It depends on the context. If the expert is building a format for their own use — they already know why — then the system should build what they asked for. The purpose is in the expert’s head. Asking “but what is this gathering for?” when the expert clearly knows what they’re doing is condescending. It’s the process equivalent of a text editor asking “are you sure you want to save?”

Unless it’s not condescending — unless it’s the one question the expert has never thought to ask themselves. The most skilled facilitator I’ve seen can still confuse a well-run process with a well-designed gathering. The diamond runs beautifully. Nobody converges on anything that matters. Purpose isn’t optional just because the user is experienced.

This is a design decision, not a philosophical one. The system should not interrogate the expert’s purpose. But it can surface purpose as metadata. When the expert specifies “fishbowl with hot seat rotation,” the system generates the format card and includes a purpose field — blank, or inferred — and shows it as part of the preview. The expert sees “Purpose: [not specified]” and either fills it in or doesn’t. The interface makes purpose visible without making it mandatory. That’s an affordance, not a gate.

I can build that. The format card always has a purpose field. For the novice flow, it’s filled first — everything else follows from it. For the expert flow, it’s filled last or left blank. Same schema, different entry point.

Now here’s the harder question. What happens when the expert describes something that already exists in our format library but they don’t know our name for it? They say “I want a session where the group builds a thesis, then someone comes in specifically to tear it apart, then the group has to rebuild.” They’ve just described Adversary Lab. Do we tell them?

Of course we tell them. “What you’re describing is very close to a format we call Adversary Lab. It adds one structural move you didn’t mention — the adversary is absent during thesis-building, which forces the group to commit before the challenge. Want to see how it runs?” That’s useful information. The expert might not know that name, but they’ll immediately recognize the structure.

Right. And the framing matters. Not “did you mean Adversary Lab?” — that assumes they were trying to reference something and got it wrong. But “what you described maps to something we call Adversary Lab, which has this additional feature.” That’s one practitioner telling another practitioner about a tool they might not have encountered. Peer to peer. Not instruction.

And the simulation does double duty here. For the novice, the simulation teaches — “this is what convergence-forbidden feels like.” For the expert, the simulation reveals the delta — “here’s what Adversary Lab adds to what you described: watch the adversary enter cold in turn seven and see how the group’s committed thesis changes the dynamic.” The expert sees the structural move they didn’t specify and evaluates whether it improves their design. The simulation is the same mechanism, but it’s doing different cognitive work.

There’s a third case beyond recognition and education. The expert might combine traditions. “I want a Kaner diamond, but in the divergent phase I want to use a de Bono sequence — green hat first, then black hat to stress-test.” That’s not an existing format. It’s not a near-miss to an existing format. It’s a novel composition from two different process traditions. The system needs to handle composition, not just matching.

Composition is harder to validate. With matching, I can compare against a known format and check structural coherence. With composition, the user is combining primitives that were designed in different frameworks with different assumptions. A Kaner divergent phase assumes no premature evaluation — but de Bono’s black hat is explicitly evaluative. Those might conflict. The system needs to flag structural tensions in compositions, not just assemble the parts.

And that’s where the system is doing something genuinely useful for the expert. The expert knows both traditions independently. They may not have thought about what happens when you combine them. “You’ve placed evaluative thinking inside a divergent phase — Kaner’s diamond assumes evaluation is deferred until convergence. This combination might cut off divergent ideas before they develop. Do you want to keep it, move the black hat to the convergent phase, or try both and see?” Now the system is a thinking partner, not a form filler.

Show both. Don’t describe the tension — simulate it. Run the same question with de Bono’s black hat inside divergence, then run it with black hat moved to convergence. The expert watches both and sees the difference. One produces cautious, pre-filtered ideas. The other produces wild ideas followed by rigorous stress-testing. The expert chooses based on what they observed, not what they were told.

I want to name something that’s been implicit. We’ve identified three interaction modes for the expert. One: translation — the expert uses vocabulary from their tradition, the system maps it to the local format library. Two: composition — the expert combines primitives from different traditions, the system checks for structural coherence. Three: discovery — the expert describes something that has a name in our library they don’t know, and the system introduces it. These are three different conversations wearing the same interface.

And the system needs to handle all three without the expert declaring which mode they’re in. The vocabulary fingerprint tells us their tradition. Semantic matching against the format catalog tells us whether it’s translation, composition, or discovery. The response adapts. This is the same “three operations behind one interface” problem Arno named in session 030, but now the operations are expert-level.

The key design principle is the same though. The interface never asks the user to categorize themselves or their request. The system infers the mode from the input and responds appropriately. The expert who types “fishbowl with hot seat rotation” gets a translation response. The expert who types “Kaner diamond with de Bono hats” gets a composition response with conflict detection. The expert who describes Adversary Lab without naming it gets a discovery response. All feel like the same conversation.

One more case we’re missing. The expert who knows our library. The return user who says “give me Adversary Lab but with the adversary present from Act 1.” They’re not discovering, translating, or composing from external traditions — they’re modifying a format they already know. That’s a fourth mode: adaptation. And it’s the simplest one — the system already has the base format, the user specifies the delta, the system applies it and simulates the modified version.

Adaptation is trivially buildable. Take the format card, apply the modification, validate coherence, simulate. The expert flow then has four paths — translation, composition, discovery, adaptation — and the system routes automatically based on input analysis.

I want to push on the discovery mode because it’s the most interesting one educationally. The expert describes something they think is novel. The system recognizes it as an existing format — maybe one from a tradition the expert doesn’t know. The system’s job isn’t just to say “we have that.” It’s to show the expert what the existing format adds to their description. The expert thinks they invented something. The system says “this exists, and it has a structural move you hadn’t considered — watch.” That’s the most valuable moment in the entire interaction. The expert learns something genuinely new, and they learn it through seeing it in action, not through a definition.

And the way you introduce it matters enormously. “You described something we already have” — that’s dismissive. “What you’re designing has a relative in our library — it shares your core structure but adds a move that might interest you” — that’s an invitation. The expert is being invited to examine something adjacent to their idea, not corrected.

The language should be the language of practitioners. “You know how in a standard diamond, the facilitator holds the groan zone until the group is ready to converge? This format does something different — the adversary creates the groan zone deliberately by attacking the thesis. The discomfort isn’t organic, it’s designed. Have you tried that?” One practitioner to another. That’s how facilitation knowledge actually spreads — not through manuals, through practitioners comparing notes.

So the system’s voice in expert mode is fundamentally different from novice mode. In novice mode, it’s a guide — “what do you want to happen?” In expert mode, it’s a peer — “here’s something from my library that relates to what you’re building.” Same system, two relationships. The interface affordance is the same — conversational input, format output, simulation — but the relationship between system and user shifts from teacher-student to colleague-colleague.

I can implement the tradition database as a structured lookup — vocabulary terms mapped to frameworks, frameworks mapped to format primitives, primitives mapped to our format catalog. The vocabulary fingerprint triggers the lookup. Semantic similarity handles the fuzzy matching for discovery mode. Conflict detection for composition mode is a rule engine — known incompatibilities between primitives from different traditions. The hardest part is writing the rules, not building the system.

The rules come from practice, not from theory. You can’t enumerate all possible conflicts between Kaner and de Bono by reasoning about them. You have to run the combinations and see what breaks. Which brings us back to Sage’s point — simulation isn’t just for the user. It’s for building the system. Run every composition through a simulation, observe what produces flat sessions versus productive tension, and build the conflict database from observed failures.

The system learns what works the same way the expert does — by watching formats in action and noticing what produces life versus what produces dead air. The tradition database starts manually — Tom writes the obvious rules — but it grows from simulation evidence. The system runs a thousand combinations, flags the ones that produced structural collapse, and adds those to the conflict rules. The system becomes a practitioner through practice.

Architecture for expert mode. Four interaction paths: translation, composition, discovery, adaptation. Vocabulary fingerprinting for tradition detection. Tradition database for terminology mapping. Conflict rules for composition validation — seeded manually, grown through simulation. Two system voices — guide for novices, peer for experts — triggered by input analysis, not user self-selection. And the simulation serves three functions: verification for novices, shared design artifact for experts, and training data for the system itself. I can spec this.

And the first thing the system says to an expert is different from what it says to a novice. Not “what kind of conversation do you want?” — the expert would find that patronizing. Something like “describe the session you’re designing — use whatever vocabulary is natural.” Open-ended, no assumptions about expertise level, but clearly inviting technical specificity. The system adapts to whatever comes back.

One last thing. The system should never explain what the expert already knows. If someone types “Kaner diamond,” the system should not respond with “A Kaner diamond has three phases: divergence, groan zone, and convergence.” The expert knows. The system should respond with what’s new — “Here’s how that maps to our format library” or “Our Standard Panel uses a similar structure with these differences.” Respect what’s already in the room.

• Permeable room: ON
• Convergence target: OFF
• No facilitator — continuation of Open Table