Fields
The team handling invoices starts recording why customers dispute them. The original invoice model has no field for that information. Requiring a revised record structure makes collecting the reason depend on changing the model first. The team already has useful information, even while it is learning which distinctions matter.
An open ontology allows new concepts and relationships without declaring every record structure in advance. In Stardust, an entity has an identity and a collection of facts. Fields name the facts associated with that entity. An invoice can acquire a reason field without requiring every other invoice to have one.
The application can add the field when it records a reason, leaving other invoices as they are. A query can find invoices with a reason or identify those that lack one. A later requirement can ask for a reason while earlier invoices remain available with the information actually recorded.
Names
Fields usually take natural names such as name, date, and reason. An invoice and a refund can both have a reason, with other facts establishing the context. A query selects the entities relevant to its work through their tags and the conditions they satisfy. The field name does not need a prefix identifying every kind of entity that might use it.
Tags describe roles or characteristics an entity has. An entity can have several tags, allowing different operations to select it for different purposes. For example, a query can require an invoice tag together with a dispute condition and a recorded reason. The meaning needed for that operation comes from the combination of facts it selects.
Existential processing
The Existential Processing chapter of Data-Oriented Design describes organizing work around data that meets the conditions for processing. Selecting the relevant data first reduces the checks that processing code must repeat for every object. Membership in the selected data expresses which work applies. This connects the shape of the data to the behavior that operates on it.
In Stardust, queries can express that selection through combinations of facts and predicates. A dispute investigation might select entities tagged as invoices where disputed is true and reason exists. Adding a condition that resolved is false narrows the selection to unresolved disputes. The application receives the matching data with those conditions already established, rather than inspecting each invoice to decide whether to process it.
Boolean values are useful facts in this model. A predicate can test a boolean value, while an existence condition tests whether a fact is present. A missing resolved field and a resolved value of false are different conditions. The query expresses which one the operation requires.
Schemas
An open model can also accept misspelled names and inconsistent values unless an operation applies constraints. The team may accept a free-form reason during an investigation, while requiring specific information before approving an invoice for payment. Those uses need different requirements for the same invoice. Schemas express the requirements selected by each operation without making one fixed shape mandatory for every entity.