Velocity hides in separate cases
Each refund is below the amount threshold. The system still needs to know how many refunds this agent has recently initiated.
Benefit / Trust & Control
Policies
that remember.
One refund can be ordinary. Eleven refunds in an hour may need a different decision. Frozion brings recent activity into policy evaluation, so the next request is judged in the context of the work that came before it.
Track the activity. Reuse the fact. Apply the rule with history in view.
FROZIONExecution FabricGoverned from request to outcome
- Recent activity
The case reads 10 committed refunds for this agent in the defined window.
- The next request
A new $180 refund reaches the governed action boundary.
- The policy response
The configured velocity rule holds this request for review.
Sample sequential decision · historical aggregates are not atomic reservations.
01 / The challenge
Every request looks reasonable.
The pattern does not.
A rule that sees only the current action misses the relationship between actions. Repeated requests, shared identities and activity across agents can change the meaning of an otherwise ordinary transaction.
Small amounts add up
Two payments can each sit below a review threshold while their combined amount crosses it. A per-request check cannot answer the cumulative question.
Activity follows an identity
A person can use several agents to access records. Counting separately by agent misses the combined activity associated with that user.
02 / How it works
History becomes
a reusable decision input.
Configure the activity to record and the fact to calculate. Policies, agents and reviewers can then use the same defined value rather than reconstructing a different history for every decision.
Define the activity and its key
Identify the recorded events and the entity they belong to: an agent, user, supplier or other business key. A count across agents needs a shared identity key, not separate per-agent totals.
Define the window and calculation
Specify the period, aggregation and source relationships. A one-hour count and a 30-day supplier total are different facts with different meanings.
Materialize and reuse the fact
The Feature Store makes the calculated value available with its definition version, entity scope and freshness. Consumers can check whether it meets their decision contract.
Evaluate the next request
Apply an explicit policy to the available historical fact and current proposal. The result can require review, deny the action or follow another configured path, with the inputs recorded.
03 / In practice
Four patterns.
Four better-informed decisions.
These sample rules use recorded activity to change the treatment of a new request. Each fact has a defined subject and time window.
History-aware policy examples · sample data
Choose a pattern to inspect its recorded fact, current request and policy response.
Agent / 1 hour
The next refund needs review.
Ten refunds are already committed to this agent’s one-hour activity fact. In this sequential example, the next $180 request reads that value and triggers the configured review rule before the refund action.
Rule inputs
- Subject
- Agent refund-agent-7
- History
- 10 committed refunds / 1 hour
- Current proposal
- $180 refund
- Rule
- Review when prior count is at least 10
- Response
- Hold current request for review
Supplier / 30 days
The second payment crosses the threshold.
A new supplier has one recorded $4,900 payment. A second $4,900 proposal brings the projected total to $9,800, above the $5,000 review threshold. Supplier age comes from the vendor master; payment history comes from recorded activity.
Rule inputs
- Supplier age
- 12 days · vendor-master source
- Prior payments
- $4,900 / 30 days
- Current proposal
- $4,900
- Projected total
- $9,800
- Response
- Hold the second payment for review
User / 1 hour
See the activity across agents.
A shared user key connects recorded access through multiple governed agents. The next request is evaluated against that user’s combined activity, so changing agents does not reset the fact used by the policy.
Rule inputs
- Subject
- User across governed agents
- Recorded activity
- 200 records / 1 hour
- Current request
- Access 25 additional records
- Policy
- Review projected access above 200
- Response
- Hold request for the configured review
Reviewer / 12 minutes
A review pattern deserves attention.
Thirty-one recorded approvals in twelve minutes trigger an additional-review rule for the next qualifying case. The pattern is a signal to examine, not proof of careless or improper judgment. Business context still matters.
Rule inputs
- Subject
- Eligible reviewer identity
- Recorded activity
- 31 approvals / 12 minutes
- Policy response
- Additional reviewer required
- Interpretation
- Attention signal · not a misconduct finding
- Evidence
- Recorded decisions linked to the cases
04 / Shared history
The value is in
a shared definition of the past.
A count is easy to describe. A reusable policy fact also needs a reliable meaning: whose activity, which events, which window and how current the result is.
- One definition
- Use the same versioned calculation across agents, policies and human review, instead of embedding a different query in each consumer.
- Visible freshness
- Check whether the available fact is fresh enough for this decision. Missing or stale inputs follow the configured refresh or exception path.
- Connected provenance
- Retain the relationship between the value, its definition and source activity so a reviewer can understand why the rule matched.
- Explicit decision semantics
- Distinguish the previously committed total from a projected total that adds the current request. Define both clearly in the policy.
05 / By role
Recognize patterns
before the next action.
History-aware rules connect operational context to the people responsible for defining and reviewing the boundary.
Risk & compliance
Express controls that use recent behavior as well as the current amount. Review the fact definition, window and policy response together.
Policy with relevant context.Operations leaders
Identify bursts, repeated exceptions and review patterns. Route attention to cases that deserve another look.
Fewer isolated decisions.Application teams
Reuse activity facts across consumers with explicit keys, versions and freshness. Avoid rebuilding the same historical query in each workflow.
A shared calculation to maintain.06 / Scope and questions
History informs the rule.
Transaction controls enforce hard caps.
Keep the distinction clear when designing financial, access or usage controls. A historical fact improves the next decision but does not reserve capacity for it.
Coverage follows recorded activity
Facts reflect the events integrated into their source. External actions and missing events cannot be inferred from an incomplete history.
Committed values are not reservations
Two concurrent decisions can observe the same prior total. Use an appropriate transactional check or reservation where the business requires a limit that cannot be exceeded.
Not from a historical aggregate alone. Concurrent decisions can read the same committed value before updates arrive. A strict cap needs a suitable transactional control or reservation at the action boundary.
Yes. The split-payment example combines payment activity with supplier age from the vendor master. Each input retains its source, meaning and freshness requirements.
The decision’s contract determines whether to refresh the calculation, wait or follow an exception path. Reusing a value does not remove the need to check its freshness.
No. It can trigger a review or another configured control. The signal, the business context and the underlying evidence must be evaluated before drawing a conclusion.
Start with one business process
Bring the pattern
your current rules miss.
We’ll define the activity, subject and time window, then connect that fact to the next governed decision and its review path.