Reification
"To regard something abstract as if it were a concrete material thing."
Reification turns an action or concept into an entity that the system can examine. A committed patch can affect fields on one or more entities, and the commit itself becomes a transaction entity. Its id comes from the same sequence as every other entity id, and Stardust records its UTC commit time.
Every fact records the transaction that asserted or retracted it.
The transaction file under data/transactions/<id-path> contains the full reified patch in JSON or DUST.
Its top-level keys are decimal entity IDs. Each value contains changed fields, with null for retractions.
Unchanged fields are absent.
The transaction entity appears under its own ID with stardust/committedAt and stardust/transaction.
Definition and object changes include their structural facts. The patch has no named-path aliases or wrapper objects.
163 {role engineer
retired null}
164 {name Ada}
165 {stardust/committedAt {#utc 2024-01-02T03:04:05Z}
stardust/transaction true}
The transaction is part of the data rather than an audit record beside it. A query fact pattern can bind the transaction as a fourth term:
where [[?e role ?v ?tx]]
A query can also read the whole store as of an earlier transaction. Stored system definitions follow the same principle, so each revision of a definition is a commit in the same history. This level of detail is unusual because most systems discard much of this knowledge or keep it in other systems.
Knowledge across the stack
Most systems separate business data from the code, configuration, and operational records that give it meaning. Knowledge about one application then exists across databases, source repositories, deployment tools, and audit systems. Stardust keeps more of the durable development stack and business model in one store. Queries, mutations, schemas, expressions, macros, and backup targets are entities that hold documents under definitions/. Stardust includes only knowledge that a project places under its management, not activity that happens in unknown external systems. Within that boundary, one historical view can describe both the development stack and the business.
When system definitions and business facts share one store, their changes share one ordered transaction log. A project can see which definition revision was committed before or after a business fact changed. A mutation with live true reacts to matching commits. Its definition and the changes it produces share one history. Queries and Mutations describe live definitions in detail. These relationships provide insight without a separate audit model for each subsystem.
More application truth
Stardust can be the source of truth for more application knowledge. Applications can focus on temporary interaction or specialized processing instead of owning another durable model. For example, Stardust can keep uploaded video data as a content-addressed object. It can keep the metadata as entity fields and a JSON Edit Decision List as a document. Another process can perform video conversion or graphics processing unit (GPU) work. Binaries explains how large payloads remain connected to this knowledge.
Power requires boundaries
When data controls behavior, a data change can also change how the system operates. Behavior definitions therefore need strict validation and controlled write boundaries before they become durable. Stardust rejects an invalid Draft-7 JSON Schema when it is written. It also rejects a mutation whose query or patch does not compile. Immutable history makes each accepted revision visible, but history does not make an incorrect definition safe. Code explains how executable data stays bounded.
Business data and reified system definitions need names that survive implementation changes. Stardust gives each field name a stable identity without requiring a complete model first.