0007 Relation network: claim ledger, superposition and views, UUID identifiers

At the request of the arkive session (2026-10-12), 06-Relation network is newly written.

What

• The name is “relation network”. arkive asked for “06 Connection”, but “connection” in section 5 of HGP-0006, in the September Hahoe Genesis Protocol (HGP) specification, means introducing living people to each other. To avoid using one word with two meanings, we chose “relation network”, the term arkive uses. The September “connection” is recorded in 05-Glossary as “introducing people”.
• Claim ledger. Relations are only ever appended to claims.jsonl. Lines are of three kinds: node (node), claim (claim) and view (view). A graph database is an index that can be rebuilt.
• The claim is the smallest unit. Names, birth and death dates, and relations are all claims with a source position. Claims without a source are not made.
• Three states: candidate candidate, confirmed confirmed, retracted retracted. Only people granted the stamp right can confirm or retract (decision 0006). AI can raise even a counterargument only as a new candidate.
• Superposition and views. All claims about the same target and the same property are kept, and a view chooses among them. Wikidata’s “preferred” rank is not written in the ledger.
• Two times: time of fact when (EDTF + original text + calendar), time of record at.
• Scope: cannot go beyond the narrowest of its sources. The same fact from different sources is a different claim. Private relations of living people start sealed. Aggregate counts need five or more depositors. Candidates for introducing people are not kept.
• Identifiers are UUIDs, and the human-readable alias is the handle (arkive:p-kimtae). The same target is linked with a same_as claim and nothing is deleted. External IDs only as links.

Why

• The smallest shape that holds all three properties the head of Nodeone wanted (superposition, recording edges too, and learning from AI memory graphs and Palantir) is “one claim per line”. The factoid model, Wikidata and nanopublications all use this unit.
• If the ledger is the original, the same rules as 03-manifest (append-only, fingerprints, export) apply as they are.
• If “connection” had two meanings, “connection candidates are not kept” (September) and “all claims are kept” (this document) would read as if they contradict each other.
• UUIDs can be made on phones and across projects without asking each other. Putting people’s names in identifiers breaks down with alternate names and people who share a name.

Other options

Option	Why not chosen
Keep the name “06 Connection”	Its meaning overlaps with “connection” in the September specification
Store nodes and edges directly in a graph database	Editing erases old values, and they cannot be rebuilt. It goes against decision 0002
One property value per node (Palantir, ordinary databases)	Cannot hold superposition
A Wikidata-style “preferred” rank for each claim	What to put first differs for each viewer. Leave it to views
Only readable identifiers (p-kimtae)	They can collide between projects, and when a name changes the identifier lies. Kept as an alias (handle)
Export with RDF 1.2 triple terms	Still a W3C Candidate Recommendation (2026-04-07). The first version uses named graphs, which are a Recommendation

Where it has effect

• arkive: start the M4 relation network in this shape. Split alternate names and edge records into claims, and move verified_by: 판독 연구자(주석) (the transcription scholar (annotation)) from confirmation stamp to the person who supplied the source. Rename correction states according to the mapping table. 06-Relation network section 14, arkive to-do.
• secretary: nothing for now. A recording’s people (people who appear) can later be moved to person nodes and refers_to claims.
• Principles (00): not changed.

Cost

0 won. All are open standards, and Python and SQLite are enough to start (arkive PLAN section 12.6).