Parent-Approved Contacts Are an Architecture Rule, Not a UI Filter

I reached Parent-Approved Contacts Are an Architecture Rule, Not a UI Filter through a repeatable lab problem rather than a design slogan. A contact list is not a security boundary if the device can still dial or receive arbitrary identities underneath it.

LOUP treats approved contacts as backend-controlled state. The device renders the allowed list, while backend and PBX-facing logic are expected to enforce who can be provisioned, called, blocked or revoked. That keeps authorization outside the display code and makes a lost or modified UI unable to create new communication rights by itself.

The useful debugging step was separating signal path, state and timing instead of modifying all three and then guessing which change mattered. Evidence marker: parent-approved-contacts.

Authorization belongs where identities and routing decisions are authoritative. The screen should reflect policy, not invent it. That distinction also makes regressions cheaper to isolate when hardware, firmware and infrastructure are changing in parallel.

Project evidence

LOUP engineering marker: parent-approved-contacts. This note records the design or debugging lesson without publishing device credentials, private keys, customer data or manufacturing secrets.