Change logs, additive columns, calm releases.

Releases are change-logged and additive - old fields keep working - so a model does not go haywire because a supplier shipped.

The fastest way for a data supplier to lose a lender is to break its schema without warning. A column that changes meaning, a field that disappears, a type that shifts - each one is a model that starts producing nonsense at production scale, and a Monday morning your risk team spends explaining why.

Additive by default

Our releases are additive. New fields arrive as new columns. Existing fields keep their names, their types and their meaning. A model built on last quarter’s schema keeps running on this quarter’s release, because nothing it depended on moved underneath it.

Old fields keep working. Your models do not go haywire because we shipped.

Change-logged, so nothing is a surprise

Every release carries a change log. What was added, what was improved, what a field now covers that it did not before. Your second line reads the log, not the tea leaves. No surprises is the order of the day - a release should be something you can plan around, not something you discover in production.

Refresh, stated per field

The product release cadence is monthly. The refresh period of an individual field is a property of that field, not a blanket promise, and each field page renders its period from the dictionary. A monthly product release does not establish a monthly flat-file refresh or a monthly AVM testing cadence.

// on every field page
Refresh: {refresh}   // rendered from the dictionary, never hard-coded

That precision is not pedantry. A lender that is told everything refreshes monthly, and then builds a rule expecting it, has been set up to fail on the fields that do not. We would rather state the real period per field and let you plan against the truth.