One Interface, Full Record

Expectation. The building shall provide a single primary digital interface for all support interactions — reporting, tracking, history, and communication — and that interface shall be the authoritative record of every request.

Required.

• The building designates one interface as the primary channel for support requests. All requests submitted through it are the authoritative record.
• The resident submits a request, tracks its progress, views its history, and communicates about it within the same interface.
• The resident can view every request they have submitted — open and resolved — including full history, status transitions, and resolution descriptions.
• The resident can add information, images, or clarification to an open request.
• The resident can indicate whether a resolved request actually addressed the issue. Disputing a resolution reopens the record.

Recommended.

• When a request is received through a secondary channel — phone call, email, in-person — it is entered into the primary interface and visible to the resident in the same request list.
• Household members or designated contacts can view requests associated with their unit.
• The resident can categorize a request by severity at submission: emergency, urgent, or routine.
• The resident can view which personal data is associated with their support requests and can request its deletion after resolution.

In practice.

A resident submits a request about a persistent odor in the hallway. A technician visits, inspects, and adds a note to the record: source identified as ventilation, HVAC team notified. The resident opens the interface and sees the technician's note in the same thread as their original report. They did not call the office to ask what happened. The record accumulated context from both sides in one place.

A resident calls the front desk about a broken hallway light. The front desk logs the request in the building's digital system. The resident opens their interface and sees: hallway light reported, received today. They can follow its progress alongside their own submissions. The call did not create a parallel, invisible record.

A request for a persistent draft near the bedroom window is marked resolved: weatherstripping replaced. The resident still feels the draft. They indicate the resolution did not address the issue. The request reopens. The history — original report, first resolution attempt, resident's dispute — is preserved in a single record.

Failure modes.

Parallel record. The resident reports a noise issue through the interface. They mention it again to the concierge the next day. The concierge creates a new entry. Two records now exist for the same issue, each with partial information, tracked independently. When one is resolved, the other remains open. Neither contains the full picture.

History erasure. The resident views their request history to reference a recurring problem. Requests older than 90 days have been purged. The resident cannot demonstrate that the same issue was reported — and resolved — three times previously. The system optimized for storage at the expense of the resident's record.

Dispute without effect. The resident marks a resolved request as unresolved. The system records the dispute but does not change the status or trigger reassignment. The dispute is logged; the request remains closed. The resident's ability to contest resolution exists in the interface but not in the workflow.

Test.

1. Submit a request. Add supplementary information. Confirm: both appear in a single record within the primary interface.
2. View request history. Confirm: all previously submitted requests — open and resolved — are visible with full status history.
3. Mark a resolved request as unresolved. Confirm: the request reopens and the dispute is recorded.
4. Submit a request via a secondary channel (phone or in-person). Confirm: the request appears in the resident's primary interface.