Designing K2-Consensus: A Debate the Reader Can Follow

A lively transcript can still leave the reader lost

Imagine watching three reviewers discuss your proposal. Comments arrive quickly. One asks for a stronger baseline; another worries about deployment cost. The final report says the proposal is promising—but you can't tell which concerns were resolved or what to do next.

The K2-Consensus proposal aims for a live expert-panel experience. Its strongest interface opportunity is to make the review navigable: who raised a concern, what evidence supports it, and what action follows?

This is a design companion to what an AI panel's agreement means. The published repository contains the proposal, so the behavior described here is an intended experience and set of design choices, not a report from a deployed application.

Start with a transcript that has a job

The proposal uses a React frontend, a FastAPI orchestrator, and Server-Sent Events (SSE) to deliver successive review turns. The transport choice is useful because the server can send new material as it becomes available rather than waiting for the whole report.

A streaming connection still needs an application-level contract. Each turn should identify its speaker, the issue being discussed, and whether it is raising a question, challenging a claim, or proposing an action. Otherwise, fast text can become a more elaborate loading indicator.

The conceptual diagram separates ongoing discussion from the final artifact. Indigo receives the proposal, amber streams the review, teal synthesizes, and slate preserves a report the reader can revisit.

The system, at a glance

Drawing the architecture…

Follow the labeled connections. On smaller screens, scroll to explore wide diagrams.

View diagram source

flowchart TD
    accTitle: Proposed K2-Consensus reader experience
    accDescr: A user submits a proposal to an orchestrator. Review turns stream into a transcript, while moderator synthesis produces an action report that links recommendations to supporting turns and unresolved questions.
    I[Submit proposal and context] --> O[Orchestrate review turns]
    O -->|SSE events| T[Speaker-labeled transcript]
    O --> M[Moderator synthesis]
    T --> R[Traceable action report]
    M --> R
    R --> Q[Open questions and next checks]
    classDef input fill:#eef2ff,stroke:#818cf8,color:#312e81
    classDef live fill:#fff7ed,stroke:#fb923c,color:#9a3412
    classDef synthesis fill:#ecfdf5,stroke:#34d399,color:#065f46
    classDef record fill:#f1f5f9,stroke:#94a3b8,color:#334155
    class I input
    class O,T live
    class M synthesis
    class R,Q record

Show the critique, then make it easy to inspect

Useful transparency does not require presenting a model's private internal reasoning. The visible artifact can be the review it was asked to produce: claims, evidence, assumptions, objections, and concise explanations for recommendations.

For an illustrative baseline concern, the transcript might show:

Academic reviewer: “The reported improvement needs a comparison under the same data split. Without that, we cannot tell whether the model or the evaluation changed.”

The corresponding report item can request a controlled comparison and link back to that turn. The reader can inspect the reason without rereading the entire conversation.

Preserve the state of a concern

A question can be raised without being answered. A reviewer can suggest a fix without demonstrating that it works. A moderator can recommend an experiment without that experiment having happened.

Review state	What the interface should communicate
Raised	Someone identified a concern
Discussed	The panel responded to it
Supported	Available evidence addresses it
Unresolved	More information or a check is needed

These are proposed interface states. Their value is that the final summary can't silently turn “discussed” into “resolved.”

Pause and predict: should every concern disappear from the report once the moderator has spoken?

No. The moderator may have organized the discussion without resolving the underlying question. Open issues should remain visible with the evidence or action needed to settle them. A useful conclusion can preserve uncertainty while still giving the reader a clear next step.

A dropped stream should not erase the review

SSE carries events to an open connection. The product still needs a strategy for retaining turns and retrieving a completed report. If a connection drops halfway through, the reader should know whether the review stopped or only their view of it was interrupted.

A design extension could give runs stable identifiers, store ordered turns, and allow a reconnecting client to recover missing material. It would also define whether cancellation stops generation or merely closes the display. These are requirements to implement and test, not capabilities established by the proposal's diagram.

Put the reading experience ahead of visual noise

Different reviewer labels and restrained color can make speaker changes easy to scan. The important motion is the arrival of useful information: a new objection, a revised assumption, or a recommendation with evidence.

An expanding graph of agent avatars may look busy without helping the reader decide anything. The proposal deliberately prioritizes a streaming transcript for its scoped demo. That keeps the interface focused on the content the panel contributes.

What would make a good first demo?

Use a short proposal with one known flaw and a few genuinely open questions. Show the panel identifying the flaw, debating a tradeoff, and producing an action report that keeps unresolved issues explicit. Then disconnect the interface mid-run and test whether the reader can recover the result.

The first demo should establish a comprehensible review experience before making claims about expert equivalence or superior reasoning. The useful outcome is a reader who understands the critique and knows what to check next.

Return to the panel-design walkthrough, or read the source proposal at revision dfc6b0d.