Long Family Archive — Inventory v2: Parent-Child Chain Linkage (Pass 2 delta)

Read-only delta over 01-inventory.json. No FamilySearch API calls. No site content modified. Generated for the 2026-05-28 audit.

Adds three per-ancestor fields — parent_pid, chain_id, generation_index — plus a supplementary extraction_method. v1 is untouched; output is 01-inventory.v2.json.

Source-priority finding (read first)

Priority 1 (explicit parent reference) returned ZERO across the codebase. Every chain data structure the site renders — the AncestorTable ancestors arrays, ChainPerson/ChainNode/DescentNode in relationships.ts / ancestors/data.ts / cousins/data.ts, and FamilyTreePage members — is an ordered array with no parent_pid / parent_id field. Parentage is encoded only by position. Therefore 100% of populated links use Priority 2 (ordinal); none are structurally asserted by an explicit field.

generation_index is per chain: 0 = the most-recent generation shown on that chain, increasing upstream. For chains that reach the living brothers (the /ancestors/* descents, the Plantagenet full chain, the cousin branches) g0 is the living generation; for self-contained line tables g0 is simply the youngest person in that table.

Counts

Pages where NO chain structure could be extracted

These pages carry ancestor rows but no extractable parent-child ladder. Every row on them is parent_pid: null, chain_id: null, extraction_method: "unresolved".

Per-line method log (required)

Method is ordinal wherever a chain was extracted (no structured/explicit-parent source exists), unresolved otherwise. source records which ordered array the chain came from.

Method notes & deliberate exclusions

• columns="loyalist" roster tables (battle rosters, Society-of-the-Cincinnati member lists) are NOT chains — they list peers, not generations. Dropped from linkage so no peer-as-parent edges are invented.
• Family-group tables (e.g. /lines/long, /lines/perry, /lines/swift, /lines/wall) interleave spouses and the spouses' own parents with the direct line, so birth years are non-monotonic. They fail the monotonic gate and are left unresolved rather than linked by raw position. The same individuals are linked where the site presents them as a clean descent (their /ancestors/* pages, or curated AncestorTable ladders).
• /lines/tree (FamilyTreePage) is a family-group aggregate (spouses tagged marriage, collateral siblings/children interleaved). Not safely linearisable by ordinal; every PID on it is also carried on a dedicated line page. Treated as a non-linearisable aggregate.
• Siblings & spouse-only nodes are filtered out of chains. A member described as a brother/sister/sibling of its neighbour, or as a wife/husband with no lineal descriptor, is removed before linking (e.g. James Coffin — Tristram's son but John Coffin's brother — was being linked as John's parent; now dropped). Lineal members who merely also have a spouse ("Son of X; husband of Y") and genuine collateral ladders ("collateral to our line" but internally parent→child, e.g. the Heman Swift Cincinnati line) are kept.
• Multi-table chains are stitched. Where one descent is rendered across several consecutive AncestorTables under a single <h2> (e.g. the Plantagenet "Full Chain", 26 generations), the tables are greedily merged while birth years keep trending and the boundary-overlap person is de-duplicated; a divergent branch (e.g. Eleanor of Aquitaine's Capetian line) correctly splits into its own chain.
• Cousin Y-chains prepend the mrca (most-recent common ancestor) to both the brothers' and the cousin's branch so the branch head's parent resolves to the shared ancestor.

Integrity checks (all pass)

• Birth-year direction: 0 edges where the parent is younger than the child.
• Self-parent edges: 0.
• Dangling parent_pid (not present anywhere in the inventory): 0.
• Non-standard PID format among parent_pid values: 0.

Generated by audit/build-inventory-v2.cjs (read-only; re-runnable).