How I Choose

How I Choose is a local-first rehearsal workspace that checks whether a communication partner followed a person's self-authored protocol-never evaluating the person.

Comment

Inspiration

Important conversations often become harder when speech, language, or processing gets difficult. Yet many communication tools still ask the person to perform better: answer faster, choose from someone else's categories, or fit a fixed conversational rhythm.

We wanted to reverse that responsibility.

How I Choose asks whether the communication partner adapted to the person—not whether the person performed correctly. The person defines what helps, what each signal means, how much time is needed, and what a partner must do next. The software turns those choices into a protocol that can be rehearsed and audited without inferring meaning from silence or delay.

What it does

How I Choose is a local-first communication rehearsal workspace for adults. A person authors their preferred channels, wording, pace, processing time, literal-language rules, semantic signals, and partner actions. They also choose exactly which fields an active browser agent may read.

The workspace supports both human-only practice and an optional WebMCP agent rehearsal. Before any partner turn becomes visible, a deterministic engine checks it against the current protocol. It enforces one question at a time, word and option limits, channel rules, pending-signal acknowledgment, Pause, terminal Stop, revision freshness, conflicts, and idempotency.

The person directly selects every semantic signal, including yes, no, not sure, more information, more time, rephrase, Pause, and Stop. Silence creates no event and never advances the rehearsal. Reports contain evidence about the partner's adherence and repairs; they never score the person.

The complete human-facing product includes:

  • guided onboarding plus blank and clearly labeled synthetic profiles;
  • profile, signal, and per-field agent-access editing;
  • a large keyboard-accessible signal board;
  • low-stakes rehearsal templates and partner-turn validation;
  • partner-adherence audit and revision history;
  • staged protocol suggestions with exact diffs and provenance;
  • JSON import/export and a printable support guide;
  • visible owner-only review and ratification;
  • text-size, contrast, Quiet, and Plain language preferences.

Why WebMCP

This workflow needs an agent to operate inside the person's current, visible, revisioned protocol, not inside a detached chat containing copied instructions. WebMCP lets ChatGPT use the page's existing permissions, validator, state machine, and evidence while the person retains direct control of signals, rule changes, and approval.

The workspace starts in Human-only mode. All eight Site tools fail closed until the person visibly enables Agent rehearsal. Once enabled, ChatGPT can read only allowlisted fields, audit readiness, start an already approved scenario, offer a validated partner turn, acknowledge the exact person-selected signal, inspect its own adherence, stage a draft improvement, and verify guide derivation.

There is deliberately no tool for selecting a person's signal, answering for them, resuming, ratifying, publishing, sharing, exporting private data, deleting a profile, or assessing capacity, consent, diagnosis, comprehension, safety, or coercion.

How we built it

The app is a static Next.js and React application written in strict TypeScript. Dexie/IndexedDB is the durable local source of truth; Zustand holds hydrated read projections and transient preferences. Zod validates every persisted document, import, command, and Site-tool payload.

Human controls and WebMCP handlers use the same application-service command path and pure domain logic. Compare-and-swap revisions, idempotency fingerprints, events, and state writes happen atomically in one IndexedDB transaction. Ratified profile snapshots are immutable and identified by canonical hashes.

The top-level /demo/ page feature-detects WebMCP and imperatively registers a stable catalog through document.modelContext.registerTool():

  • get_rehearsal_brief
  • audit_rehearsal_readiness
  • start_approved_rehearsal
  • offer_partner_turn
  • read_latest_signal
  • get_rehearsal_report
  • stage_protocol_patch
  • verify_support_guide

A singleton guard prevents duplicate registration under React Strict Mode. Every JSON Schema is bounded and closed with additionalProperties: false, then Zod validates again at the application boundary. Mutations require expected revisions and an idempotency key. Handlers resolve current IndexedDB state at invocation time instead of trusting stale UI state.

The quality system combines Vitest, Testing Library, fast-check property tests, Playwright desktop and narrow-viewport suites, axe-core checks, dependency and secret audits, a static production build, and GitHub Actions. The release includes 76 unit, service, property, import/export, and agent-flow tests plus a complete 15-step browser judge path.

Challenges we faced

Treating discovery and authorization as separate problems. Registering a tool successfully does not mean it should be authorized in the current state. A real-browser test exposed an early version where Human-only was only presentation state. We fixed this by making owner-controlled agent access durable, revisioned session state and enforcing it inside every handler.

Keeping agent authority physically narrow. Removing dangerous fields from a broad object was not enough. We created allowlisted agent DTOs and a separate AgentRehearsalService that cannot import owner-only ratification, signal selection, export, share, delete, or resume operations.

Making concurrent changes recoverable. A person may change a rule while an agent is preparing a turn. Expected revisions cause the stale write to fail instead of overwriting the person's newer choice; the agent can reread the brief and adapt.

Building safety without making clinical claims. The product is deliberately scoped to synthetic and low-stakes adult communication practice. It does not infer answers, assess a person, or present itself as a consent system, medical device, emergency plan, or legal instrument.

Accomplishments that we're proud of

  • One deterministic engine governs both human and agent partner turns.
  • Human-only access fails closed, while owner-enabled agent access remains field-scoped and revisioned.
  • Pause is immediately effective and Stop is terminal—no agent override exists.
  • Stale revisions, duplicate requests, invalid turns, repair, signals, and provenance are visible and recoverable.
  • Private notes are structurally absent from agent projections, and receipts contain metadata rather than authored conversation text.
  • The full human product works without an account, backend, API key, remote database, analytics, or runtime external model call.
  • The deployed production build was exercised in ChatGPT's real built-in browser: all eight tools were discovered and the guarded workflow, including Human-only denial and visible owner-enabled access, was verified.

What we learned

WebMCP is most useful when it exposes an existing trustworthy application boundary rather than creating a second automation-only path. Tool discovery, state authorization, validation, persistence, and visible evidence all need independent treatment.

We also learned that “local-first” needs precise disclosure. Profiles and rehearsals stay in local, unencrypted IndexedDB, but fields explicitly exposed through Site tools are processed by the active browser agent. The interface says that plainly.

Most importantly, semantic safety becomes more reliable when it is structural: the agent cannot manufacture a person-authored signal, Stop cannot be reversed, silence cannot become an answer, and suggestions remain drafts until the person reviews them.

What's next

The next phase is compensated co-design with people who use diverse communication methods, followed by deeper accessibility research and independent review. We also want to explore portable protocol formats, more rehearsal templates, stronger assistive-technology testing, and longitudinal partner-adherence evidence without introducing person scoring or surveillance.

How I Choose is an open alpha, not a clinically validated product. The challenge profiles and scenarios are synthetic. Its contribution is an executable pattern for accountable communication agents: the person remains the source of meaning, while adaptation becomes testable.

Verification note

Real ChatGPT built-in-browser verification is documented separately in the public repository. The submitted video is an editorial product walkthrough using the real deployed interface and synthetic data; it does not claim to be footage of the separate live Site-tool test.

Built With

Share this project:

Updates

Submission history