# The Graph Before the Screen

_Published 2026-09-03._

The previous CRM could store people. It could not reliably explain how those people were related to an institute, an applicant, a task, or a decision.

That gap is easy to hide in a screen. Add another filter. Add another status. Add an admin-only button. Eventually the interface appears flexible while the underlying graph remains implicit.

## Relationships are not decoration

The operational CRM starts with institutes, contacts, applicants, tasks, and statuses as explicit nodes and edges. An applicant can be linked to a contact at an institute. Tasks and statuses can move the case forward. Permissions can decide who may see or change each relationship.

The [Operational CRM case study](/work/enterprise-crm) describes the guiding rule: if the model cannot say “this contact at this institute,” the UI will eventually lie.

Moving from a legacy store is not a one-time import followed by a hopeful redirect. The useful path is a keymap, bounded batches, shadow reads where needed, and a cutover that can explain what happened to an old identifier.

The result is not a prettier CRM. It is an operational record that can survive a new role, a new workflow, and the person who has to understand it after the original migration team has left.