Table of contents
Record
Formal definition
A Record is a triple :
where:
- is the key — the identifier that distinguishes this record from all others in the same indexing scheme; must be unique within its context; the key provides the external face of the record — the address by which it is retrieved, cited, and cross-referenced
- is the value (the record’s content) — a structured assignment of values to named fields; in the simplest case, is a tuple where are field names and are their values; in richer cases, is a dependent record (fields whose types depend on prior fields) or a partial record (some fields may be absent or computed on access)
- is the history marker — the specific point in the history at which the record was committed; anchors to a definite moment; the record is accessible at all (it persists forward in history); it is not accessible at (it did not yet exist); the history marker is not just a timestamp — it is the commitment event that brought the record into existence
Three invariants. is a record iff:
-
Committed: the record has been written — not planned, not queued, not intended. The commitment is the act that creates the record. A fact that is known but not written is not a record. A plan to create a record is not a record. The record exists from onward; before , no record exists. This is what distinguishes a record from a belief or an intention.
-
Persistent: once committed at , the record persists at all subsequent histories . A record that can be unwritten (overwritten without trace, deleted without audit) is not a full record. Record systems designed for accountability maintain append-only logs: records can be annotated, superseded, or corrected by new records, but the original record persists. The immutability of records is the foundation of their evidentiary value.
-
Structured: is not raw data but structured content — a typed, field-organized value. The structure is what makes the record legible, retrievable, and composable with other records. A pure bit-string is data; a record is data plus structure. The structure makes the record interpretable by any agent that understands the schema.
Records in type theory: record types and record values
In dependent type theory and programming language theory, a record type is a named product type:
where each field has a type that may depend on the earlier fields’ values (dependent record). A record value is a term of a record type: a tuple where each .
The record type is the schema — the specification of what fields exist and what their types are. The record value is the instance — the specific assignment of values conforming to the schema.
Every spec file in this system is a record in this sense:
- Record type = the
spec/schema (the frontmatter template withid,description,defines,params,output,astfields and their types) - Record value = a specific spec file (e.g.,
group.mdwith its specific field assignments) - Key = the
id:field - Value = the full frontmatter plus markdown body
- History marker = the
date-created:field (the commitment event)
The defines: field is the record’s status function declaration: “the concept with key K counts as an entity in the relational system.” The record’s persistence property ensures that once group.md is written and committed, Group persists as a named entity at all subsequent histories.
Records in law: registration, certification, and evidentiary records
Legal systems maintain records because records are the mechanism by which institutional facts are made durable and enforceable. The key legal record types:
Public registers: land registries, company registers, ship registries, birth registers. These are authoritative records of institutional facts: “as of date , parcel P is owned by person Q.” The register entry is both a record (a committed fact) and a StatusFunctionDeclaration: ownership is constituted by the register entry, not merely reported by it (in register-based systems). The key innovation of registration systems: the institutional fact (ownership, personhood, incorporation) is anchored to a record that can be retrieved, verified, and relied upon.
Ship’s log: the master’s official record of all significant events during a voyage — courses steered, weather, personnel changes, cargo events, incidents. The ship’s log is the vessel’s History rendered as a linear record. In maritime law, the log is presumptive evidence of what occurred; discrepancies between the log and other evidence must be resolved in favor of the log absent clear proof of falsification. The log is the vessel’s memory.
Court records: the official transcript and record of proceedings — the pleadings, evidence, orders, and judgments of a case. Court records are both evidentiary (what happened in the proceeding) and constitutive (the judgment is the court’s finding; the record of the judgment is the institutional fact of the judgment’s existence). The res judicata doctrine (a matter once judged cannot be relitigated) is the legal doctrine of record persistence: once a matter is in the record, it constrains all subsequent proceedings.
The Public Record: in English law, “a matter of record” has a specific meaning — it is a fact established by an official court record that cannot be contradicted by other evidence. The record is conclusive. This is the strongest form of record persistence: not merely stored but irrefutable.
Records in databases: the row as the atomic unit
In relational database theory (Codd, 1970), a record (or row) is a tuple — one instance of a relation (a table). The table schema defines the record type (field names and types); each row is a record value.
The relational model:
- Relation = a set of tuples (records) all conforming to the same schema
- Key = a minimal set of fields that uniquely identifies a record within the relation
- Normalization = the process of removing redundancy from records to ensure that each fact is stored in exactly one place
Codd’s insight: a database is not merely a store of records but a store of facts — atomic, independent, compositional. The relational model is based on mathematical relations (set theory): a table is a relation in the mathematical sense; querying the database is computing new relations from old ones.
ACID properties (the guarantees of a transactional database system):
- Atomicity: a transaction either commits fully or not at all — no partial records
- Consistency: a committed transaction leaves the database in a valid state — records conform to their schema and constraints
- Isolation: concurrent transactions do not interfere — each transaction sees a consistent snapshot
- Durability: once committed, a record persists even through system failures — the committed fact survives crashes
The ACID properties are the database formulation of the record invariants: commitment (atomicity + durability), persistence (durability), and structure (consistency).
Immutability and audit logs: some systems maintain append-only logs where records are never modified — only new records are appended. The history of changes is preserved. This models the ideal record system: all records from all times are accessible. The history at time is exactly the set of records committed at or before .
Records in the history monoid: traces as records
In the relational hyperverse, a history (an element of the history monoid) is itself a record — the trace of all steps taken to reach the current state. The history is the key of the current state; the fiber is the value available given that history; the empty history is the beginning of the trace.
Every step that extends a history to is a record event: a committed act that extends the current trace. The history monoid is the record of all such extensions: it is the set of all possible traces, structured by the monoid operation of concatenation.
The restriction maps for prefix are the operations that allow reading earlier records from later histories: given that we are at , we can access the information available at the earlier history by restricting. The fiber is the “record as of history ” — the full information state committed by history .
Entity files as records in H_t: every entity file in a FARS locale is a record committed at some history and persisting through all subsequent histories. The entity file’s date-created: field is the history marker . The file’s content is the value . The file’s id: field is the key . The file is the physical implementation of the record triple .
Fixed fiber as the settled record set: is the sublattice of consisting of propositions that are both meaning-settled () and execution-settled (). These are the settled records — the facts that have passed through both nuclei and are fully institutionally established at history . An element of is present (in the fiber) but not yet settled (still being processed by the nuclei).
The record at the frontier: at the current history , the records in are the settled institutional facts. Records in are pending — present but not yet fully processed. Future steps will either settle them (moving them into ) or leave them pending.
Open questions
- Whether the ACID properties (atomicity, consistency, isolation, durability) have formal nuclear analogs — whether atomicity corresponds to the all-or-nothing character of reaching , consistency to the constraint that all records in are mutually consistent (no contradictions in the Heyting algebra), isolation to the fiber’s independence from other concurrent fibers, and durability to the persistence property of the fixed fiber across future histories.
- Whether there is a formal distinction between mutable records (records whose content can be updated in place, losing the old value) and immutable records (records that persist at their original value, with updates creating new records) — and whether this corresponds to the distinction between ordinary elements of (which may shift under nucleus application) and elements of (which are stable at their settled values).
- Whether the append-only log structure has a direct fiber analog — whether the full history is the “append-only log” and the fiber is the “current state derived from the log” — and whether this makes every relational universe an implicit append-only log system.
- Whether schema evolution (changing the record type while preserving existing records) corresponds to a morphism between fibers — a natural transformation that maps records under the old schema to records under the new schema, and whether this is always possible (all schemas are interoperable) or only when certain compatibility conditions hold.