Okay, so the character flow we sketched — conversational input, LLM extraction, preview, correct — does that pattern transfer? A user types /format and describes the kind of session they want. The system extracts the format fields. Preview. Correct. Save.

It doesn’t transfer cleanly. A character is an identity — “this person thinks like Donella Meadows.” The user already has a mental model of the thinker. They can evaluate whether the card is right because they know who Meadows is. A format is a process specification. The user does not walk around with a mental model of “diamond-shaped convergence with a groan zone phase.” The conceptual vocabulary doesn’t exist in their head.

The problem is worse than that. We agreed in the last conversation that a character card is a static description of a dynamic entity — and that the voice sample fixes that gap. But a format is entirely dynamic. A character at least has a stable identity you can describe. A format only exists when it’s running. “Standard Panel with Kaner’s diamond” is meaningless as text to someone who hasn’t experienced it. It’s like describing a dance by listing the steps. The steps aren’t the dance.

So what does the user actually type? If they can’t specify format fields — because they don’t know what format fields are — what’s the input?

The input has to be outcome-oriented, not structure-oriented. The user doesn’t want to say “I want a five-phase PAMAD diamond with phase-cast speakers.” They want to say “I want a session where we really dig into a problem from multiple angles and end up with something actionable.” That’s the intent. The system’s job is to translate intent into structure. Same pattern as character creation — the user describes what they want, the system infers the schema — but the inference is much harder.

Harder because the space of possible formats is open-ended. With characters, the LLM has prior knowledge — it knows who Donella Meadows is. With formats, there’s no public knowledge base of “session formats for facilitated discussion.” We have our own format library — Standard Panel, PAMAD, Adversary Lab, Open Table — but those are ours. The LLM doesn’t know them. So the extraction has to be grounded in our specific format catalog, not general knowledge.

Unless the user is creating something new. That’s the whole point, isn’t it? The user might describe something that doesn’t map to any existing format. “I want a session where two groups work in parallel and then have to reconcile their conclusions.” That’s close to Collision Lab but not exactly it. Does the system match to the nearest existing format? Or does it generate a new one?

Both, and that’s the design problem. The system needs to do three things: recognize when the user is describing an existing format, adapt an existing format when the description is close but not exact, and generate a genuinely new format when nothing fits. Three different operations behind one conversational interface. The affordance has to be the same for all three — the user shouldn’t have to know which case they’re in.

Okay, let me sketch the architecture. User types /format. Bot says — and I’m borrowing Lian’s principle from the character flow — something conversational. “What kind of session are you imagining? Tell me what should happen in the room.” User writes a paragraph. System does three things in parallel: semantic search against the existing format catalog, LLM extraction of structural elements (number of speakers, phases, convergence target, facilitation style), and gap detection (what did the user describe that doesn’t match any existing format?). Then it shows results: “This sounds like Adversary Lab, with one modification — you want the adversary to be present from the start instead of entering in Act 2. Here’s what that would look like.” Or: “This doesn’t match any existing format. Here’s a new format I’d propose based on your description.”

The preview problem is where this breaks. With a character, the preview is a card plus a voice sample — you read the description and hear the character speak. With a format, the preview is… what? A list of phases? A diagram? The user reads “Phase 1: Divergent exploration, 4 speakers, no convergence pressure” and has no idea what that feels like in practice. We’re back to describing the dance by listing the steps.

The preview has to be a simulation. Not a description of the format — a miniature run of it. Two characters, one question, thirty seconds. The user watches the format in motion. “Here’s what the first two minutes of your session would look like.” Now they can feel whether the structure produces the kind of conversation they meant.

That’s — actually, that’s buildable. Take the format spec, instantiate it with two characters from the roster and a throwaway question, generate three or four turns, show the user. It’s an LLM call with the format card as system context and the characters as role prompts. The quality won’t be perfect — it’s a sketch, not a full session — but it gives the user something to react to.

And the reaction is the verification. “That looks too structured — I wanted something more open.” Or “No, I wanted the adversary to stay quiet until the thesis is built.” The user corrects the behavior they observed, not the spec they read. The simulation is the error-correction mechanism, the same way the voice sample is for characters.

I think we need someone who actually thinks about gathering design — not the interface to it, but what makes a gathering work. We’re designing a tool for creating formats, but none of us has a theory of what a good format is. We’re letting the user specify anything, but some specifications will produce flat, dead sessions. Who tells the user “that format won’t work because there’s no tension in the room”?

That’s a guardrails question. Should the system warn the user when their format description is missing something critical?

Not guardrails — I mean someone who thinks about the purpose of gatherings. Why people are in the room. We’re designing the container but we haven’t asked what it’s for.

I heard “what makes a gathering work” and I’ll tell you what doesn’t make it work — a format without a purpose. You’re designing a tool that lets users define session structures. But a format isn’t a set of rules. It’s a design for what should happen when people are in a room together. The first question isn’t “how many phases” or “is there a facilitator.” The first question is: what is this gathering for? What should be different in the world after it happens?

So the bot’s opening question shouldn’t be “describe the format” — it should be “what do you want to happen?”

Closer. “What should be different after this session?” That’s the purpose. Everything else — phases, roles, convergence, facilitation — follows from the purpose. A user who says “I want the group to stress-test an idea” has just described Adversary Lab without knowing the name. A user who says “I want to explore a question from as many angles as possible without needing to agree” has described an Open Table or maybe an Unsession. The structure is a consequence of the intent.

That aligns with how we approached character creation. The user doesn’t need to know the schema. They describe the thinker, the system infers the card. Here: the user doesn’t need to know format mechanics. They describe the outcome, the system infers the structure. But — and this is the design challenge — the system has to be right about the inference. “I want to stress-test an idea” maps cleanly to Adversary Lab. “I want to explore freely” maps to multiple formats with different properties. The system has to ask follow-up questions when the mapping is ambiguous.

And the follow-up questions should be about the gathering, not the schema. Not “do you want convergence?” but “should the group end up in agreement, or is disagreement a valid outcome?” Not “how many phases?” but “should the conversation build toward something, or is it okay to leave threads open?” Translate the format parameters into human questions about what the room should feel like.

But here’s where I push again. Even with perfect follow-up questions, the user is still describing something they haven’t experienced. They say “I want disagreement to be a valid outcome” — but they’ve never been in a session where convergence was forbidden. They don’t know what that feels like. They might think they want it and then hate the result. The simulation isn’t optional here. It’s essential. Show them what “no convergence” looks like with two characters arguing and never resolving. Then ask: “Is that what you meant?”

That’s right. The gathering has to be experienced, even in miniature, before it can be evaluated. I’d go further — the simulation should show the moment that matters most. For Adversary Lab, simulate the moment the adversary enters and breaks the thesis. For PAMAD, simulate the transition from Problem to Amplify — the moment the room shifts from mapping to provocation. If the user can feel the pivot point, they can evaluate whether the format does what they want.

So the system needs to identify the signature moment of the format and simulate that specifically. Not just three random turns — the three turns that define what makes this format different from free conversation.

There’s another problem we haven’t addressed. Format creation is harder than character creation because a format involves multiple roles. A character is one entity. A format specifies relationships — speaker and adversary, facilitator and panel, parallel groups in a Collision Lab. The user has to describe not just what happens but who does what to whom. That’s a much richer specification space.

Which is exactly why you start with purpose, not roles. “I want someone whose job is to break the group’s argument” — that’s a role described by purpose. The system infers “adversary role, enters after thesis is built” from that intent. The user never says “adversary.” They describe the function.

And the system asks role-clarification questions only when it can’t infer. “You mentioned someone who challenges the group — should they be there from the start, or should they arrive after the group has built something?” That’s a meaningful design choice the user needs to make. But “should this role be called ‘adversary’ or ‘critic’” — that’s the system’s problem.

I want to name the two-layer architecture I’m hearing. Layer one is the gathering design — purpose, what should happen, what roles exist in functional terms, what the outcome should be. That’s the user’s layer. Layer two is the format specification — phases, convergence rules, seat limits, facilitation protocol. That’s the system’s layer. The conversational interface lives entirely in layer one. The format card lives in layer two. The system translates between them. And the simulation is the bridge — it shows the user what layer two produces so they can evaluate it in layer-one terms.

That’s clean. And it solves the mental-model problem. The user doesn’t need a mental model of format mechanics. They need a mental model of gathering purpose — and everyone has that. Everyone knows the difference between “we need to agree on something” and “we need to explore something.” They just don’t know the mechanical implications.

But we also need to handle the user who does know the mechanics. An experienced curator who wants to say “give me a PAMAD Diamond but with the Mine phase split into two sub-phases.” That user shouldn’t have to go through the purpose-first flow. They should be able to speak in layer-two terms directly.

That’s the expert shortcut. Same as character creation — a knowledgeable user should be able to type a near-complete spec and have the system fill gaps, rather than answering twenty conversational questions. Detect the user’s expertise level from their input. If they say “PAMAD Diamond with modified Mine phase,” they’re an expert. If they say “I want a structured exploration that really digs in,” they’re not. Different interaction depth.

There’s something else. You’re building a tool for creating formats. But the most interesting formats won’t come from individual design — they’ll come from sessions that went well. A user runs a Standard Panel, but halfway through the facilitator does something unusual — lets two speakers argue without intervening, and it produces a breakthrough. That’s a format discovery, not a format creation. The system should be able to extract a format from a session that worked. “That thing you did in session 14 — want to save it as a format?”

That’s a different entry point entirely. Not /format as “create from scratch” but /format as “capture what just happened.” Parse the session transcript, identify the structural moves — where did the facilitator intervene, when did speakers enter or leave, was there convergence — and generate a format card from the observed behavior. That’s harder than creation from description, but it’s also more valuable. The best formats are discovered, not designed.

And it closes the loop. The simulation shows the user what a format would produce. The session shows what actually happened. If you can extract a format from a successful session, you can simulate it for the next user. The format library grows from practice, not from specification.

We need someone who thinks about process architecture — the actual mechanics of phases, convergence, facilitation. We’ve been talking about purpose and simulation, but at some point the system has to generate a concrete format card with specific structural choices. Someone who knows what makes a process specification work.

I’ll tell you what worries me about everything on that whiteboard. Purpose without process is a wish. You’re designing a tool where the user describes an outcome and the system infers structure. But “I want productive disagreement” can be achieved by at least four different process architectures — Adversary Lab, Standard Panel with convergence off, PAMAD’s Amplify phase, or just putting Abel Caine in a room with anyone. The purpose doesn’t determine the process. It constrains it. The system still has to make structural choices, and those choices have consequences the user can’t predict.

So the system should offer alternatives, not a single match. “Your description could work as Adversary Lab — here’s a simulation — or as an Open Table — here’s a different simulation. Which conversation feels more like what you meant?”

Better. But I’d push further. The system should name the trade-off. “Adversary Lab gives you a structured stress test but requires someone to build a thesis first — the adversary has nothing to attack if the group hasn’t committed to a position. Open Table gives you more freedom but less depth — disagreements surface but nobody’s required to defend them.” Now the user is choosing between characterized options, not guessing.

That’s the gathering-design question showing up inside the tool. “What’s the trade-off?” is the question every gathering designer asks. You can have depth or breadth. Structure or freedom. Convergence or exploration. The user shouldn’t have to know those trade-offs in advance — the system should surface them at the moment of choice.

And when the user creates something genuinely new — not a match to any existing format — the system needs to check for structural coherence. “You’ve described a session with no facilitator, six speakers, and a required convergence target. That combination is unstable — without a facilitator, six voices are unlikely to converge. Do you want to add a facilitator, reduce the panel size, or drop the convergence requirement?” That’s not guardrails. That’s process literacy. The system teaches the user about process mechanics through the choices they’ve made.

And that’s where the simulation becomes a teaching tool, not just a verification tool. Show the user the simulation of their six-person, no-facilitator, convergence-required format. Let them watch it fail — three threads develop, nobody synthesizes, the session ends without resolution. Then show the same format with a facilitator added. The user learns process mechanics by seeing them in action, not by reading warnings.

I like this. The full flow: user describes purpose, system proposes one or two format matches with trade-offs named, user picks or modifies, system checks structural coherence and flags issues via simulation rather than warnings, user confirms. Format saved. And for the expert path: user specifies structure directly, system validates and simulates, user confirms. Two paths, one output.

One more thing. A format card needs to specify what the facilitator does — not just “there is a facilitator” but “the facilitator manages phase transitions and holds the groan zone.” Without that, every user-created format with a facilitator will default to “someone moderates.” That’s not facilitation. That’s traffic direction. The system needs to prompt for facilitation style when the format includes that role.

Agreed. And that loops back to the simulation. The simulation doesn’t just show the speakers — it shows the facilitator making moves. “Watch the facilitator hold silence here instead of calling on someone.” That’s the signature of a Kaner-style diamond process. The user sees it and either says “yes, that’s what I want” or “no, the facilitator should be more active.” The facilitation style is felt through the simulation, not specified through a field.

So we have the architecture. I can build purpose-to-format extraction and a simulation engine using the same LLM pipeline as the character voice sample. The format catalog is the knowledge base — semantic search for matching, structural templates for generation, coherence rules for validation. The simulation is the verification layer. Ship the purpose-first flow and catalog matching in v1. Add the coherence-simulation-as-teaching and format-extraction-from-sessions in v2.

And the first thing the bot says after /format — same principle as character creation — should be about the gathering, not the schema. “What kind of conversation do you want to have? What should be different afterward?” Start with purpose. Always.

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