ShiftSync

• 

Lost in the shift? Not with ShiftSync.

“Mostly finished” can become “finished” somewhere between one operator leaving and the next taking over. The words barely change. The next decision might.

ShiftSync is a two-way shift-handoff app for data center operators. It turns voice or typed notes into a structured handoff, asks about important gaps, and gives the incoming shift a briefing linked to the original evidence. Then it asks them to explain critical details in their own words.

Not just a record of what one shift said. A chance to catch what the next shift heard.

A cleaner summary can still carry the wrong meaning.

An operator says maintenance is “mostly finished.” Testing was postponed, but the reason stays in somebody’s head. A vendor’s expected return becomes an assumed completion date. Both shifts leave the conversation thinking the handoff worked, while carrying different pictures of the same equipment.

We wanted to build around that difference.

Organizing notes helps people find information. Summarizing helps them read it. Neither, by itself, exposes an assumption or checks whether an interpretation matches the source.

ShiftSync focuses on what can disappear between those steps: unfinished work, decision rationale, restrictions, missing confirmation, and uncertainty. The goal is to ask useful questions before the outgoing operator leaves—not make the incoming operator reconstruct the conversation later.

That also means respecting fatigue. A handoff should not become an endless questionnaire. We designed around natural language, a small clarification budget, quick corrections, and an explicit “I don’t know” answer.

Carry the context into the next shift.

• Capture by voice or text. Describe the shift naturally, then review the structure proposed from that account.
• Clarify important gaps. Ask up to three adaptive questions, one at a time, rather than repeat everything already provided.
• Preserve the “why.” Keep a postponed test connected to its reason, restrictions, and conditions.
• Show uncertainty explicitly. Distinguish confirmed, reported, unverified, and unknown claims.
• Keep review separate. Show whether an extracted fact has been checked or edited without treating that action as independent verification.
• Brief by priority. Bring critical and unresolved items forward, with source quotes and follow-ups.
• Separate receipt from interpretation. Acknowledgment records receipt; an open-ended check compares the incoming operator’s answer with the handoff.
• Keep unresolved work visible. Open follow-ups can remain after communication is complete, including work whose owner is still “To be assigned.”

An illustrative handoff

Imagine an outgoing operator says: “UPS-B maintenance is mostly finished. Testing is postponed because the replacement component hasn’t arrived.”

A summary that collapses this into “maintenance complete” changes the meaning. ShiftSync is designed to preserve the unfinished status, its rationale, and the information that still needs clarification. The outgoing operator can supply more context or explicitly leave a detail unknown.

The next shift sees the unresolved work alongside its evidence. If their answer assumes testing can begin because maintenance is complete, the understanding check can point back to the contradiction.

This example illustrates the interaction, not a measured test result. The purpose is to make the difference discussable—not authorize an equipment operation.

1. Capture the account. The outgoing operator records or types a note. In the live voice path, transcription happens after recording, before analysis.
2. Propose structured facts. Extraction identifies equipment, work, decisions, rationale, and other handoff details, with supporting source quotes.
3. Find the gaps. Deterministic logic evaluates the available information, prioritizes missing details, and selects the next clarification within the question budget.
4. Clarify without forcing a guess. Short answers add context. “I don’t know” preserves an unknown rather than requiring a confident-looking answer.
5. Review and submit. The outgoing operator checks critical extractions and can edit or reject them before submission.
6. Brief and acknowledge. The incoming operator receives the prioritized handoff and records receipt separately.
7. Explain and compare. Open-ended answers are checked against the reviewed handoff. Feedback includes relevant source evidence. Each check allows at most two attempts; unresolved misunderstanding moves into clarification rather than endless retries.

Two dimensions remain distinct throughout.

Certainty describes the claim: confirmed, reported, unverified, or unknown. These labels represent the information available in the handoff, not an independent inspection of the equipment.

Review describes the extraction: whether an operator checked, edited, or rejected what the system proposed. Confirming that “mostly finished” was extracted correctly must not turn it into “finished.”

Follow-ups form another separate track. Completing the communication workflow does not close operational work. Neither open nor unassigned follow-ups block handoff completion under the current contract.

Acknowledgment and check completion are software states. They do not prove comprehension, certify safety, or replace authorized facility procedures.

React: one task at a time

The frontend uses React, TypeScript, Vite, and Tailwind CSS, with React Router for navigation and TanStack Query for server data.

The outgoing experience separates Capture, Clarify, and Review. The incoming experience separates the briefing, acknowledgment, understanding check, and follow-ups.

That structure makes the next action clear without hiding the evidence. Certainty badges, review indicators, and source quotes carry different meanings instead of collapsing into one reassuring green check.

The redesigned interface uses a light, dotted canvas, white reading surfaces, Urbanist typography, and restrained glass treatments. The mascot gives the product a recognizable identity without acting as a safety indicator or replacing operational information.

FastAPI and SQLite: explicit handoff state

The Python backend uses FastAPI, Pydantic, and SQLModel with SQLite.

We divided the architecture by responsibility. Language models handle interpretation and wording. Deterministic code owns state transitions, question budgets, gap priority, certainty constraints, and check progression.

Structured model outputs are validated before use, and proposed evidence quotes are checked against the source. A plausible sentence is not enough to establish a fact or advance every workflow state.

Persistence also matters beyond the summary. Reviewed information, uncertainty, and outstanding work need to remain part of the same handoff instead of becoming disconnected notes.

NVIDIA Nemotron: five language jobs

We use language generation for specific tasks rather than asking one unrestricted prompt to run the whole process.

1. Extraction. Convert an operator’s statement into proposed items and facts. Capture decisions and reasons when present, preserve uncertainty, and attach supporting quotes rather than fill gaps with invented details.
2. Clarification wording. Phrase a short question about a gap selected by code. The model makes the question conversational; it does not receive an unlimited license to keep asking.
3. Briefing. Turn reviewed information into concise incoming-shift text while retaining priority and uncertainty. The briefing is another view of the handoff, not a new source of operational truth.
4. Question generation. Ask an open-ended question about a critical item. The operator must explain the situation rather than simply agree with a yes/no prompt.
5. Answer grading. Compare that explanation with the handoff, identifying conveyed facts, omissions, and contradictions. Feedback is paired with evidence, while deterministic constraints limit how verdicts affect the workflow.

The team documented a live Nemotron backend run through the scripted handoff, including identifying an incoming answer that treated incomplete work as complete. That demonstrated the pieces working together in a synthetic scenario; it was not a real-operator study or a comparative benchmark.

Whisper: from spoken account to reviewable text

The voice implementation supports local transcription through faster-whisper, with an OpenAI transcription option.

Speech is an input method, not an exemption from review. A transcript still passes through extraction, clarification, and operator checking before becoming the submitted handoff. Text entry provides another way into that same workflow.

Photon: an optional messaging bridge

The optional TypeScript bridge uses Photon’s Spectrum SDK to forward iMessage text and voice notes into the backend workflow.

The goal is to bring an account into the same handoff process rather than create a second, disconnected record. Review and submission remain in the web app, where the operator can inspect structured details and evidence together.

Fixtures and live integration answer different questions

The frontend’s fixture mode makes the interaction reproducible without transcription or model calls. It supports repeatable interface work and demonstrations, but it is not evidence that speech recognition or a hosted model succeeded.

Tests exercise workflow rules and handlers, while the documented live-model backend run checks a different boundary: the language integration participating in the scripted journey.

Real microphone-to-handoff validation and confirmed live iMessage delivery remain separate integration tasks. Implemented paths and mocked tests do not substitute for those checks.

Building as a team

Ethan led frontend, design, and demo work. Diego owned voice and transport. Akshi owned AI extraction, prompts, providers, and grading. Aditri owned backend state, storage, planning, evaluation, and tests.

Claude Code, Cursor, and Grok Bot supported implementation, research, and coordination. Shared contracts helped keep independently developed pieces aligned, especially where the frontend’s interpretation of a state had to match the backend’s rules.

Technologies

Category	Technologies
Frontend	React, TypeScript, Vite, Tailwind CSS
Navigation and data fetching	React Router, TanStack Query
Backend	Python, FastAPI, Pydantic
Persistence	SQLModel, SQLite
AI	NVIDIA Nemotron
Speech-to-text	faster-whisper, optional OpenAI transcription
Optional messaging	Photon Spectrum SDK, TypeScript
Development tools	Claude Code, Cursor, Grok Bot

• Short answers lose their subject. “It’s still in maintenance bypass” depends on the preceding question. Clarification needs to preserve which item is being discussed instead of creating an unrelated equipment claim.
• Unknown is not a negative answer. “I don’t know if they finished” must not become a confident statement that work is incomplete. The normalized value and its certainty both matter.
• A relevant question can still be the wrong question. Repeating a question about remaining work is unhelpful when the selected gap concerns clearance. Question wording needs to stay focused on the gap code actually selected.
• Provider responses can be empty or off-topic. Live integration required handling these cases explicitly instead of letting a malformed response quietly change the workflow.
• Completion language can overpromise. “Acknowledged,” “checked,” and “closed” sound similar but mean different things. We kept communication status, answer consistency, and operational follow-ups distinct.
• Demo polish can conceal missing validation. A smooth fixture flow says little about microphone capture, transcription quality, or live messaging. Keeping those paths honestly labeled became part of the product work.

We built a handoff interaction that continues after the summary.

The outgoing side can expose missing context before submission. The incoming side can inspect the evidence and explain its interpretation. Between them, the system represents uncertainty instead of quietly smoothing it away.

We are particularly proud of the distinctions carried through the product:

• Certainty is separate from operator review.
• Acknowledgment is separate from an understanding check.
• Completed communication is separate from finished operational work.
• Source-grounded feedback is separate from a claim of guaranteed comprehension.

The prototype also supports two useful demonstration paths: reproducible fixtures for the interface and a documented live-model backend journey. Keeping those separate lets us show progress without presenting scripted behavior as proof of general reliability.

The integration work also exposed concrete problems worth solving: misplaced item references, off-topic clarification, and unknown values being interpreted too confidently. Those failures helped us improve the boundaries around the model, not just the wording of its prompts.

• Uncertainty needs structure. A warning sentence can disappear during summarization. A separate certainty field can remain visible through extraction, review, briefing, and feedback.
• Evidence is part of the interaction. Showing the original quote gives operators something concrete to inspect when interpretations differ.
• The state machine is a product decision. Separating receipt, checking, clarification, and follow-ups changes what users believe a completed handoff means.
• A small question budget forces prioritization. Asking everything is easy to describe and exhausting to use. Choosing what matters is the harder design problem.
• Different tests answer different questions. Fixture tests, rule tests, live integration, and human evaluation are complementary. None should stand in for all the others.
• Visual clarity cannot replace semantic clarity. A beautiful interface still fails if its labels imply more certainty than the underlying information supports.

First, close the remaining integration-validation gaps: real voice capture through transcription and extraction, live Photon delivery, and the redesigned frontend against the integrated backend.

Next, evaluate beyond a scripted journey. We want to compare unchanged handoff notes, a basic AI summary, and ShiftSync using realistic scenarios. Transferred information should be measured alongside introduced errors, missed uncertainty, and operator effort—not just whether the result sounds polished.

Then bring those scenarios to operators and learn where questions are useful, where the interface creates friction, and where feedback is misleading. Any reported results should come from actual runs with clear limits, especially when simulated operators are involved.

The goal is not to make every handoff sound certain.

It is to make uncertainty harder to miss—and carry the context into the next shift.

ShiftSync. Carry the context into the next shift.

Built With

• cursor
• grok
• nvidia
• photon
• react
• sqlite
• sqlmodel
• tailwind
• tanstack
• typescript
• vite