Which data drove this decision?
Facts and judgments link back to the source revisions they used.
Provenance, Lineage & Evidence
Follow the evidence.
Explain the outcome.
Answer “why did this happen?” from one record: the source data, the decision, who approved it and the evidence of the result.
The record is built as the work runs, not pieced together afterwards. Tamper-evident entries stay tied to the versions in force at the time.
FROZIONExecution FabricGoverned from request to outcome
Start from what happenedINV-1042 · Payment recordedYour ERP’s confirmation, kept
confirmed by↓
Proof of paymentERP payment PAY-4821 · revision 1
which was allowed by↓
The approvalReviewer + passkey · invoice r5
reviewed with↓
What the decision usedContext · source records · 2.0% variance
Recorded as the work runsEvery link says what it meansThe exact versions in forceMissing evidence stays visibleEach reviewer sees what they may
One explainable record on every adoption path
Govern existing agents
For connected tool calls, see what was asked, what was decided and what the target system reported.
Grow tools into workflows
Sources, calculations, approvals and results sit in one connected case history.
Build native agents
Inspect the recorded evidence behind your native agents’ governed actions.
Build systems of engagement
Answer an employee’s, customer’s, vendor’s or partner’s “why?” with the decisions and source records behind their case.
The problem this solves
Data lineage tells you where data went. You also need to know why the decision was made.
Connect the data to the rules, authority, exact approval and recorded outcome. When the evidence is missing, the gap stays part of the explanation.
Which rules and approval applied?
The exact versions and the approved proposal are on the record.
Did it actually happen?
A confirmed change, an attempt and a missing confirmation stay distinct.
01 / From data to decision to result
Data has a history.
So does the decision.
A source-to-field map explains data movement. A business outcome also involves identity, policy, judgment, approval and execution.
The published application version and the individual run connect the sources, decisions and results. Each relationship keeps its meaning across systems and waits.
| Concept | The question it answers | What supports the answer |
|---|---|---|
| Provenance | Where did this artifact originate? | Source identity, revision, derivation and generator. |
| Data lineage | How did information move or change? | Field, document, dataset and feature transformations. |
| Context provenance | What was supplied to this decision? | The input records, calculated facts and versions supplied to the decision. |
| Decision lineage | Which judgments formed the result? | Model, deterministic, routing, policy and human decision records. |
| Execution lineage | How did this run reach its outcome? | Inputs, authority, state, decisions, attempts and external effects. |
| How records link | How exactly are two records related? | Explicit links such as derived from, constrained by and authorized by. |
| Evidence | Which retained record supports the claim? | Receipts, snapshots, version references, digests and protected source records. |
Every link says what it means, not just when it happened. “Approval authorized proposal r5” states which decision permitted which action.
02 / Try it
Start from what happened.
See everything behind it.
Follow INV-1042 through eight stages, and switch cases to see what the record shows when something goes wrong.
Inspect the sources, versions and relationships behind a confirmed payment, missing confirmation, changed proposal or reconciled no-payment result.
Application version AP-Review v7This run EX-1042-ATenant A · Purpose: invoice settlement
Recorded outcomePayment confirmed
The ERP receipt confirms payment PAY-4821 for the approved invoice r5.
Evidence complete8 of 8 present
The declared boundaries have supporting records for this path.
Choose a stage
Proof of paymentPresent
The external system confirms the change.
Sending a payment request is not proof it was paid. The change is marked confirmed only once your ERP confirms it.
Evidence relationship
What it supports
Known gaps stay visible.
A missing confirmation leaves the payment outcome unresolved. The record shows the attempt and the gap, while a superseded approval stays tied to its original proposal.
Versions survive the wait.
Application, proposal, source, policy and approval versions stay attached to the run through durable waits. You can see what governed the recorded decision, even after the application changes.
See how work survives waits03 / Make the explanation supportable
See the evidence you have—and
the gaps that remain.
You can see whether a tidy timeline is a complete one.
The Lineage Coverage Contract defines the records each consequential path needs: sources, decision inputs, policy, approvals, attempts and a confirmed outcome or a reconciled no-change result.
Evidence gaps in the workflow are caught before it goes live.
Compile-on-Publish checks required evidence domains and links on the relevant workflow nodes. The Traceability Map connects runtime behavior to the published application version.
At runtime, missing expected evidence stays visible too.Evidence is recorded as the work happens.
Each required record shows as present, missing or not needed for that path. Sources, decisions, approvals and outcomes stay connected to the same run.
Coverage follows the path actually taken.You see what is still available.
The record shows available content, protected references, versions, retention state and integrity information together.
Content and access are shown in their current state.Keep the evidence in the form your policies permit.
Selective snapshots, protected references, source revisions, redacted excerpts and confirmation metadata keep the explanation connected. Authoritative content can remain in the system that owns it.
SnapshotProtected referenceVersion identityContent digest
Verify integrity. See what is still there.
Tamper-evident records let you verify whether the retained evidence has changed.
Retention rules and classifications stay on the record, along with any known gaps.
04 / Shared execution, appropriate access
One record.
Each team sees the part it needs.
Evidence is protected like the data it describes.
Tenant, purpose, business scope, classification and source permissions determine what each reader can inspect. The six views below connect those permissions to the questions each team needs to answer.
What needs attention?
State, waits, attempts, retries, timing and reported effects.
Which path ran?
Graph nodes, schemas, mappings, dependency versions and errors.
Whose authority applied?
Identity, delegation, assurance, scope, policy and capability eligibility.
What shaped the decision?
Material evidence, judgments, obligations, escalation and consequence.
What supports the account?
Versioned records, approval binding, effect evidence and known coverage gaps.
What happened to the proposal?
Relevant business state, the human decision and the resulting outcome.
Each view shows only what that person is currently allowed to see.
The evidence is kept for you.
Frozion stores or references each record and its links, connecting the systems you already run around the same application run.
Explore the AI Data PlaneInvestigate and replay from the same record.
Use the connected record to inspect a run, compare outcomes and reconstruct the history. Replay uses that record under its own access controls.
Explore Behavior IntelligenceYour systems stay authoritative
Frozion links to the evidence you already keep.
Data catalogs, identity systems, model gateways, workflow engines and observability tools retain their own records. Business systems retain committed state. Frozion connects those references to the decision, approval and result in the business case.
Auditors get what they need, and nothing more.
Give auditors scoped, read-only access, or export the cases they sample. The record keeps source restrictions, retention state and known gaps visible.
05 / Questions, answered
Keep the evidence.
Know exactly what it proves.
Every recorded link is explicit, and every known gap is visible.
Data lineage shows where data went. Execution lineage also shows the decision, approval and result, so you can explain an outcome as well as the data flow.
No. You get the application-visible inputs the model received, what it returned and what happened next—the evidence reviewers can inspect without its private reasoning.
No. You decide what is copied and what is referenced, so the record keeps the relationships without unnecessary duplication. Coverage shows when required evidence or referenced content is unavailable.
No. A request is recorded as an attempt. The change is marked confirmed only once the target system confirms it, directly or through authoritative reconciliation. Missing confirmation remains unresolved.
No. The record shows what happened, including rejected or blocked actions. Permission is checked separately before a governed action runs, and that decision is on the record too.
No. It adds the business relationship between a decision, its approval and its result, and works alongside your observability and audit systems.
Start with one consequential outcome
Answer “why did this happen?”
from one record.
Bring one business process. We’ll show the record it would leave, from source data to the confirmed result—or the gap that still needs resolving.