Schema Evolution
Changing the shape of a dataset over time without breaking the systems already reading it.
Schema evolution is how a dataset changes shape - a new field, a renamed one, a type widened - while consumers keep working. The distinction that governs it is compatibility direction: a backward-compatible change lets existing readers handle new data, and a forward-compatible one lets older data still be read. Adding an optional field is usually safe; removing a field, renaming it, or narrowing a type breaks somebody, and usually silently.
For a provider this is a contract obligation rather than an internal concern, because every client integration is coupled to the shape. The practices that keep it manageable are versioning the interface, treating field removal as a deprecation with a stated horizon, and never repurposing an existing field's meaning - a field whose semantics changed while its name stayed is the hardest kind of failure to notice, since nothing errors and every number quietly shifts. It sits next to data normalization as the work that keeps a dataset coherent as its sources change.
Real-time data, at edge speed.
A live evaluation measures EdgeOrigin against your coverage requirements: decision-ready real-time data, delivery latency into your systems, and record-level provenance.