THRESHOLD — A Considerate Doorway

• 

  The local decision record preserves the exact approved wording and states that no visitor received it.

• 

  The visitor faceplate displays the resident-approved bilingual local preview for a fictional delivery practice note.

• 

  The resident’s private rehearsal archive stores a local decision record for later review.

Inspiration

A visitor and a resident may both be trying to have a simple conversation at the door, yet the usual doorbell alert gives them little help. A visitor might prefer written replies, need another language, or ask for a step-free place to meet. The resident needs to understand that request and decide what to say. We built THRESHOLD to make that exchange clearer for both sides.

What it does

THRESHOLD is a local practice doorway with a resident desk, a visitor faceplate, and a simulated Alexa+ conversation. A fictional visitor starts an arrival with a purpose and a stated communication or access need. The resident sees reviewed reply choices and previews the exact words before choosing one. Once approved, the visitor faceplate displays that text. The resident can manage waiting arrivals, look back at saved decisions, and rehearse how a different need would change the response. Optional browser speech features can help select or read a preview where supported.

How we built it

We use a Node.js server to hold the arrival and resident's decision, so the resident page and local MCP tools act on the same state. A practice catalog combines seven visitor purposes with fifteen reviewed profiles, including compatible pairs of needs. Each response comes from an allowlist, and approval is tied to the current arrival and revision. The visitor faceplate receives a small projection of the approved result. Browser speech recognition can choose a preview and synthesis can read text, while the resident makes the decision. A local journal records the choice and source. The simulated Alexa+ client calls the same engine through Streamable HTTP MCP tools.

Challenges we ran into

The difficult moments happen when the situation changes between preview and approval. A resident might be looking at one arrival when another arrives, or a speech callback might finish after the displayed reply has changed. We made approvals specific to the exact arrival and preview, and we clear outdated speech and screen state as the exchange moves on. Network timeouts create another delicate case because a decision may have reached the server even if the browser did not receive the answer. The resident station leaves that uncertain choice for the person to check instead of quietly repeating it. We also keep the fictional practice source visible so a generated scenario is understood as a rehearsal.

Accomplishments

The local experience now follows a visitor-started arrival all the way to a resident-approved message on the visitor faceplate and a saved decision. It includes written, spoken, bilingual, plain-language, and step-free practice situations, with reviewed combinations when a visitor has more than one need. A resident can handle a queue without losing the current choice, review the history, remove selected records, and compare an alternative need without changing what was actually sent to the local faceplate. The simulated Alexa+ route shares the resident station's current arrival and approval rules.

What we learned

We learned that language and communication channel are separate choices. A bilingual written reply, for example, answers a different request from a spoken reply in one language. We also found that selecting text by voice is useful only when the resident can still inspect and approve the exact result. Keeping the arrival source beside the saved choice helps explain what happened later. The local faceplate demonstrates that approval flow. Evaluating delivery to a real visitor and accessibility on real devices will require further work with people using those modalities.

What's next

We want to complete a richer visitor and resident exchange in which a visitor can answer a follow-up question and the resident can still choose from reviewed words. We will keep the current-arrival checks as that conversation grows. We also plan to test the display and speech experience with people who use different access methods, then investigate authenticated doorbell events and actual visitor delivery with the same clear approval step.

Built With

• css
• html
• javascript
• model-context-protocol
• node.js
• streamable-http
• web-speech-api