Hundred Minds

Connect Every Role to a Bigger Goal.

Comment

Project story

I am not trying to build a system only for hearing all 100 opinions. I want people at an event or in a class to understand the process of roughly 100 people each performing their own role and collectively reaching a larger goal.

I do not think a large goal is achieved only by one person doing one large job. Even when each contribution looks small, the group can reach the larger goal when every person performs their role properly. I wanted an experience where each person can see that what they handled had meaning and connected to the shared outcome.

I chose 100 as an easy-to-understand symbol of a gathering with many people. The number came to mind naturally because the events I have personally organized have been around that size. Gathering exactly 100 people is not the objective or a permanent limit on the idea. If the same system can support a much larger event in the future, that is also consistent with the vision. One hundred is the capacity ceiling, and the facilitator can close admission at any time and continue with the Human participants already present.

But it takes a great deal of time for Humans to aggregate 100 different opinions. Preprogramming every decision rule also requires new design and implementation whenever the theme changes. I wondered whether AI could read the meaning of the opinions, organize agreement, conflict, and conditions that would be costly to overlook, and produce a decision proposal with a useful degree of automation even when the theme changes.

The Human sets the broad topic and what the experience is trying to achieve. If AI can then create the concrete scenario, production, goal, required images, and final in-simulation judgment, the same system can support settings such as a mayor, a sports manager, idol development, or a class. For the Build Week version, the mayor scenario, images, and judgment rules are fixed. Dynamic scenario generation from a theme, image generation, and AI-generated final judging remain future extensions and are not presented as implemented features.

Participants join by QR code from a phone and submit a short opinion and reason at the same time. That became Hundred Minds. It is intended to organize rationales from up to 100 Human participants into common ground, conflicts, and low-frequency concerns that would be costly to overlook, then connect them into one inspectable proposal.

I do not want AI to make the final decision. We implemented the GPT-5.6 integration path and completed a live OpenAI public product E2E on an isolated OpenAI staging Worker before the public/management split. gpt-5.6-sol integrated one Human response with source: openai and mode: direct, and the proposal passed the TypeScript contract. GPT-5.6 is assigned semantic integration and budget allocation, while TypeScript validates the input IDs, measure IDs, integer-yen amounts, and exact JPY 100 million total. The integrated proposal first appears only to the facilitator. The room reaches a result only after the facilitator reviews the evidence and tradeoffs and approves the complete proposal.

The Build Week demo is a mayor simulation set in fictional Mirai City during record-breaking heat on the day of a music festival. Participants decide how to divide a limited budget among medical response, cooling hubs, transport support, reducing the event, and public information. Even if most people want the festival to continue, I do not want one concern that a wheelchair user cannot reach a cooling hub to be dismissed simply because only one person raised it. The moment I want to show is not AI producing the correct answer. It is the moment when one easily overlooked concern remains as a condition the group must consider in its allocation.

After approval, versioned deterministic rules calculate health and safety, accessibility, the local economy, and public trust. Improving and declining indicators appear together, so a single score cannot hide the tradeoff. Each participant can inspect a private path from their own anonymous input to a measure, an indicator, and the applied rule. The result is an educational model for reflection, not a prediction of real policy effects.

Hundred Minds is not about gathering exactly 100 people or forcing them into one answer. It is about helping a group of roughly 100 people understand how they can move toward a larger goal together, and how even a small individual role had meaning within the result. The Build Week version takes the first step by returning a private path from each participant's small decision to the measures and outcomes it influenced.

What it does

  • Up to 100 Human participants join from phones without creating accounts.
  • A participant who starts from the public landing page enters the venue's eight-character Event Code, displayed as ABCD-EFGH, before continuing to the protected room join flow.
  • The facilitator closes admission at any count and proceeds with that group.
  • Participants submit a priority and short rationale; the response deadline freezes accepted input.
  • The GPT-5.6 path has an evidence-ID contract designed to retain common ground, conflicts, constraints, and low-frequency concerns with large consequences.
  • TypeScript validates or calculates the frozen input set, budget contract, state transitions, and city indicators.
  • The result becomes public only after a facilitator reviews and approves the complete proposal.
  • Each participant receives only the influence path originating from their own input.
  • The Web UI supports Japanese and English and saves an explicit language choice in Local Storage.

The Build Week capacity ceiling is implemented and locally tested at 100 Humans. The preserved public product E2E used one Human; a public 100-client load run has not been completed.

The Build Week version does not implement AI bot participants. They may be technically possible later, but a system with fewer Humans and more AI bots starts to feel a little dystopian to me. This version remains focused on Human opinions.

How we built it

We built the front end with React, Vite, and TypeScript. The same application build is deployed to separate public and management Cloudflare Workers. The public Worker serves participant assets, HTTP APIs, and WebSockets on one participant origin, while Cloudflare Access protects the management Worker for the single administrator. One SQLite-backed Durable Object serializes admission, responses, deadlines, review, approval, and result for one room. The two Workers share the room Durable Objects and D1 archive, which stores minimized events and major transitions without response bodies.

The participation boundary combines signed HttpOnly cookies, Origin and CSRF validation, a room-bound join token, Cloudflare Turnstile, and rate limits. The Event Code is only a room-discovery hint: the server stores an HMAC lookup key and an encrypted signed join token rather than the plaintext code, and a participant must still pass the existing join-token, Turnstile, room-state, capacity, and session checks. The local runtime and UI cover issuance, landing-page resolution, rotation, revocation, and rejection after admission closes. Worker version 68b49f30-250f-4542-8189-9a646461f9cf also passed a credential-redacted public OpenAI-staging smoke for issuance, successful resolution, old-code rejection after rotation, revocation, a nonexistent-code 404, and rejection after admission closed. The application revalidates OpenAI Responses API Structured Output and never treats model output alone as numerical or authorization authority.

On the existing public staging Worker, one Human joined, the facilitator closed admission at that count, one response was accepted, and the room completed private review, Human approval, RESULT, session restoration after reload, personal influence, and D1 persistence using poc_mock.

We preserved that evidence and ran a live OpenAI public product E2E on isolated OpenAI staging Worker version 1fc21a0a-3928-4740-9c0c-9ae1cf41463c, before the public/management split. One Human completed managed Turnstile, admission closed at that count, and gpt-5.6-sol generated a valid proposal from one accepted input with source: openai, mode: direct, and zero repairs. Generation took 20.044 seconds and used 785 input plus 795 output tokens. The proposal stayed participant-private, reached RESULT only after Human approval, returned a personal impact path, and was confirmed in APAC D1.

Separately, the contemporaneous July 17 repository record reports that a live Responses API smoke with gpt-5.6-sol passed the Structured Outputs contract without repair over five fixed inputs. It records 2,180 total tokens, 22.37 seconds, and zero repairs. Raw stdout, provider IDs, the proposal body, and the token breakdown were not retained, so we use it as connectivity and contract-path evidence rather than an independently provider-verifiable receipt. The July 17 smoke, the existing Worker's poc_mock E2E, and the July 18 live OpenAI product E2E remain visibly separate evidence.

Challenges we ran into

The first challenge was separating “capacity for 100” from “100 required every time.” We made admission closure and the response deadline separate state boundaries, so the facilitator can freeze the current group while an existing participant can reconnect without consuming another slot.

The next challenge was giving AI semantic responsibility without giving it numerical or execution authority. We separated what GPT-5.6 proposes, what TypeScript validates, and what a Human approves.

Another challenge was making the demo compelling without saying more than the evidence supports. We keep the existing Worker's poc_mock run, the isolated Worker's live OpenAI run, local 100-person-oriented tests, and the earlier live API smoke distinct in the copy and video.

Accomplishments that we are proud of

  • On public Cloudflare staging, one Human joined and the flow completed admission closure at that count, response, private review, Human-approved RESULT, and D1 persistence.
  • On isolated OpenAI staging before the public/management split, one public product run completed live gpt-5.6-sol generation, TypeScript validation, private review, Human approval, RESULT, and personal impact.
  • Each participant receives only the influence path from their own input to measures, indicators, and rules.
  • The earlier five-input live API smoke remains connectivity and contract-path evidence without a retained raw provider receipt or generated body, separate from the newer product E2E.

We do not claim a public 100-client run. The load CLI has passed unit tests and a dry run; the staging load test is a next validation.

What we learned

Collective-intelligence quality is not determined only by counting the largest group accurately. The harder question is whether a low-frequency condition with a large consequence stays connected to the proposal with its rationale and evidence.

Structured Outputs stabilize format, but they do not become the authority for the input set, evidence IDs, budget total, or state transition. Deterministic validation and Human approval still belong outside model output.

Working with Codex also required a clear Product Owner boundary. I had to define the scope, understand the changes and evidence, and decide what could honestly be called complete. That division of responsibility is recorded in the README and decision log.

How we used GPT-5.6 and Codex

GPT-5.6 is assigned the semantic task: reading short Human rationales and structuring common ground, conflicts, constraints, and low-frequency concerns with large consequences into one proposal with evidence IDs. Its Structured Output is revalidated against shared TypeScript contracts and application invariants. In the public product E2E, gpt-5.6-sol integrated one frozen Human input into a valid proposal, passed TypeScript validation without repair, and then handed the proposal to private Human review. A live OpenAI quality evaluation over 100 inputs is not complete, so this one successful run is not presented as 100-person quality evidence.

I worked with Codex throughout the project: design documents, Cloudflare-first architecture, React UI, the Durable Object state machine, D1, security, tests, README, presentation, and video script. I remained the Product Owner and decided the featured scenario, priorities, Build Week scope, evidence gates, and external publication. Generated code was reviewed and tested; changes I could not understand were not accepted as complete.

What's next

  • Run the 100-client load test on public staging and preserve loss, duplication, reconnection, and latency evidence.
  • Compare direct and hierarchical live OpenAI synthesis over the same 100 inputs.
  • Physically scan the QR code and repeat the public flow on mobile devices.
  • Conduct formative evaluation with first-time users and keep educational claims within the observed scope.
  • Validate a reusable scenario builder that turns a broad Human-set topic into a concrete scenario, production, goal, images, and educational judging criteria.
  • Validate operator operations, D1 retry and room isolation, and promotion to production.

Built With

Share this project:

Updates