Model relationships that help answer real tasks

Relationships make a memory useful when the query does not repeat the source wording. A task about a deployment may need the service, repository, environment, owner, last decision and operating procedure connected to it.

Start with a small relationship vocabulary grounded in retrieval questions. Useful relationships may include:

• a person owns a service;
• a decision applies_to a project;
• a task depends_on another task;
• a document supports a decision;
• a record supersedes another record;
• an event changed an entity;
• a preference has_scope a project or communication channel.

Define direction and meaning. owns might mean operational responsibility, commercial ownership or record authorship if left vague. Split relationships when those differences change retrieval or permission decisions.

Give relationships their own provenance and validity. The fact that one person owns a service can change independently of either entity. A relationship record should point to the source that established it, carry effective dates and support supersession.

Keep co-occurrence as a weak discovery signal rather than turning every shared mention into a graph edge. Promotion into a durable relationship needs a typed statement or a rule that can be reviewed.

Entity resolution is part of the write path. Two people can share a name, and one project can have a shorthand label that overlaps another. Use stable identifiers from trusted systems where possible. When identity is ambiguous, retain an unresolved mention linked to the source rather than attaching it to the nearest matching entity.

Keep documents and semantic search alongside graph traversal. Relationships support bounded traversal and current-state questions. Document retrieval handles explanations, detailed procedures and material that has not been reduced to structured records.