Feature Store

A number becomes a decision fact only when the application knows what it means.

Define calculated business facts once and use them across models, rules, policy, Context Assembly, human review, routing, and workflows with definition, entity, source, time, scope, freshness, and provenance intact.

Payment Exposure value, definition, source watermark, decision time
Account Change Frequency entity, window, freshness, scope
Corrections do not rewrite past decisions.
Reusable facts

Turn calculations into reusable business facts

Declared proposition

Payment exposure, change frequency, account age, exception count, and risk indicators remain typed business facts.

Definition contract

Formula, window, unit, entity, source dependencies, missingness, scope, consumers, freshness, and provenance stay attached.

Reusable consumers

Models, deterministic rules, policy, routing, human review, Context Assembly, and UI use the same meaning.

Point-in-time semantics

Preserve four different meanings of time

Point-in-time correctness is more than asking for the latest value before a timestamp. The application must distinguish what was true from what could be known.

Effective time: when the fact became true
Observed time: when the source could know it
Computed time: when the feature was calculated
Decision time: when execution consumed it
Execution evidence

Record the exact features the execution actually used

A Decision-Time Feature Snapshot retains the precise Feature Value Records consumed by one Execution Instance.

Feature identityDefinition versionEntityValue statusSource watermarkFreshnessConsumerLineage
Freshness and status

Keep point-in-time correctness separate from freshness

ZERO / FALSE
UNKNOWN
UNAVAILABLE
STALE
INSUFFICIENT_HISTORY
NOT_APPLICABLE
NOT_AUTHORIZED
INVALID
Scope inheritance

Preserve scope through the calculation

Derived values can inherit tenant, taxonomy, legal entity, purpose, classification, residency, and permission revision from eligible sources.

Parity

Keep online and historical features semantically aligned

A Feature Parity Contract can specify equivalence and allowed divergence across online, offline, batch, and streaming representations.

Corrections

Preserve late data and corrections without rewriting history

A Feature Correction Record connects original values to corrected values while preserving what the application actually knew at decision time.

Original valueLate eventCorrected valueReplay implication

Map one calculated decision fact from source to business effect.

Use an architecture review to define feature contracts, time semantics, freshness gates, parity, corrections, and Feature-to-Decision Lineage.