A reviewable data contract for family relationship diagrams

A diagram application turns a set of people and relationships into a visual representation. The rendering can look precise even when its underlying inputs are incomplete, disputed, or intended for a different audience. For developers and reviewers, the useful question is not only whether a graph can be drawn. It is whether the representation can be inspected, corrected, and shared without silently turning unknown details into facts.

This guide describes a conceptual review contract for fictional examples. It is prepared on behalf of the Genogram Maker project with AI assistance; it is not an independent product evaluation, a claim about internal implementation, or a substitute for legal, clinical, or security advice. The examples are not real family records. A production system needs its own requirements, privacy review, and tests.

Define the boundary before the schema

Begin by describing the purpose of the diagram and its intended audience. A classroom illustration explaining a parent connection needs less detail than a private working diagram. A reviewer preparing a public presentation may need a version that excludes dates, notes, and identifiers. These are different outputs, even if they originate from the same fictional source data.

A practical contract should distinguish three layers: source claims, working representation, and reading copy. A source claim is what a note actually says. A working representation records how the author currently models it. A reading copy is an export selected for a specific audience. Keeping those layers conceptually separate makes it easier to explain why a relationship appears and to remove a detail without rewriting the entire project history.

The contract should also support an explicit unknown state. An empty field does not mean the system is authorized to infer a value. An approximate year should remain approximate, and a missing relationship should not become a default parent connection merely because that produces a visually balanced tree.

Model a minimal fictional example

Consider four fictional identifiers: person A, person B, person C, and person D. Suppose one note says A is a caregiver for C, while another says B is C's parent. An implementation may use different fields or a different graph structure, but the review should retain the distinction between a caregiving role and a parent relationship. The notes do not establish any further connection between A and B.

For each person, record only the fields needed by the current purpose. A stable internal identifier can distinguish two people with the same display name. The display label can be corrected without requiring the author to treat it as a unique database key. If the system has to merge two duplicate entries, that decision should be explicit and reversible where possible.

For each connection, reviewers should be able to identify its endpoints, relationship type, any relevant time context, and the source or explanation behind it. These are review concepts, not a universal genogram standard. The correct representation depends on the domain and the people involved; avoid embedding assumptions about household structure, gender, or which relationships are important.

Preserve uncertainty in the editing workflow

A common failure mode is a presentation layer that forces a choice before the evidence supports it. For instance, a form may have a required date picker even though the note only says an event occurred around a year. Where the product permits it, preserve the approximate value or omit it. If the interface requires a precise value, do not silently invent one just to satisfy validation; record the limitation and choose an appropriate representation for the current exercise.

A source ledger can be simple: claim key, short description, source reference, review state, and sharing restriction. It should not become a reason to collect more sensitive information than necessary. For fictional exercises, label the records as fictional. For real material, assess whether each field is needed, whether people have agreed to the use, and what storage and retention rules actually apply.

Two sources can disagree without either being replaced by an unmarked default. Keep the disagreement in the working notes, indicate the unresolved state when appropriate, and decide whether the uncertain claim belongs in the reading copy. The goal is not to make the picture look complete at all costs; it is to make the representation explainable.

Treat layout as a separate concern

Layout algorithms solve a presentation problem. They do not prove that two nodes represent different people or that a line's meaning is correct. A review process should inspect data before rearranging a diagram for symmetry. Moving a node into a generation because it improves the layout may alter the apparent meaning unless the convention is clear.

Test the legend and the output at the intended size. Ask a reader who has not seen the editing view to trace a representative line and explain its label. If they cannot identify the endpoints or confuse a structural connection with an emotional description, revise the visual convention. Color alone is often insufficient, especially in grayscale copies or when readers use different displays.

An export is another representation, not an automatic proof of correctness. Reopen a generated image and check the title, legend, a representative branch, and the end of any explanatory note. A successful export notification proves only that a file was produced. It does not establish that private working notes were excluded or that a reader can interpret every line.

Review AI-generated suggestions as untrusted drafts

An AI feature may suggest people, connections, or a preliminary layout. Treat each suggestion as a candidate to compare with the supplied notes. A fluent sentence is not a source citation, and a plausible-looking relative is not evidence that the relative exists. For fictional examples, the reviewer can reject additions that were not part of the example; for real material, the stakes and applicable requirements may be higher.

Write review constraints in plain language: use only supplied information, do not infer a diagnosis, retain uncertainty, and do not make approximate dates exact. Then inspect the result rather than assuming the instruction was followed. Keep a way to revise the draft and identify which claims changed. A correction record should be proportionate and should not replicate unnecessary sensitive material.

One optional browser-based workspace is the genogram generator from Genogram Maker. It provides editable people and connections, optional AI assistance, and image export. Its stated free plan includes two projects with up to fifty people per project and PNG export; signed-in users have a limited monthly AI credit allowance. Check current official plans before depending on a specific limit. This guide does not assert how the service stores data or what infrastructure it uses.

Add practical acceptance checks

A useful test plan can be expressed without claiming that a particular application has already passed it. Start with fictional fixtures where two people have the same display name but different identifiers. The expected review outcome is that the people remain distinguishable. Add an approximate date and confirm that an exported explanation does not present it as an exact date. Add an unresolved connection and confirm that the reader can see the uncertainty or that the item is intentionally omitted.

Next, test a sharing boundary. Prepare two conceptual outputs from the same fictional working material: a private review view with a source note, and a presentation view without it. Compare the outputs against the stated audience and purpose. If an omitted note reappears in the presentation copy, the test should fail even if the picture looks polished. The test should describe observed behavior, not assume that a format or product automatically enforces the boundary.

Finally, test correction and handoff. A reviewer changes a label, records the reason, and checks that the relevant reading copy is regenerated or clearly marked outdated. The handoff should state the purpose, version, known uncertainties, and a route for reporting a concern. This does not require a public change log containing private background details.

The central design principle is modest: make the assumptions behind a diagram visible enough to review, and make the shared output no broader than its purpose. A graph can be useful without pretending to be a complete account of a family. Good data boundaries, clear conventions, and a deliberate correction path make the result more trustworthy than visual polish alone.