Fields#

Reification makes system behavior and business concepts available as data, but that data still needs stable meaning. Many systems require a complete model before they accept a new property. An open ontology lets useful knowledge arrive before that model is complete. Fields supply the durable names that make this openness practical.

Closed and open ontologies#

An ontology identifies the concepts and relationships that a system can represent. A traditional struct starts closed because only declared members are valid. An empty Go struct permits no named data members:

type Device struct{}

Adding temperature requires a new declaration before the struct can contain that value. The application must then compile and deploy the changed definition. This approach gives strong agreement when the model is stable, but it delays facts that arrive first.

An empty JSON Schema Draft-07 schema has the opposite default:

{}

This schema accepts every JSON instance. That open default removes the requirement for a complete class model. A project can record a new field immediately, then add a schema where validation is necessary. Openness becomes the starting point rather than an exception to the model.

Entities are fact bundles#

An entity in Stardust is a bundle of facts under one id. Each fact joins one entity, one field, and one value at one transaction. A document such as data/entities/0000/0000/001/63.dust is a readable view of that bundle, where each top-level member names a field.

name   Ada
active true
count  42

No declaration precedes these fields. The first commit that uses a field name allocates its identity in the same transaction as the facts that use it. New concepts can therefore appear without a migration or prior declaration.

Strings at the boundary#

JSON object member names are strings, so Stardust keeps string names as its public contract. This choice works across programming languages, the JSON and DUST projections, and ordinary JSON tooling. Internally, Stardust records each name in a field dictionary that maps it to a compact numeric identity for indexing and comparison. Clients do not need to know or preserve that identity.

The dictionary is append-only. A commit that would remap an existing name or identity is rejected, so a name keeps the same identity for the life of the store.

Names keep their meaning#

One exact name identifies the same field across the full store, so historical data does not appear to change meaning later. When meaning changes, a project should introduce a new field instead of reusing the old one. Projects can use namespaced fields when the same short word has different meanings in different domains. Frequent namespacing can show that one store spans domains that need separate authority. In that case, separate Stardust instances are usually clearer than one large namespace because each instance is small and flexible.

Stardust reserves one namespace for itself. Top-level names that start with stardust/ are structural fields, such as a definition's type, path name and parent. A data entity has none of them: its document is exactly its authored fields, and a document write that supplies any stardust/ member is rejected.

Openness has a cost#

A flexible system can accept a field with a spelling error or two names for the same concept. One field can also hold values of different types when no schema restricts it. Schemas add agreement where necessary. A query can select entities that validate against a schema. A schema-checked patch rejects changes that do not conform. Other data remains outside those selected rules.

A field explains what a value means, but it does not decide what kind of value can carry that meaning. Strings, numbers, references, times, and custom values need different representations without closing the ontology. The shared value model records the type of each value.