Core concepts

Organize parent and subordinate facts

Group broad factual propositions with the specific details that refine them without duplicating or flattening the record.

Fact relationships organize a dense factual record into readable branches. A parent fact states the broader proposition. A subordinate fact states a more specific detail, consequence, or component that naturally refines that proposition.

For example:

Parent: Police officers removed Defendant from the offices.
Subordinate: The officers prevented Defendant from driving home.
Relationship description: Preventing Defendant from driving is a specific consequence of the same police intervention.

Both facts remain independent records. The relationship adds an edge between them; it does not merge their text, evidence, people, dates, or links to claims and elements.

When a fact should be subordinate

Use a parent/subordinate relationship when the proposed child can be read naturally as a detail of the proposed parent. Common patterns include:

a general incident and one action taken during that incident;
a notice being sent and a specific demand or deadline in that notice;
an agreement being formed and a particular obligation in that agreement;
a general injury or loss and a specific component of that harm;
a course of conduct and a documented instance within that course.

The relationship should remain understandable without relying only on a shared date, source, person, or tag. Add a short description explaining why the narrower fact belongs under the broader one.

What is not a subordinate relationship

Do not create a fact relationship merely because two facts:

occurred on the same date or appear in the same source;
mention the same person, place, agreement, or meeting;
happened one after another;
are duplicate or corroborating accounts of the same proposition;
conflict with one another;
support the same claim or element; or
rely on the same evidence.

Those connections belong in date and entity metadata, evidence links, fact-element links, or the facts’ support and contest status. If the record contains a specific detail but no broader parent fact, keep the detail at the top level or identify the missing parent as a gap. Do not create a hypothetical parent solely to make the hierarchy look complete.

Build the hierarchy manually

Open Facts, then switch to Hierarchy.

Drag the more specific fact onto the broader fact to make it subordinate.
Choose Move fact only when its existing subordinate facts should remain at the top level.
Choose Move group when the entire branch should move intact.
Drop a fact in the top-level zone to remove its current parent.

Lattice blocks a move that would place a fact beneath itself or one of its descendants.

You can also open a fact’s metadata and use Relationships. Choose either This fact is parent of… or This fact is subordinate to…, select the related fact, add a useful description, and choose Add fact link. Existing descriptions can be edited, and a relationship can be removed without deleting either fact.

Multiple parents and display behavior

The proof graph can represent more than one parent for a fact when the same specific proposition genuinely refines more than one broader proposition. Use this sparingly: multiple parents can make the factual theory harder to read.

Dragging a fact in Hierarchy is a reparenting action and selects one parent for that branch. Use the fact’s Relationships editor for deliberate multi-parent links. Where a single display parent is required, such as a timeline branch, Lattice uses one valid parent for presentation while preserving the graph relationships.

Dates in a fact branch

Parent and subordinate facts do not automatically inherit or overwrite one another’s date metadata. Each fact keeps its own date and date precision.

For timeline ordering, Lattice may use a related branch date as a display anchor. An undated parent can be grouped near its earliest dated descendant, and an undated child can remain visually grouped with its dated branch. This affects presentation only; it does not populate a missing date_occurred value.

Ask Case Assistant to find relationships

Case Assistant can analyze the available fact set and return a ranked batch containing up to six high-confidence relationships. For example:

Find facts that should be subordinate. Treat a fact as subordinate only when it is a specific detail that naturally refines a broader fact about the same event or proposition. Return one proposal per high-confidence pair, cite both facts, and group ambiguous candidates as gaps.

Each proposal identifies the broader parent, the specific child, and the reason for the direction. Record references appear as readable linked labels; Lattice keeps the immutable record identifier behind each link so the citation remains precise.

Choose Accept change to add that relationship. Before applying it, the server confirms that both facts still exist, they are different records, the relationship is not a duplicate, and the new edge would not create a cycle. You can accept a correct card and dismiss the others. The assistant can also propose removing a relationship when the child does not actually refine its parent.

Large audits are intentionally batched to keep every card reviewable and the structured response reliable. After reviewing the first batch, ask Case Assistant to continue. Accepted relationships are already part of the graph and will not be proposed again.

Case Assistant should return an explanation rather than an action card when:

either fact’s text is unavailable;
the broader-versus-specific direction is uncertain;
the only connection is a common date, source, or participant;
the proposed parent is missing from the record; or
the relationship would duplicate or contradict the existing hierarchy.

Review checklist

Before accepting or adding a relationship, confirm:

The child is a detail, component, or consequence of the parent.
The direction is correct: broad parent, specific child.
Both propositions are supported by text you can inspect.
The records are not duplicates or merely corroborating accounts.
The connection is more than chronology or shared metadata.
The description explains the relationship in plain language.
Any additional parent clarifies rather than confuses the theory.
Dates, evidence links, and fact-element links remain accurate on each fact.

More examples

Proposed relationship	Result	Why
Notice was sent → notice required cure within ten days	Usually appropriate	The deadline is a specific term of the broader notice event.
Agreement existed → agreement contained a termination clause	Often appropriate	The clause is a specific contractual detail, if both facts are separately stated.
Two witnesses describe the same meeting	Not by itself	This is corroboration or conflict, not broad-to-specific structure.
Breach occurred → damages followed	Review carefully	Causation or sequence does not automatically make damages a detail of the breach.
Two unrelated events occurred on December 31	Not appropriate	A shared date is metadata, not hierarchy.
Specific harassment incident → missing general pattern fact	No relationship yet	Keep the incident independent and record the absent parent proposition as a gap.