Readable rules
Make nested business conditions inspectable across engineering, risk and compliance.
Visual Policy Builder &
runtime enforcement
Define the rule.
Govern the action.
Visually compose deeply nested policies for who may act, on which resource, and under which business conditions.
Compliance, risk and engineering read the same nested rule, see which facts it checks and see where it is enforced. Each evaluation records the conditions and inputs behind its decision.
Caller authority + tenant + supplier scopeCheck first
FROZIONExecution FabricGoverned from request to outcome
ANYOne risk condition is sufficient
Bank changes / 30 days≥ 2
ALLBoth conditions must match
Verification passedfalse
ANYExposure or supplier history
Payment exposure≥ $100k
Supplier age< 30 days
WHEN THE RULE MATCHESRequire finance review + FIDO2The protected update waits for the obligations to be
satisfied.
One policy connects the rule, the required work and its
evidence
Nested visual conditionsRBAC & attribute scopeFeature Store factsHITL & FIDO2Inline enforcementDecision lineage
Visual Policy Builder across your adoption path
Govern existing agents
Apply explicit conditions before a protected operation your existing agent requests.
Grow tools into workflows
Evaluate the relevant rule and review obligations at governed workflow steps.
Build native agents
Native agents use the same policies and permitted business facts.
Build systems of engagement
Apply policy to protected reads and actions in the application’s process.
The problem this solves
A business rule needs a visible enforcement point.
When conditions are spread across services or prompt instructions, teams have to reconstruct which rule applied and whether it actually controlled the action.
Controls in the path
Connect a policy requirement to the protected operation that must wait for it.
An explainable decision
Retain the rule version, facts and obligation status with the execution.
From policy decision to governed execution
Make the policy result
part of the work.
A rule that requires review needs an execution path that actually waits for it.
Frozion connects the decision to its obligations, the enforcement point and the resulting evidence. The workflow can pause, present the exact proposal to an authorized reviewer, require stronger assurance and recheck the next protected action.
Use these controls in workflows called by existing agents or in native Frozion applications. Your agent can keep its current framework while the governed process applies the policy.
01 / DECIDE
What does the rule require?
Evaluate the action against its facts and authority.
02 / REQUIRE
What work must happen?
Create explicit evidence, approval or assurance obligations.
03 / ENFORCE
Where must it be satisfied?
Check the obligations at the configured protected boundary.
04 / EXPLAIN
What actually happened?
Connect the decision, controls, attempts and reported result.
Enforcement applies to integrated paths and configured boundaries. Define and review that scope, including fallback and retry paths.
01 / Compose policies visually
Express the business rule.
Keep the logic inspectable.
Combine conditions with nested ALL and ANY groups. Keep the relationship between a condition, its business fact and the resulting decision visible—even when the rule spans several levels.
Separate the scope of the policy from the conditions it evaluates. Make the target resource, operation, permitted actors and required outcomes explicit.
FOLLOW THE CONDITIONS TO THE DECISION
One rule. Different business facts.
Authority & scopeSatisfied for this operation
Fact contract & freshnessRequired values valid and current
ESCALATE IF THE RISK RULE MATCHESPolicy v4
ANYAt least one branch must matchMatched
bankChanges30dis greater than or equal to 2
ALLBoth conditions must matchNot matched
verificationPassedis equal to false
ANYOne contextual condition must matchNot matched
paymentExposureUsdis greater than or equal to 100,000
supplierAgeDaysis less than 30
OtherwisePermit continuation under the applicable policy and
authority checks.
RBAC, attributes and resource scope
A role is part of the decision.
So is the resource.
Evaluate the subject and workload together with tenant, delegated authority, resource, taxonomy, action, purpose, proposal and current state. An approver role does not grant authority over every supplier or every operation.
Keep the policy's intended scope visible during authoring and historical inspection. Establish which application paths use it and where the protected operation is enforced.
Explore identity and authorization
WHEN MORE THAN ONE POLICY APPLIES
Understand how multiple rules shape one decision.
- Precedence
- Which rule has priority for this operation?
- Conflicts
- What happens when applicable decisions disagree?
- Exceptions
- Which authority may define or use an exception?
- Obligations
- Which checks and approvals still remain mandatory?
Define and review these semantics explicitly; do not infer them from the visual order of unrelated rules.
02 / Policy grounded in business facts
Give the rule facts
with a known meaning.
Use the proposed action, operational records and calculated facts together. The integrated Feature Store makes reusable business measures available to policy, workflow routing, AI context and human review.
Inspect the definition, source, scope, time, freshness and provenance of the fact used in the decision.
Integrated Feature Store
Evaluate the business situation,
not only the immediate
request.
A supplier-change request can be evaluated against recent change frequency, exposure or verification history. The same calculated fact can inform the policy condition and the reviewer's explanation.
A count of two only becomes useful when its entity, window and calculation are clear. Preserve what the value represented at decision time, including the version of its definition.
Explore the Feature Storesupplier.bank_changes_30d
2 recorded changes
- Entity & scope
- SUP-204 · Tenant A · permitted supplier
- Definition
- Count of changes in the rolling 30-day window · v3
- Source
- Eligible supplier account-change history
- Freshness
- Checked against this decision's requirement
- Lineage
- Source records → calculation → policy evaluation
STRICT CONTRACTS
Validate the value the rule receives.
Use declared types, required values and explicit mappings. A string, a missing value and the number zero are different inputs. A schema failure must not silently become a business fact.
Explore orchestration schema contracts
CURRENT ENOUGH TO DECIDE
See when a required fact is missing or stale.
Define what happens when a required fact is absent or outside its freshness window: refresh, collect evidence, wait, route an authorized exception or stop. In the example above, risk evaluation waits for the required fact.
Explore governed context
SPECIALIST BUSINESS CHECKS
Extend the calculation with a clear contract.
Bring a supported industry calculation, proprietary rule or external verification into the workflow with defined inputs, authority and recorded results. Keep its result understandable to the policy.
Explore developer extensibilityUse activity history in the next decision.
Define features over recorded activity: refunds by an agent in an hour, payments to a supplier in seven days or records read by a user. Policies can hold, deny or request review based on the recorded count, total or rate and its freshness.
agent.refunds_count_1h ≥ 10 → hold for reviewMaterialization is defined by your feature workflow. Concurrent decisions can read the same committed value; a historical feature does not reserve capacity.
03 / Enforce & escalate
Put the control
before the consequence.
Evaluate policy at the configured data, capability and action boundaries. Connect the decision to the actual operation and verify that its mandatory work has been completed before that operation proceeds.
Prompts can guide model behavior. Protected data access and business actions need independent runtime authorization and enforcement.
DATA & CONTEXT
What may inform the decision?
Apply eligibility to records, documents, fields and facts entering context.
MODELS & CAPABILITIES
What may this workload use?
Evaluate eligible tools, models, providers and deployment routes.
TOOL CALLS & ACTIONS
May this operation proceed?
Check the active actor, purpose, resource, proposal and current state.
HUMAN REVIEW
Who may decide?
Scope reviewer authority, visible evidence and required assurance.
OUTPUT & PERSISTENCE
What may leave or be stored?
Apply supported disclosure, redaction, release and retention controls.
BUSINESS WRITE
Are the conditions still valid?
Recheck authority, policy, approval and the exact action before the protected write.
Integrated HITL + FIDO2
Turn “requires review”
into a governed human decision.
The ready-made HITL Inbox presents the exact proposal, eligible facts and policy to an assigned internal reviewer. Require FIDO2 where policy calls for it and bind the decision to the revision reviewed.
CASE-041 · PROPOSAL REVISION 2
Required does not mean completed.
01
Finance reviewAssigned to an authorized reviewer · pending
Waiting
02
FIDO2 assuranceRequired for this approval · not recorded
Pending
03
Explore durable human decisions
Protected updateRevalidate after obligations are satisfied
Not attemptedPolicy shapes the next step
Express the outcome
the operation needs.
Permit and deny are only part of the model. A decision can also require work or constrain how an operation proceeds.
Use the outcomes supported by the intended integration. Configure the enforcement path for each obligation; unsupported transformations or routes must not be treated as completed controls.
Permit or denyContinue under the applicable conditions, or stop the
requested protected path.
Require evidenceCollect or refresh specified facts before
proceeding.
Require human reviewObtain the appropriate decision for the exact
proposal.
Require stronger assuranceComplete policy-required step-up authentication.
Transform or redactApply the approved supported transformation before
release.
Reroute or limitChoose an eligible supported route or apply explicit
constraints.
Re-evaluateCheck current conditions at the next relevant
boundary.
Durability includes the decision's validity
When the work waits, the world can change.
Resume with the proposal, authority, relevant facts and approval conditions required for the next step. Re-evaluate after changed business state, a new actor, expired authority, a revised proposal or a completed wait when the configured process requires it.
See policy in the execution graph04 / Test & inspect
Review the rule before release.
Explain its decisions afterward.
Evaluate policy changes against expected business cases and the execution paths they govern. Retain the version associated with each recorded decision.
Inspect the facts, conditions, outcome, obligations and enforcement result in the context of the operation—under the viewer's own permissions.
Build a useful policy review set.
Use supported test facilities and execution evidence to review these cases. This checklist does not imply automatic proof of every possible path.
Expected permit & denyRoutine authorized work and explicitly prohibited
operations.
Thresholds & nested branchesValues just below, at and above a threshold; each relevant
ALL/ANY combination.
Invalid, missing & stale factsWrong types, unavailable required inputs and expired
decision context.
Scope & policy conflictsWrong tenant or resource, conflicting rules and permitted
exceptions.
Incomplete obligationsMissing review, insufficient assurance and an approval for
another proposal.
Waits, fallbacks & retriesChanged authority or business state and configured routes
around a protected action.
Version changesExpected differences from the previous policy and the
effect on new decisions.
Policy decision evidence
See the outcome.
Trace the decision.
Understand why an action proceeded, was blocked or is waiting for approval. Inspect the policy version, business facts and authority checks behind the decision, then follow the human review and enforcement checks through to the reported outcome.
Review the evidence your role permits, with source permissions and disclosure controls respected.
Explore Behavior Intelligence and replayWhy is CASE-041 waiting?
- Policy
- Supplier change controls · v4
- Fact used
- 2 changes / 30 days · definition v3
- Matched condition
- bankChanges30d ≥ 2
- Required work
- Authorized finance review + FIDO2
- Enforcement state
- Protected update held pending obligations
- Business outcome
- No account update attempted yet
Version policy with the work it governs
Keep yesterday's decision
explainable tomorrow.
Trace each recorded decision to the policy version, proposal, facts and application execution that informed it—even after definitions change.
Before delayed consequential work continues, check the current authority and approval conditions required by its execution path. Historical traceability and current authorization answer different questions.
Test the change against recorded cases.
Use batch simulation to compare a proposed workflow or policy change against recorded business cases without authorizing live side effects. Inspect the workflows that use a policy; compare the workflow versions and review changed outcomes before publishing.
Work with your existing governance architecture
Connect the control
to the application.
Frozion’s policy engine evaluates and enforces policy at protected steps in its execution path. Connect enterprise SSO or use Frozion’s built-in FIDO2 identity; your GRC processes and downstream security keep their responsibilities.
Frozion connects policy to the application context and the workflow that applies it. Define the integration boundaries and connect its evidence to the operational and audit systems your teams use.
The integrated value is the path from rule to fact, decision, required work, enforcement and reported outcome—available to existing agents and native applications alike.
Visual OrchestrationPlace decisions and obligations on an inspectable
execution path.↗AI Data PlaneSupply eligible records, calculated facts, context and
lineage.↗App BuilderGive reviewers the proposal, evidence and permitted
controls.↗Identity & SecurityCarry tenant, role, purpose, delegation and assurance
into the decision.↗
Before you define the policy
Questions teams ask.
Yes. Existing agents can invoke Frozion-governed workflows
and operations through supported integrations. Policy
applies at the configured enforcement points along those
paths. A connected agent's unrelated activity outside
those paths is not automatically governed.
Yes. Compose nested condition groups using the policy's
supported operators and typed facts. The example shows an
ANY group containing an ALL group with another ANY group
inside it. The definition and condition results remain
inspectable so reviewers can understand how the rule
reached its outcome.
A role contributes to authority, while tenant, resource
scope, attributes, purpose, proposal and current state
establish the relevant conditions for the operation.
Passing a risk rule does not grant missing permissions.
The policy checks scope before evaluating the
business-risk conditions.
The decision creates obligations for the configured
workflow. The protected operation waits while an
authorized reviewer considers the exact proposal and
completes the required assurance. The execution records
the response and checks the conditions for continuation.
Simply returning “review required” is not the same as
enforcing or completing that review.
Define missingness, types and freshness explicitly. A
missing count is not the number zero, and an old fact may
not satisfy the current decision's requirement. Configure
the appropriate refresh, evidence, review or stop path. In
this page's example, missing or stale required facts hold
the operation before risk evaluation.
It is one part. Governance by Design describes
identity, authorization, policy, schema contracts,
approvals, durable state and evidence participating in the
application definition and runtime. The visual rule, its
enforcement path and its evidence must work together.
No. Use enterprise SSO or Frozion’s built-in identity with FIDO2. Frozion evaluates policy in the governed execution path while your identity provider, GRC processes and downstream controls retain their responsibilities. Decision evidence can be exported for review.
Bring one consequential action and its business rules
See the rule.
Follow the enforced decision.
We'll map the facts, scope, conditions and human decisions
that belong on your governed execution path.