A Small Review Protocol for Relationship Diagrams

This note proposes a lightweight review protocol for a person-to-person relationship diagram. It is intended as a technical discussion of data quality and handoffs, not a proposal for an on-chain transaction, governance vote, clinical assessment, or new community integration. The examples are fictional. I am associated with the Genogram Maker project, and AI assisted the preparation of this note.

A diagram is a claim, not just a layout

A visual connection compresses several choices into one line: which two records are involved, what the line means, whether it applies at the time being described, and how confidently the author knows that information. A reader may not see those choices unless the author explains them. A tidy graph can therefore be misleading even when every individual label looks plausible.

The first review step is to state the intended question. A teaching example may explain how different kinds of relationships can be drawn. A planning conversation may need only the people participating in a particular activity. A historical reconstruction may have to distinguish first-hand evidence from later recollections. These are different tasks, and collecting every available detail is not automatically a better answer to any of them.

A useful scope statement has three parts: who the intended reader is, what the drawing is supposed to help that reader understand, and which categories of information are deliberately outside scope. It can fit in a few sentences. If the audience changes, revisit the scope rather than assuming that a version suitable for a private conversation is also suitable for an open page.

Separate records from display names

Imagine an invented exercise containing two people called Sam and a third person who is sometimes called Alex and sometimes Alexandra. A node label alone cannot tell a reviewer whether the Sams are duplicates or which name belongs to the same individual. Assign a local working identifier to each proposed record, then keep display names as attributes. The identifiers need not be published; their purpose is to make review precise.

Avoid merging records because their names or dates look similar. Instead, note the source of each proposed match and the reason it is being considered. If the evidence is incomplete, keep the records separate until a knowledgeable reviewer can resolve them. A visible question mark or an explanatory note is more honest than a silent merge that changes the meaning of several connections at once.

A working table can also record a person's preferred display label, whether a label is a pseudonym, and the date at which a source was reviewed. Keep the table as small as possible, and apply the same access restrictions as the diagram. The point is to make the drawing reviewable, not to build a permanent dossier about people who did not agree to that use.

Model each edge as a separate assertion

Represent an edge as a specific assertion rather than as a generic statement that two people are related. A practical review record might contain a subject identifier, an object identifier, a relationship type, an optional time range, a source note, and a confidence qualifier. Those fields are a conceptual model; a drawing tool may expose a different interface and need not implement this exact schema.

For example, an exercise may state that one fictional person helped care for another during a particular school year. That assertion does not establish parentage, partnership, legal responsibility, or a continuing role after the stated period. If another source says something different, preserve the distinction and ask what the diagram's purpose requires. Two statements can coexist as attributed reports without being presented as a single resolved fact.

Direction also matters. A line that has a direction in the working data can become ambiguous when the drawing is rearranged. Before sharing, trace several edges from endpoint to endpoint and confirm that the legend explains their meaning. Do not rely solely on color: readers may print in grayscale or use displays on which similar colors are difficult to distinguish.

Use a provenance ledger without overcollecting

A provenance ledger is a small companion record explaining where each claim came from and what remains uncertain. It may refer to a fictional exercise sheet, a participant's correction, or a dated source that the author is permitted to use. Use references appropriate to the sensitivity of the material. A claim such as “based on a conversation, date approximate” can sometimes provide enough context without copying a private conversation into another file.

Distinguish the source's statement from the editor's interpretation. If a source says that two people lived in the same household, a review note should not turn that fact into a different relationship merely to complete a template. Similarly, an empty field means the value was not supplied; it does not mean that a hidden default is true.

When evidence conflicts, add a review item rather than silently selecting whichever entry fits the layout. The resolution might be to ask a participant, retain both attributed accounts, remove the claim from a particular copy, or explicitly mark the connection as unresolved. Which response is appropriate depends on the audience, consent, and consequences of getting it wrong.

A bounded validation pass

A practical first pass can check structure before appearance. Confirm that each displayed node maps to one working record, each connection has two valid endpoints, each visible symbol occurs in the legend, and dates or ranges do not contradict the source notes. Then look for orphan nodes, duplicate labels, lines that visually cross without connecting, and text that becomes unreadable at the intended export size.

Next, test a sample of claims against the ledger. Include ordinary-looking edges as well as unusual ones; errors are not always visually dramatic. Ask another authorized reviewer to explain what they think a line means before showing them the intended interpretation. If the two explanations differ, revise the symbol or legend rather than assuming the reader should know the author's convention.

Finally, review the output file itself. Open the exported image, inspect the beginning and the final note, follow representative lines, and check whether any working annotations were included unintentionally. A completed export operation proves only that a file was produced. It does not prove that the right revision was exported or that its contents are appropriate for every recipient.

Where automation helps and where it stops

A browser-based drawing workspace can reduce the mechanical work of arranging nodes and changing a draft. For example, https://genogrammaker.org/ provides a place to create relationship diagrams, use optional AI assistance, and export an image. Its published free plan describes two projects with up to fifty people per project and PNG export, with a limited monthly AI credit allowance for signed-in users. Features and limits may change; consult the current official plan when deciding whether it meets a particular need.

Automated drafting can suggest a layout from supplied notes, but generated content must be checked for invented people, unsupported relationships, and false precision. A fluent answer is not a source. Give the tool only information suitable for its actual processing conditions, inspect its published privacy terms, and do not assume that a browser interface proves local-only processing or any particular certification.

No diagram tool can decide on behalf of the people represented whether the information should be collected, shared, or retained. Use fictional examples when practicing, obtain appropriate consent for real information, and avoid adding medical interpretations from visual patterns. Clinical or legal questions require qualified advice and relevant evidence beyond a drawing.

Design the handoff and correction path

Deliver a short note alongside the reading copy: its intended purpose, the date or version, the conventions used, known gaps, and a way for an authorized person to request corrections. A focused copy may intentionally omit branches that are not relevant to its task. Say that it is a partial view so that omissions are not mistaken for a complete account.

Before sending, consider whether labels or combinations of events identify someone even if their name has been removed. Reduce unnecessary detail, restrict the audience, and avoid redistributing editable source files unless the recipient needs them. Privacy safeguards are context-dependent; replacing names alone does not guarantee anonymity.

When a correction is received, locate the underlying record and each affected edge before updating the image. Record the reason for the change without duplicating unnecessary sensitive details. If previous readers may rely on an incorrect copy, decide how to notify the appropriate recipients and which version should be retired. A correction mechanism is part of the design, not an admission that the original review had no value.

The protocol is deliberately modest: define the question, separate records from labels, give each connection a meaning and source, review the actual export, and make corrections possible. These steps cannot eliminate every ambiguity, but they make a diagram easier to understand, challenge, and improve without treating visual neatness as proof.