Edge ownership selects the key; choosing files or a database requires a workload comparison

Type: kb/types/note.md · Tags: architecture

When mutable state's identity or accepted transition belongs jointly to one instance of a many-to-many relation, neither endpoint is its unique logical owner. Its logical record must therefore be keyed by the complete edge identity: both endpoint identities and every discriminator that distinguishes one relation instance from another, such as relation kind, direction, or partition. This conclusion, developed from files deferring centralized schema commitment while database authority remains separate, selects an edge key, not a file or a database. Choosing where that record persists requires comparing concrete implementations against named workload requirements and the relevant costs of both.

Suppose the sole mutable payload for edge (a, b) is stored under a. Selecting it from b then requires a cross-endpoint scan or a separately maintained reverse index; storing it only under b produces the symmetric problem. If independently authoritative payload copies are instead stored under both endpoints, every transition requires coordinated writes and partial or concurrent updates can leave divergent copies. One edge-owned record removes this duplicate ownership of the payload, but it does not make selection from either endpoint free.

A complete file representation exists: an implementation can map each normalized complete edge key deterministically and collision-safely to one file, retaining the full key with the sole mutable payload when needed for checking. This is an existence witness, not a file-format proposal. Every logical edge then has one addressable record and neither endpoint is privileged, although selection by one endpoint may still scan the files or consult secondary indexes. When retained indexes are mechanically derived views, a derived copy of recomputable truth must be checked or absent; that rule does not turn irrecoverable accepted edge state into a derivation.

Moving the same complete-key record from a file to a database row changes its storage substrate and operational machinery, not its edge ownership. Substrate is separate from representational form, lineage, and behavioral authority. A database can therefore be a derived index over canonical edge files. It can hold canonical edge state only after the system makes an explicit authority decision and uses an operative write path to install accepted commitments that the files do not determine, since commitment rather than derivation creates new ground truth. Database placement alone decides neither lineage nor authority.

For a specified workload, database preference requires comparing concrete alternatives: an available edge-file implementation, including any scans, indexes, locks, journals, or service layer it would use, and a chosen database in its actual operating environment. A database is preferable only when it better meets named requirements—such as indexed partial-key selection, coordinated transitions, concurrent-writer or stale-work rejection, cross-record integrity, bounded latency, recovery, lifecycle operations, or fit with existing tooling—than the specified edge-file design after the relevant implementation and operating costs of both are considered. Many-to-many topology, churn, file count, or database availability alone does not settle that comparison; churn matters only through the requirement it stresses. The available evidence supplies no benchmark, fixed pair of alternatives, commensurable cost metric, or universal crossover threshold.

Commonplace is a bounded witness. Its current v1 freshness architecture identifies a review-pair target by target kind plus a complete target key, conceptually (note, criterion, model_partition). The subsystem needs indexed current-state selection, baseline-revision compare-and-swap for stale work, coordinated finalization and refresh transitions, cross-record integrity, and lifecycle operations. The original SQLite decision made SQLite canonical for review operational state and Markdown review artifacts derived. The general freshness-store decision extended that operational store to freshness baselines, inputs, and review evidence while retaining review-pair as the only v1 target. The storage architecture keeps authored notes and criteria canonical in files and generated indexes derived; freshness does not adjudicate truth. This case shows that explicit requirements and a separate authority decision can justify a database for an edge-keyed operational state class. It does not show that the complete key required SQLite, that all many-to-many state belongs in a database, or that Commonplace establishes a general threshold.