Visible definitions
Review sources, joins, filters and output contracts before other steps depend on them.
Visual Query Builder
Build the query.
Trust what it means.
Design queries visually, using SQL concepts the team can inspect. Sources, joins, filters, scope and time are explicit; the typed result carries its meaning, permissions and provenance into the decision.
Visually define the sources, relationships, scope and result contract. Keep permissions, time, units and provenance attached as data moves into a decision—and the action that follows.
BUSINESS QUESTION
What is this supplier's
What is this supplier's
current payment exposure?
SupplierCanonical resource
1 : manyScope + time preserved
Open paymentsAuthoritative payment state
AggregateDeclared currency + basis
TYPED RESULTUSD 125,000
Value · scope · freshness · evidence
BUILT INTO THE FROZION AI DATA PLANE
Typed operational collectionsVisual joins & result contractsExecution-bound authorityQuery-to-decision lineage
Operational collections and queries across your adoption path
Govern existing agents
Resolve scoped business records through a defined query before a governed action.
Grow tools into workflows
Reuse visual query definitions and typed results across workflow steps.
Build native agents
Native agents use declared queries with business meaning and permissions preserved.
Build systems of engagement
Application processes use the same operational records and inspectable query definitions.
The problem this solves
The query needs to be as inspectable as the answer.
A correct-looking result can conceal a join that double-counts, a missing value treated as zero or a query that ignores the caller’s scope.
Explicit missingness
Distinguish zero, missing, stale, denied and unavailable results.
Business meaning
Keep units, time, source ownership and scope attached to the value.
Start with the agents you have
Give existing agents
a governed way to ask.
A tool call can invoke a Frozion workflow that queries operational data, validates its meaning and returns an eligible result.
Keep your agent's language and framework. Bring selected data-access paths into Frozion, where queries can share the same policies, Feature Store facts, human decisions and execution evidence as the rest of the workflow.
01 · EXISTING INVESTMENTYour agent or application
Requests a defined business capability.
02 · GOVERNED PATHFrozion query + orchestration
Binds scope, validates facts and handles exceptions.
03 · REUSABLE RESULTTyped, scoped context
Returns eligible information with its status.
Controls apply to integrated query and execution paths. Reading data does not authorize a later write or widen an agent's unrelated access.
01 / Model & compose
Start with the business fact.
Make its definition visible.
“Current payment exposure for this supplier” carries more
meaning than a column named amount.
Declare the proposition first. Then compose the sources, fields, filters, joins and aggregation that can establish it. Review the definition before downstream logic depends on it.
Model the business objects
Operational Collections represent suppliers, cases, invoices and other typed entities with CRUD semantics and relationships. Declare canonical identity, properties, classifications, source ownership and lifecycle so pages, workflows and policies refer to the same object.
Choose authoritative sources
A supplier master, payment service and analytical warehouse may hold similar fields with different meanings. Bind each source to the proposition it can establish, including its legal scope, freshness and correction behavior.
Declare the result contract
Specify schema and cardinality alongside currency, basis, time, missingness and permitted consumers. A downstream step should know whether a value is current, estimated, incomplete or unavailable before using it.
Relationships are application logic
A valid join can still
answer the wrong question.
Joining two one-to-many relationships can multiply payment values before aggregation. Matching supplier IDs can also cross legal entities if the canonical binding is incomplete.
Expose keys, cardinality, effective time, duplicate handling and missing-row behavior in the governed definition. Carry authority through the joined result.
Join contractSupplier → open payments
- Canonical binding
- Tenant + legal entity + supplier ID
- Expected cardinality
- One supplier → many payment records
- Aggregation
- Sum each eligible payment once
- Time & basis
- Current, open, posted amounts in USD
- No matching rows
- Distinguish a verified empty set from missing data
- Scope propagation
- Preserve resource and property restrictions
Source relationships and supported query structures are configured for the application.
NATURAL LANGUAGE, WITH AN EXPLICIT BOUNDARY
A model can suggest entities, filters, joins or a time window. Resolve that proposal against canonical resources, allowed structures and active permissions. Parameterize values and allowlist dynamic identifiers and operators. Generated SQL remains a compiled derivative of the governed definition; it does not grant access.
02 / Scope & validate
Keep authority and meaning
inside the query contract.
Correct types are essential. So are the right resource, the right permissions and the right point in time.
The active Execution Instance supplies the subject, workload and scope. Trusted predicates bind the query to that authority instead of depending on a model or user to remember every access filter.
Scope beyond tenant ID
Bind legal entity, resource, row, property, purpose, taxonomy, classification and residency where required. Preserve those boundaries through joins, aggregates, projections and later evidence views.
Current is a contract
Distinguish effective, observed, transaction, materialization and decision time. Declare current or as-of state, freshness thresholds and any consistent-snapshot requirement across sources.
Missing is not zero
See units, gross or net basis, conversions and defaults alongside the result. Stale, denied, absent, conflicted and unavailable values remain distinct; a successful database call alone does not establish a valid business fact.
Interactive contract example
Can this result enter the decision?
The same supplier query, with different authority and source conditions.
DECLARED QUERY · EXPOSURE v7
Current open payment exposure
- Resource
- SUP-204 / US-01
- Purpose
- Supplier account-change review
- Source role
- Authoritative payment state
- Result
- One summary · amount: number · USD
- Freshness
- Observed within 5 minutes
- Join rule
- No duplicate payment contribution
Trusted execution scope is bound separately from business
query parameters.
RESULT CONTRACTCURRENT
USD 125,000
Eligible for the declared consumer.
The source is current, the query scope is satisfied and the result meets its declared contract.
- Contract check
- Current, complete, typed and within scope.
- Next step
- Pass the validated fact to the policy evaluation.
QUERY RECEIPT
query: exposure/v7 · result: CURRENT · output:
eligible
Strict schemas.
Explicit exception paths.
Type-check fields, joins and result bindings when publishing. At runtime, validate source responses and semantic status before exposing a result to dependent steps. A number returned as a string should not be silently accepted under a numeric contract.
When the source is unavailable or the result is stale, route the declared exception: refresh, enrich, review or stop. A contract turns surprises into explicit conditions the workflow can handle.
Parameterized does not
automatically mean authorized.
Keeping values separate from executable query structure addresses injection risk. It does not establish which supplier a caller may inspect, which properties may be disclosed or whether an aggregate leaks information outside the permitted scope.
Apply resource and property authorization independently, and keep it attached throughout query composition and result use.
Explore identity & security03 / Reuse & orchestrate
Put the fact to work.
Keep its context attached.
The query is one step in a complete governed business capability.
Combine operational facts with calculated Feature Store values, retrieved evidence and policy. Reuse eligible results in existing agents, native workflows and applications while preserving the conditions under which they are valid.
ONE TOOL CALL FROM AN EXISTING AGENT
Review a supplier account change
Each protected step has its configured RBAC and policy checks.
-
01
Resolve & query
Bind the supplier and active scope. Read current payment state and account-change history.
-
02
Assemble the facts
Validate the query result. Add versioned risk features and eligible verification evidence.
-
03
Evaluate policy
Use nested conditions over the same typed facts. Record the decision and obligations.
-
04
Escalate when required
Pause durably for authorized HITL review and FIDO2 reauthentication where policy requires it.
-
05
Revalidate & act
Recheck current authority and facts at the action boundary. Invoke the permitted API operation.
-
06
Inspect the outcome
Connect query evidence, policy, human action and the resulting effect in one execution graph.
Context the consumer can interpret
Context Assembly can carry the proposition, canonical resource, value, status, scope, time and provenance as a typed Context Item. Models and reviewers receive the meaning of the fact alongside its value.
Explore Context AssemblyShared definitions across experiences
Use the same governed business objects and query definitions in operational screens, workflows, policy evaluations and contextual AI. Reuse a definition under each caller's current authority; do not treat a previously eligible result as universally shareable.
Explore App BuilderDurable waits, current facts
A human decision can take longer than the query's freshness window. Retain what the reviewer saw, then refresh or revalidate the facts required before a later effect. Historical decision context and current operational truth serve different purposes.
Explore Durable Execution
One data plane, distinct responsibilities
Keep each data source's role clear.
Keep the systems that own and execute your data. Frozion connects their application meaning, authority and evidence through configured source bindings.
| Data role | Question it helps answer | Boundary to preserve |
|---|---|---|
| Operational Collection / system of record | What is the supplier's current registered account? | Authoritative business state, with typed identity and relationships. |
| Feature Store | What is exposure or risk under a specific calculation definition? | Calculated facts retain definition version, time, freshness and provenance. |
| Warehouse / lakehouse | How did payments change last quarter? | Analytical data may have a different model or freshness than current operations. |
| Knowledge retrieval | Which documents support this account-change request? | Relevant evidence does not establish current transactional state by itself. |
04 / Inspect & evolve
Follow the result
all the way to the action.
Inspect what was asked, what made the result valid and which decision consumed it.
Trace the query definition and execution receipt through the published graph and recorded run, alongside policy evaluations, human decisions, tool calls and business effects.
QUERY EXECUTION RECEIPT
Understand the evidence behind the result.
Inspect the facts that explain execution through references that respect access to protected result content.
Definition & authorityProposition, version, plan digest, subject, workload and
scope.
Source & timeSource identities and revisions, canonical bindings, decision
time and snapshot.
Result & validationRow count, output digest, freshness, semantic status,
missingness and conflicts.
Execution & useLatency, retries, source errors and the downstream decision
that consumed the result.
Business need→Authority + query→Result receipt→Policy + review→Business effect
Compile the governed definition
Compile-on-Publish can resolve bindings, type-check joins, validate units and result contracts, prepare parameterized plans and install lineage hooks. Source optimizers can choose efficient physical execution within the declared meaning and authority boundaries.
Review semantic compatibility
A schema may still pass when a source changes currency units, a view changes filters or a join starts duplicating records. Evaluate source, scope, time, mapping and result changes against the query contract and affected executions.
Keep prior runs interpretable
Associate consumed results with their definition and source versions. Assess compatibility for new and suspended executions. A new definition should not silently reinterpret old evidence or turn a historical permission into current authority.
THE INTEGRATED VALUE
From visual query construction to governed business execution.
Visual construction makes the query reviewable. The AI Data Plane carries its scope, time and meaning. The AI Control Plane connects it to policy, human escalation, durable execution and an inspectable graph. Your team can review the data access and the action it enabled as parts of the same application.
See which work depends on the query.
Inspect the workflows that consume the query definition. Review source, join, mapping, scope and result changes alongside the affected workflow versions before publishing.
Common questions
Where the query
fits in your platform.
Yes. Expose the governed query through a Frozion tool or workflow invoked with MCP, or call a workflow over HTTPS. The caller retains its framework while the operation applies scope, contract, freshness and evidence checks.
Existing databases, ERP and CRM systems, warehouses, query
engines and analytics tools can remain. The governed
definition establishes which source can answer a
proposition and under which conditions. Source-specific
integration and execution depend on the configured
bindings and adapters.
It combines visual query construction with a typed, scoped and versioned business result. The definition makes joins, time, units and missingness explicit, while the consumed result carries source and permission context into policy, human review and execution.
No. Publish-time checks catch incompatible definitions and
bindings; runtime checks handle actual source values,
authorization, freshness and availability. Explicit
failure states let the workflow respond deliberately
instead of treating unexpected data as a valid fact.
Operational queries establish facts from declared sources.
The Feature Store provides calculated decision facts under
versioned definitions, with time, scope, freshness and
provenance. A workflow can use both; retrieving a feature
does not erase the conditions under which that feature is
valid.
Retain the context and evidence the reviewer used. Before
a later action, revalidate the current authority and any
facts whose contracts require freshness. A human approval
does not automatically make a stale fact current or
override a revoked permission.
They should preserve permission-aware references and the
evidence required to explain the run. A receipt can
include result status, row count and output digest without
becoming an unrestricted copy of sensitive records.
Evidence access remains subject to its configured
authority boundaries.
Bring one business question and the data it depends on
Define the fact.
Govern how it is used.
Let's map the sources, scope, contracts and workflow
your agents and applications need.