MeaningSync

Turn spoken service agreements into shared, bilingual understanding before work begins.

Comment

Inspiration

I kept coming back to a very ordinary situation. A customer calls an electrician, explains the work, discusses the price, and asks when it can begin. The electrician agrees, and both people leave the conversation believing everything is clear.

The disagreement often appears later.

The customer thought the price included replacement parts. The electrician meant that the price covered labour only. Neither person necessarily tried to mislead the other—they simply left the same conversation with different understandings.

The problem becomes even harder when the two people are more comfortable in different languages. Translation can make the words readable, but readable words do not always mean shared understanding.

I built MeaningSync as a solo project to answer one practical question before work begins:

Did both people understand the same agreement?

I did not want to create another AI summary tool. I wanted to build something that preserves what each person actually said, identifies the exact differences, and helps both people confirm the same meaning in the language they understand best.

What it does

MeaningSync helps a customer and service provider compare their understanding of a spoken or typed conversation. It currently supports English, Hindi, and mixed English–Hindi conversations.

I designed the experience as six guided steps:

  1. Choose each participant’s language, the currency, and whether they will share one device or use separate devices.
  2. Let both participants join and accept the conversation data notice.
  3. Speak or type the conversation in each participant’s preferred language.
  4. Compare What matches, Needs a decision, and Not discussed.
  5. Resolve only the decisions that genuinely need attention, then let both participants confirm separately.
  6. Create a clarity receipt containing the agreed meaning, unresolved terms, original evidence, confirmation timestamps, and an integrity hash.

The deterministic bilingual demo uses a simple but important disagreement:

  • The homeowner says ₹1,200 includes replacement parts.
  • The electrician says ₹1,200 covers labour and replacement parts cost extra.

MeaningSync keeps both original statements unchanged and displays translations separately. It identifies the disagreement about replacement parts and gives both participants equivalent choices in their own languages.

Their visible choices may be written differently in English and Hindi, but MeaningSync connects them through the same underlying semantic meaning. A decision is resolved only when both independently select compatible meanings.

The final output is called a clarity receipt, not a contract. MeaningSync does not verify anyone’s identity, provide legal advice, or claim that translation is perfect. Its purpose is to help two people discover a misunderstanding before it becomes a dispute.

How I built it

I built the frontend with Next.js, React, and TypeScript. The backend uses FastAPI and Python.

SQLAlchemy and Alembic provide durable, versioned session persistence. The judge-ready local build uses SQLite, while the persistence layer is also compatible with PostgreSQL for a future production environment.

I built both shared-device and separate-device participation. In separate-device mode, the customer can create a single-use invitation for the service provider. The invitation expires, cannot be reused, and creates role-bound credentials so one participant cannot perform actions as the other.

For Live conversations, participants can type messages or use OpenAI Realtime transcription. A participant reviews the transcript before submitting it. The reviewed transcript becomes part of the same chronological conversation as typed messages, while the original transcription remains available as provenance. MeaningSync does not generate an AI voice or store raw audio.

Every conversation message preserves its original text, speaker, language, timestamp, and message ID. Translations are stored as separate views and never silently replace the original evidence.

I also built deterministic English and Hindi–English demos. They use the same six-step interface as Live Mode, but they require no OpenAI API key, microphone, PostgreSQL database, or paid API request. This gives judges a repeatable way to experience the complete product locally.

How I used GPT-5.6

GPT-5.6 performs the agreement reasoning inside Live Mode through the OpenAI Responses API.

It compares the conversation and returns structured agreement data that separates terms into:

  • Aligned
  • Conflicting
  • One-sided
  • Not discussed

Instead of producing a generic summary, GPT-5.6 must identify the specific agreement item, its status, each participant’s meaning, and the original message evidence supporting that conclusion.

I also use GPT-5.6 for backend-only English–Hindi localization. The backend validates important details such as numbers, currencies, quantities, negation, and whether something is included or charged separately.

If a required translation fails validation, MeaningSync preserves the original evidence and does not pretend that the translated meaning is trustworthy.

This distinction is important: GPT-5.6 helps compare meaning, but the application owns the evidence, workflow state, authorization, validation, private decisions, confirmations, and receipt integrity.

How I used Codex

I used Codex throughout the project to help turn the product idea into a working application.

Codex accelerated the FastAPI workflows, structured analysis integration, state-versioned persistence, separate-device authorization, bilingual interface, deterministic fixtures, automated tests, and submission documentation.

I remained responsible for the product, engineering, safety, and experience decisions. I repeatedly tested the product as if I were a customer or service provider and changed the direction when the technically correct solution was still confusing.

The clearest example was the clarification flow.

My first version worked logically, but it asked several similar clarification and teach-back questions. When I tested it, the experience felt more like a questionnaire than a helpful conversation. Simply changing the button labels did not solve the real problem.

I redesigned the product into six guided steps, added a chat-style conversation, replaced technical agreement labels with What matches, Needs a decision, and Not discussed, and changed repeated free-text clarification into private choice-based decisions.

Codex helped me implement that redesign across the frontend, backend state model, persistence, API contracts, and tests. It also helped me verify migrations, restart recovery, responsive layouts, separate-device access, and deterministic Demo behavior.

Codex and GPT-5.6 therefore have different roles in MeaningSync:

  • I used Codex as my development collaborator while building and testing the product.
  • GPT-5.6 runs inside Live Mode to compare agreement meaning and support bilingual equivalence.

Challenges I faced

Preserving evidence while translating meaning

I did not want a translated sentence to silently replace what someone actually said.

Every message therefore keeps its original text, language, speaker, timestamp, and provenance. A translation is displayed separately, and agreement evidence always points back to the original message ID.

This also means a participant can inspect the original statement if a translation appears incorrect.

Comparing decisions across languages

I could not safely compare the visible Hindi and English labels because equivalent meanings can be expressed using completely different words.

I solved this by giving localized choices stable semantic IDs. Two differently worded selections resolve a decision only when their semantic IDs represent the same meaning.

Preventing one participant from influencing the other

If the first participant’s choice were immediately visible, the second participant could simply copy it.

I designed private decision submission so the first response remains hidden until the second participant has answered. This gives the comparison more meaning and avoids leading the second participant.

Avoiding repetitive AI questioning

My early clarification flow asked several questions that were logically valid but felt repetitive to a non-technical user.

I reduced the experience to the smallest decision needed to move forward and removed mandatory teach-back from the visible journey. This was one of the most important product changes I made during the project.

Making the project judge-ready without deployment

Live analysis and translation require an OpenAI API key, but I did not want judging to depend on credentials, external infrastructure, or a paid request.

I built deterministic English and bilingual demos that reproduce the complete flow without making an OpenAI request. I also added a verification script and a judge guide so the project can be tested locally using a repeatable path.

Accomplishments I’m proud of

  • I built a complete bilingual journey from conversation to separate confirmation and clarity receipt.
  • I preserved immutable original evidence while keeping translations clearly separated.
  • I created agreement analysis that distinguishes matching, conflicting, one-sided, and undiscussed terms.
  • I built equivalent private decision choices across English and Hindi.
  • I supported shared-device and separate-device participation without requiring accounts.
  • I combined typed messages and Realtime-transcribed audio in one chronological conversation.
  • I added durable, backward-compatible session state and restart recovery.
  • I created deterministic judge demos that require no API key or paid OpenAI request.
  • I tested the experience across desktop, tablet, and mobile layouts.
  • I built a substantial automated verification suite covering backend behavior, frontend behavior, migrations, authorization, translation safety, and receipt integrity.

What I learned

The biggest thing I learned is that correctness alone does not create clarity.

A system can ask logically valid questions and still make people feel lost. For this kind of product, the best AI experience is not a long explanation or a polished summary. It is a small number of precise decisions, shown in language each person understands, with the original evidence always available.

I also learned that multilingual agreement checking is not just a translation problem.

The product needs stable semantic meaning beneath localized text. It must preserve numbers, currencies, quantities, negation, and the difference between “included” and “charged separately.” It also needs to behave safely when a translation is unavailable or uncertain.

Finally, I learned that a deterministic demo is not only a submission convenience. It is part of the product’s quality. It gives me a reproducible way to test the complete experience without hiding how the real Live architecture works.

Privacy and safety

I made the privacy boundaries visible throughout the experience.

Both participants must accept a clear notice before their conversation is processed. Finalized conversation text may be sent to OpenAI for translation and agreement analysis.

MeaningSync does not expose API keys, internal prompts, invitation secrets, bearer credentials, another session’s information, or one participant’s hidden decision to the other participant.

Raw audio is not stored. If a participant uses audio, the resulting transcript must be reviewed before it is submitted as conversation evidence.

If translation fails, the original statement remains available. MeaningSync does not invent a localized meaning or allow a required translation to appear trustworthy when its semantic equivalence could not be validated.

The clarity receipt records what the participants confirmed they understood. It is not a legal contract, an identity verification system, or a substitute for legal advice.

Current limitations

  • The current multilingual experience supports English and Hindi only.
  • Live agreement analysis, translation, and transcription require an OpenAI API key configured on the backend.
  • Participant credentials control application roles but do not verify real-world identity.
  • Translation can be imperfect, which is why the original evidence always remains visible.
  • Separate-device state synchronization currently uses polling rather than full realtime updates.
  • The submission is a judge-ready local test build rather than a hosted application.
  • I have not yet tested the workflow with real customers and service providers at production scale.

What’s next for MeaningSync

My next step would be to test the workflow with real customers and service providers and observe where they still become confused.

After that, I would add more languages, improve accessibility, replace polling with realtime synchronization, and strengthen production abuse controls and data-retention tools.

The central principle would remain the same:

Preserve what each person said, surface only the differences that matter, and let both people confirm the same understanding in their own language.

Built With

Share this project:

Updates