Calculate once
Reuse eligible work instead of asking another model or service to rediscover the value.
Feature Store
Calculate once.
Reuse with
confidence.
Give agents, policies and people the same calculated business facts—with their meaning, freshness and evidence intact.
Carry the definition, entity, sources, unit, time and version with the value. Feature workflows can also turn recorded Frozion activity into reusable counts, totals and rates for the next decision.
Invoice INV-1042Tenant A · Supplier SUP-204
FROZIONExecution FabricGoverned from request to outcome
Variance from purchase orderDefinition v3 · percentage2.0%
Exposure including this invoiceDefinition v2 · USD$148,500
Prior matching invoicesDefinition v1 · trailing 90 days0
Snapshot FS-1042-ASource watermark 09:58 · checked 10:00
Agent contextExplain the factsPolicy evaluationApply the thresholdsHuman reviewInspect the evidence
Calculated facts for governed workReusable definitionsLess recomputationFreshness checksDecision-time evidence
The Feature Store across your adoption path
Govern existing agents
Use reusable calculated facts and activity history in a governed action or policy decision.
Grow tools into workflows
Share the same versioned facts across workflow steps, rules and human review.
Build native agents
Native agents use defined facts with source and freshness checks.
Build systems of engagement
Show application participants the same eligible facts that support the decision.
The problem this solves
One business number should not be reconstructed at every handoff.
When an agent, a policy and a review screen calculate the same measure independently, they can use different definitions, source revisions or time windows.
Share the meaning
Carry the entity, definition, window, unit and freshness with the fact.
Retain the consumed value
Connect the fact version used by agents, rules and reviewers to the case.
01 / Reusable business facts
One definition.
Many decisions.
Payment exposure. Change frequency. Rolling balances. Exception counts. These calculations often get rebuilt in queries, services, policy expressions and prompts.
The Feature Store gives each calculated fact a shared definition and an eligible value that consumers can reuse. A fact carries the information needed to understand it, check it and trace its use.
01 · Define
Make the meaning explicit.
Specify the entity, sources, formula, units, observation window and definition version. A shared name alone does not make two calculations equivalent.
02 · Calculate & retain
Keep the value with its evidence.
Materialize the result with source revisions, time, scope and semantic status. Reuse it while the definition, dependencies and freshness requirements remain satisfied.
03 · Use & inspect
See which fact each decision used.
Agents, rules, policies and reviewers can use the same eligible calculated fact. You can trace the value each execution consumed.
Independent calculations
Three consumers repeat the same work.
3 facts × 3 consumers = 9 calculations
Each consumer queries the sources and recreates the formulas. Definitions or observation times can drift apart.
A shared, eligible snapshot
Calculate three facts. Reuse their values.
3 calculations + 9 fact reads · 6 repeat calculations avoided
Agents and reviewers interpret the facts; policy evaluates them. They do not each recalculate the same inputs.
Work count for one snapshot, three facts and three consumers. Reads, authorization, freshness checks and policy evaluation still run. Refreshes add work; actual latency, token and cost savings depend on the application.
02 / Follow one invoice
Same invoice.
Same facts.
Every step of the review.
An invoice agent prepares the explanation. A policy evaluates the thresholds. An authorized reviewer inspects the evidence. All three use the same versioned facts.
Change the scenario below to see when reuse is valid, when a source change invalidates a calculation, and how a refresh gives every consumer a consistent new snapshot.
| Reusable fact | Value | Definition | Current use |
|---|---|---|---|
PO varianceinvoice.po_variance_pct | 2.0%$240 above the PO amount | v3 · percentage | Current |
Exposure including this invoicesupplier.exposure_with_invoice_usd | $148,500$136,260 open + $12,240 candidate | v2 · USD | Current |
Prior matching invoicesinvoice.prior_matches_90d | 0Complete 90-day history checked | v1 · count | Current |
PO variance v3: (invoice amount − PO amount) ÷ PO amount × 100. Both are USD amounts on the same tax basis; the PO must be positive. Fresh case: ($12,240 − $12,000) ÷ $12,000 × 100 = 2.0%.
Exposure v2: open unpaid USD balance for SUP-204 in Tenant A, excluding INV-1042, plus the candidate invoice amount exactly once. $136,260 + $12,240 = $148,500. Other currencies require their own declared conversion contract.
Prior matches v1: count other invoices with the same tenant, supplier and normalized invoice reference, observed within the trailing 90-day window. Excludes INV-1042 itself. A complete source window is required to establish zero; zero matches is not a guarantee against fraud.
Example policy: require current, authorized facts. Route to exception review if absolute PO variance exceeds 5%, exposure exceeds $150,000, or prior matches exceed zero. Otherwise route to standard AP review. An unavailable or stale required fact pauses evaluation. Every path still requires an authorized human decision before any payment action.
Freshness passed. Reuse this snapshot.
All required sources are 2 minutes old, within the 5-minute window. Invoice and PO revisions match. All three consumers can use FS-1042-A.
Shared decision snapshot FS-1042-AComputed 09:59 · decision check 10:00
Explain the invoice.
2.0% · $148,500 · 0 matches
Explain the $240 variance using established facts and source evidence. Additional authorized agents reuse these inputs.
Reads FS-1042-A · no recalculationApply the same thresholds.
2.0% · $148,500 · 0 matches
2.0% ≤ 5%; $148,500 ≤ $150,000; 0 matches. Route to standard AP review.
Reads FS-1042-A · no recalculationInspect the same evidence.
2.0% · $148,500 · 0 matches
Review the $12,240 invoice with the same fact versions, freshness result and source references.
Reads FS-1042-A · no recalculationThe review records this snapshot. A later refresh produces a new snapshot and preserves the facts used by the original decision.
Count recorded activity. Put it into the next rule.
Define feature workflows over governed activity as well as your systems of record. Policies, agents and reviewers consume the resulting measures with the same source, version and freshness semantics.
agent.refunds_count_1h
Recorded refunds by agent over an hour.
supplier.payments_total_7d
Payment total for a supplier over seven days.
user.customer_records_read_1h
Recorded customer-record reads by a user over an hour.
reviewer.approvals_count_15m
Recorded approvals by reviewer over fifteen minutes.
Feature workflows run on a schedule or when called through an API. You build the materialization and define how current a value must be for its next use.
03 / Freshness & point in time
Correct then.
Current enough now?
A fact can accurately explain a past decision while being too stale for a new action. Check source watermarks, observation time, calculation time and dependency revisions against the consumer's requirements.
Recomputing from an old source does not make the underlying information fresh. A changed source or incompatible definition can require recomputation even before a time window expires.
Effective time09:40
When the invoice amendment became effective.
Observed time09:58
When the source made the amendment available.
Computed time09:59
When these feature values were calculated.
Decision time10:00
When the review evaluated and consumed them.
See what was known at the time.
Inspect the exact values, definition versions, source revisions and freshness results used by the execution. Historical views distinguish when something happened from when the application could know it.
Suppose a correction is effective at 09:40 but first observed at 14:20. It cannot silently become an input to a reconstructed 10:03 decision.
A rerun with corrected data answers a counterfactual question. The original consumed snapshot remains the historical evidence.
Check what is needed now.
Use the freshness requirement of the current decision. A value suitable for prioritizing a queue may be too old to release a payment.
- Confirm tenant, entity, purpose and permitted use.
- Check source age and required observation coverage.
- Match definition versions and dependency revisions.
- Refresh, wait, route an exception or stop when required.
A human approval does not make stale data current. A later consequential action applies its own authorization and freshness checks.
Zero is a value.
Unknown is a different state.
Keep semantic status explicit. A failed duplicate check must never become “0 duplicates,” and an unauthorized fact must never become an empty value that passes a rule.
ZERO / FALSE
A valid result supported by the required observations.
UNKNOWN
The proposition cannot currently be established.
UNAVAILABLE
A required source or calculation path failed.
STALE
A value exists but fails the current freshness rule.
INSUFFICIENT HISTORY
The required observation window is incomplete.
NOT APPLICABLE
The proposition does not apply to this entity.
NOT AUTHORIZED
The active authority cannot derive or use the fact.
INVALID
Schema, unit, source or invariant validation failed.
04 / Governed reuse
A reusable fact.
An explicit contract.
Reuse the calculation without losing control of its meaning or use.
Keep the business proposition inspectable across online serving, historical materializations, policy and application screens. Version incompatible definitions explicitly.
Sharing a snapshot does not broaden access. Each consumer still needs the authority to use its contents for the declared purpose. Derived facts retain the applicable restrictions of their sources.
See how policy uses business facts- Meaning
- Proposition, formula, joins, units, observation window and definition version.
- Entity & scope
- Canonical entity, tenant, legal entity, taxonomy, purpose and inherited source restrictions.
- Time & status
- Effective, observed and computed time; source watermarks; freshness and missing-value semantics.
- Consumer
- Permitted consumers and decision roles, consequence, precision and validation requirements.
- Evidence
- Source records and revisions, exact consumed value, decision snapshot, corrections and downstream lineage.
Use calculated certainty
before additional inference.
A threshold on an established number does not require a model to rediscover the calculation. Feed the fact directly into deterministic logic and policy; use AI where interpretation adds value.
Bind the fact into context alongside operational records, retrieved documents and relationships. Give agents and human reviewers the same eligible evidence for the same decision.
Keep your operational systems
authoritative.
The ledger owns posted transactions. The supplier master owns supplier identity. The Feature Store owns a defined calculated proposition and the evidence of its use.
Existing batch pipelines, streaming systems, warehouses and feature infrastructure can remain. Connect their calculations through explicit definitions, source provenance and decision snapshots.
Inspect dependencies
before publication.
Bring feature definitions and consumer requirements into the application's publication checks: explicit versions and units, complete scope, freshness rules, missingness and decision evidence.
The exact checks depend on the declared feature contract, sources and application configuration.
Trace the fact
through the resulting action.
Follow source records into the calculated value, the consumed snapshot, the policy or reviewer decision, and the resulting business operation and effect evidence.
Link corrections to the original record. Keep historical reconstruction distinct from a new run using today's facts.
05 / Questions
From calculated value
to trusted input.
What to reuse, when to refresh, and what to preserve.
No. Reusable calculated facts can serve models and agents, deterministic rules, policies, routing, context packages, application screens and human review. The consumer contract defines where each fact is appropriate.
No. Define the calculation once, then reuse an eligible materialized value while its contract remains satisfied. Source changes, freshness expiry, corrected data or a new definition can require refresh or recomputation. Preserve the original consumed values when producing a new snapshot.
A query retrieves or calculates a result; a cache retains it for possible reuse. A governed decision feature also carries a declared business meaning, entity, units, time semantics, version, source dependencies and consumer requirements. It connects the exact value used to the decision that consumed it.
Different scopes, purposes or decision times can legitimately yield different eligible snapshots. For a single shared decision, bind authorized consumers to the same snapshot and explicit definition versions. If a required input changes, create a new snapshot and re-evaluate affected decisions instead of silently mixing old and new values.
Keep its status explicit and follow the configured workflow: refresh, wait for a source, route an exception or stop. A missing value must not silently become zero. A reviewer cannot grant data access they lack or make stale data current by approving it.
No. Existing source systems, calculation pipelines, warehouses and feature infrastructure can remain. Connect their results through declared definitions, scope, temporal semantics and provenance. The operational source remains authoritative for its underlying records.
Retain the exact feature snapshot originally consumed, and link the correction with its reason, source revisions and affected time range. Historical replay inspects what the execution used then; a new calculation with corrected data is a separate counterfactual or current evaluation.
Yes. Define calculations over recorded refunds, payments, reads, approvals or other governed activity. Feature workflows run on API or scheduled triggers; you control the entity, window, calculation, materialization and freshness requirements.
Start with one repeated calculation
Define the fact.
Reuse it across the work.
Bring an invoice, risk or operational review. We'll map the
calculated facts, freshness rules and decision evidence it needs.