rfc: add RFC 0044, derived edge identity via @key on edge types

[azimafroozeh]

What & why

Adds RFC 0044, "Edge keys: derived edge identity" (maintainer track, draft). This is the design for issue #583.

What it is: an edge key is declared identity for a relationship. @key(src, dst) on an edge type says there is at most one such edge between two endpoints, and the endpoint pair is its identity. Nodes already have exactly this (@key(name) means one Person row per name); edges don't, the parser refuses @key on them.

Why we need it: without declared identity every edge insert mints a random ULID id, and branch merge keys rows on id. When two branches insert the same relationship (Alice knows Bob, once per side of a fork), the merge sees two different ids and keeps both rows (#583). The duplicate is silent: edge counts and bound-edge traversals go wrong and no conflict is raised. Branch-and-merge is the core write workflow, so any graph with two writers hits this.

The proposal: for a keyed edge type the id is derived from the key instead of minted, using the canonical encoding keyed nodes already use. Both branches then derive the same id and the merge converges to one row; the same key with different non-key properties surfaces a typed divergent_insert conflict instead of silence. Unkeyed edge types are untouched: parallel edges stay legal and existing graphs are unaffected.

Diff: the RFC file plus its registry row, no code.

Backing issue / RFC

• Is an RFC PR: docs/rfcs/0044-edge-keys.md, discussion on accepted issue bug: merge duplicates an edge added on both sides of the fork, and plain traversal hides the extra row #583

Checklist

• Change is focused (one RFC and its registry row)
• Tests added/updated for behavior changes (N/A: docs only; the RFC's Evidence section names the test owners the implementation extends)
• Public docs updated if user-facing surface changed (N/A here: the user-doc updates ride the implementation PR per the RFC's rollout plan)
• Reviewed against docs/dev/invariants.md (the RFC's Invariants section maps the design onto invariants 6, 8, and 13 and argues the deny-list explicitly)

Local verification

• python3 scripts/check-docs.py: OK, 114 files (frontmatter, registry row, and links validate)
• cargo test: not run, docs-only diff

Notes for reviewers

• The ir_version question from review is settled for this RFC: the edge-key number is 3, fixed at acceptance, not at implementation time (Design change 6, Compatibility). The cross-feature scheme raised on rfc: add RFC 0040, the system column namespace #546 (independent features against one linear scalar) is deliberately out of scope here and deferred to a dedicated versioning RFC (tracked by RFC 0040's unresolved question 1).
• The registry's next available number advances to 0045.
• Frontmatter says implementation: in-progress: the full implementation (engine changes, tests, DST updates, user docs) is open as feat(engine): add edge keys with derived identity #593; bug: merge duplicates an edge added on both sides of the fork, and plain traversal hides the extra row #583 is closed there, not by this PR.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[ragnorc]

Small fixes:

1. Title/body still say "RFC 0043" — that number is taken on main by full-text compatibility; the diff itself is already correctly 0044-edge-keys.md. Retitle and fix the stale "next available advances to 0044" line in the body (the diff says 0045).
2. The shared ir_version scalar with rfc: add RFC 0040, the system column namespace #546/feat(schema): resolve system column spellings per graph #548 deserves settling at acceptance rather than implementation — see the comment on rfc: add RFC 0040, the system column namespace #546 for the combination case a linear version can't express.
3. Rebase race with docs(rfc): add RFC 0043, GQ logic tests #584 on the registry's next-available line — whoever lands second rebases.