Two product rulings made Aug 5, 2026. Both are decided; implementation is still pending. Together they resolve the two open decisions that household-harness scenarios HH-16 and HH-17 (main repo) name as blockers.
The 30-day TTL on on-behalf expected-party hints still gates any automatic behavior — an expired hint drives nothing on its own. But an expired hint may still place the visitor on Clara's candidate list, so Clara can ask.
An expected visitor texting on tour day with tour-specific questions (parking, which building, where to check in) clears the bar for Clara to ask whether they're connected to the known tour.
Status: decided, not built. HH-16 / HH-17 stay red until the candidate-seeding and ask-threshold changes land.
Baseline mitigations in every option: quiet-hours enforcement, consent-context logging (who provided the number, when, in which thread), STOP honored immediately, informational 10DLC campaign.
When the visitor is texting us and the requester is emailing us about the same tour, what is that in the data model?
Each person keeps their own channel-native conversation (his email thread, her SMS thread). The Tour record is the shared state — both conversations reference it, and expectedParties already carries the visitor. A reschedule from either side updates the tour; both sides are notified from the tour, not from each other's transcripts.
Single thread with two participants across two channels. Honest about "it's one deal," but requires reworking message authorship, channel semantics, the context loader, and consent tracking — a real refactor for no user-visible win. Neither person ever sees the other's messages anyway (email vs SMS).
One-way sends to her number; no Person record, no thread. Cheapest possible — but the moment she replies "can we do 3 PM instead?" she's an unrecognized new lead and Clara has no idea what she's talking about. Rejected unless we explicitly want a throwaway v0.
Create a Person for her with a phone identity claim and a "touring on behalf of <requester>" link. When she texts or calls in — even months later — recognition works (same machinery as the existing on-behalf linking, ADR-0101) and Clara has her context. This is what makes Option 1A's two-thread model actually converse.
Name + phone stored on expectedParties, nothing else (this is today's state). Fine for outbound-only; falls over on any inbound from her. Only sensible paired with Option 1C.
The confirmation, the pre-tour access instructions, and the post-tour follow-up already fire for the prospect at fixed lifecycle points. Each of those senders fans out to every expected party who has a phone/channel — same template, same timing, per-recipient channel. One code path, parity guaranteed by construction (a new touch added later reaches both people automatically).
A parallel sender keyed off the tour for non-prospect parties. Decouples risk from the main prospect path, but parity now lives in two places and will drift — the exact opposite of the "same as a regular prospect" ruling.
Her tour was booked before this ships. Options for the catch-up send once the design lands:
Once the fan-out exists, trigger the standard confirmation for her tour through the real code path (no hand-crafted message), inside the morning quiet-hours window. Same rule as the requester redrive: the product does it, not an operator.
Faster to her phone, but it's an operator-authored text outside the loop — the pattern we just spent a day eliminating.
1A + 2A + 3A + 4A: two linked conversations sharing the Tour as source of truth, the visitor becomes a real recognized Person, every existing tour touchpoint fans out to all expected parties on their own channel, and the visitor's confirmation is the first message through that pipeline — in the morning window.
Prepared overnight Aug 2→3, 2026. Context: the Aug 2 requester / the Aug 2 visitor tour (Camellia), Fede's parity + quiet-hours rulings in session. Related: incident record, death-path audit.