The Data Model Behind a Production AI Workflow

Prompts get the attention. The data model decides whether the AI workflow can survive production.

Once an AI system moves from a demo to operational work, it needs to remember what case it is handling, who initiated it, what evidence it used, what decision it proposed, which tool action was taken, who approved it, what changed, and whether the outcome improved the business metric.

Without that data model, the workflow becomes a sequence of impressive but disconnected model calls.

The workflow record is the control surface

If you cannot reconstruct the case after the fact, you cannot govern, debug, measure, or improve the AI workflow.

The workflow case is the center

The central entity is not the prompt. It is the workflow case.

A case is one instance of operational work: one renewal review, one escalation, one invoice exception, one vendor approval, one onboarding risk check, one account update, one compliance review.

The case connects everything else:

Actor: the user, role, team, agent, or system that initiated or handled the work.
Business object: the account, ticket, invoice, contract, vendor, project, or policy involved.
Context package: the evidence assembled for the decision.
Decision: the recommendation, classification, or judgment.
Action: the draft, tool call, write-back, escalation, or refusal.
Approval: the human review, edit, rejection, or override.
Outcome: the final result and business metric.
Audit event: the traceable record of what happened and when.

This model is what lets the business ask, “Why did the agent do that?” and get a real answer.

Why this matters before agents write back

NIST’s AI Risk Management Framework treats AI risk as something to address across design, development, use, and evaluation. A workflow data model is the operational map. It gives each recommendation and action a place to store evidence, policy, authority, and outcome so the team can measure behavior after the system is live.

OWASP’s Top 10 for LLM Applications makes the 2025 risks data-model problems as much as prompt problems. Prompt Injection, Sensitive Information Disclosure, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption are easier to control when tool calls are tied to identity, scope, case state, permissions, and logged outcomes.

IBM’s 2025 breach research makes the control gap concrete: the average breach cost was $4.4 million, and 97% of organizations with an AI incident lacked AI access controls. For AI workflows, the data model is part of that discipline because it makes permissions, actions, approvals, and incidents testable and observable.

A simple production model

erDiagram
    WORKFLOW_CASE ||--o{ CONTEXT_ITEM : uses
    WORKFLOW_CASE ||--o{ DECISION : produces
    WORKFLOW_CASE ||--o{ ACTION : attempts
    WORKFLOW_CASE ||--o{ APPROVAL : requires
    WORKFLOW_CASE ||--o{ AUDIT_EVENT : records
    WORKFLOW_CASE }o--|| ACTOR : initiated_by
    WORKFLOW_CASE }o--|| BUSINESS_OBJECT : concerns
    ACTION ||--o{ AUDIT_EVENT : emits
    DECISION ||--o{ APPROVAL : reviewed_by

This is not meant to be the final schema. It is the minimum shape leaders and builders should expect before a workflow becomes important.

The entities that carry accountability

Production AI workflow data model

These entities can be implemented in different systems, but the workflow needs a way to reconstruct them together.

Entity: Workflow case

What it stores: Case ID, workflow type, status, priority, timestamps, and owning team
Why it matters: Gives every model call and tool action a durable operating record

Entity: Actor

What it stores: User, role, tenant, team, delegated authority, and agent identity
Why it matters: Keeps actions tied to real business authority

Entity: Context item

What it stores: Source, field, citation, timestamp, trust tier, and permission result
Why it matters: Makes recommendations inspectable instead of mysterious

Entity: Decision

What it stores: Recommendation, rationale, confidence boundary, policy used, and model version
Why it matters: Separates model judgment from final approved action

Entity: Action

What it stores: Tool, arguments, dry-run diff, idempotency key, result, and rollback reference
Why it matters: Controls the moment AI touches real systems

Entity: Outcome

What it stores: Business result, review result, cycle time, error, rework, or accepted value
Why it matters: Connects the workflow to ROI and improvement

Store decisions separately from actions

One subtle design mistake is treating the model recommendation and the system update as the same event.

They should be separate. A decision is what the AI proposed or classified. An action is what the workflow did after policy, state, permission, and approval checks. This distinction matters when something goes wrong.

If a renewal agent recommends “high risk” but a manager changes it to “medium risk,” the system should preserve both the model decision and the human override. If an agent proposes a CRM update but the state check rejects it because the opportunity changed, the rejected action should be logged without pretending the workflow succeeded.

That is how the data model protects accountability.

Context items should be first-class

Context is often treated as a transient prompt ingredient. In production, important context should become a record.

Store the source type, source ID, retrieved field or excerpt, timestamp, trust tier, permission result, and how the context was used. You do not need to store every token forever, but you do need enough evidence to answer why the workflow made a recommendation.

This supports evaluation too. If reviewers keep rejecting decisions that relied on one stale source, you can see the pattern. If a prompt upgrade changes which context is selected, you can compare outcomes. If a permission policy blocks required context, the workflow can surface that as a design issue.

Outcome data is not optional

Many AI workflows log prompts and outputs but never capture whether the work improved. That leaves the business with usage metrics and anecdotes.

Outcome data should match the workflow:

Renewal review: risk accuracy, cycle time, accepted recommendations, saved renewals.
Support escalation: time to route, severity accuracy, reopen rate, customer impact.
Invoice exception: resolution time, error rate, recovered amount, approval quality.
Onboarding risk: blocked issues, launch delay avoided, handoff completeness.

McKinsey’s 2025 State of AI frames the same broader lesson: value depends on workflow and operating-model change, not tool deployment alone. Outcome data is how the team proves that change happened and whether the workflow belongs in the small group of AI initiatives that actually affect EBIT.

Build the model before broad autonomy

Before expanding an AI workflow, confirm that the data model can answer:

What case was this?
Who initiated it?
What business object was involved?
What evidence did the AI use?
What did the AI recommend?
What did the human approve or change?
What tool action executed?
What system changed?
What happened afterward?

If the answer lives across logs, screenshots, chat messages, and memory, the workflow is not ready for more autonomy.

This is why Metacto’s Operational AI work treats workflow architecture as part of the product. The data model is not plumbing under the product. It is the thing that lets the business trust the product and keep improving it through Continuous AI Ops reviews, evals, incidents, runbooks, and tuning.