Architecture
Architecture for Enterprise AI That Must Be Trusted
Business logic remains deterministic where it should. Semantic context is prepared before model interpretation. The model is one component in a governed system, not the system itself.
This page describes system responsibilities. How we work describes delivery and change. Workflow authoring stays separate from the business-facing agent runtime.
From enterprise data to a reviewable decision
We use your existing data platform to turn business information into governed results, AI-assisted interpretation, and accountable decisions.
Complete overview.
- Data flow
- Query / control
- Optional evidence
- Human feedback
ERP, CRM, and operational systems stay outside the customer’s cloud data platform and send business information into prepared data. Prepared data feeds a governed calculation, which can publish a result. Semantic definitions inform that calculation and the interpretation. They are not a later processing step. A reviewer can read the published result directly. Separately, the AI runtime may send an approved-tool request and receive the returned tool result. The request is not the result. Identity, permissions, parameters, and business rules still apply. The runtime may also write a proposed explanation for business review. Documents can stay outside the platform. An optional authorized retrieval can pass a reference to the runtime or the reviewer. Retrieval is not proof, not an ingest step, and not a deployed product. A person records the decision. A proposed rule change is conditional: rule-owner approval, then a versioned definition, then revalidation before affected outputs are accepted. Recording a decision does not itself change a rule. Snowflake, Databricks, and BigQuery are alternative choices for one selected platform in this example.
Execution, evidence, and ownership
Where a calculation happens
A governed calculation may already be published, or it may run when requested through an approved tool. The tool call is a request. The number that comes back is a separate result returned to the AI runtime. Either result remains subject to the identity, permissions, parameters, and business rules configured for that workflow. The proposed explanation is written separately. Human review can use the result and the evidence without waiting for the explanation.
Who owns definitions and review
The business-rule owner is outside the technical platform boundary. That owner approves a proposed change, which becomes a versioned definition or rule and is revalidated before affected outputs are accepted. The reviewer inspects the result, the evidence, the uncertainty, and a proposed next step, then records a decision. The drawing shows that role. Playback does not record a business decision, and a recorded decision does not automatically open a rule change.
Evidence references
Supporting documents are a proposed reference responsibility. They can remain outside the warehouse. An authorized retrieval may supply a reference to the runtime, the reviewer, or both. It does not prove a claim, it does not grant arbitrary document access, and it is not a claim that a document-retrieval feature is already deployed. Detail that is outside this drawing stays in the deployment-control checklist.
What is configurable
Snowflake, Databricks, and BigQuery are alternative homes for the one platform in this example, not a sequence. Alteryx or the customer’s engineering tools can prepare data and implement rules. Where a workflow executes is chosen for that workflow, including execution that stays in those tools. AI runtimes, authoring experiences, and review interfaces may be hosted differently in a selected implementation. The cross-platform deployment pattern later on this page remains available when more than one platform is in scope. The names and placements here are a worked example.
The Orisdale reference architecture, on Google Cloud
The overview shows responsibilities. The Google Cloud pattern below shows one way to place them on a selected platform. Source data stays governed inside BigQuery. Alteryx One defines the preparation and the approved business rules. Only governed outputs and their semantic context reach the Agentic AI Runtime, and people review what matters. Expand the architecture to select a stage, or download this Google Cloud graph as SVG. The same six layers apply on Snowflake and Databricks. This is one reference pattern, not the only one.
Google Cloud reference pattern
Reference pattern. Not a demonstrated deployment and not an endorsement by Google Cloud or Alteryx.
Reference pattern
Enterprise source systems
Finance and ERP systems
Budgets and actuals
Data · Ingest and stage → Governed ingestion and staging
CRM and operational systems
Pipeline and operations
Data · Ingest and stage → Governed ingestion and staging
BigQuery · cloud data platform
Governed tables and views
Approved outputs
Data · Approved result and context → Agentic AI Runtime
Governed ingestion and staging
Controlled intake
Data · Staged data → Source tables
BigQuery compute
Runs delegated queries
Data · Publish governed outputs → Governed tables and views
Source tables
Inputs in BigQuery
Data · Read inputs → BigQuery compute
Semantic context
Meaning with the numbers
Query · Meaning and lineage → Governed tables and views
Conditional rule change
Business-rule owner
Versions a rule change
Feedback · Reviewed, versioned change → Business-rule definitions · conditional
Agentic AI Runtime
Approved tools only
Query · Approved query → Governed tables and views
Data · Explained result → Gemini Enterprise app
Gemini Enterprise app
Business experience
Feedback · Proposed finding → Human reviewer
Human reviewer
Confirms findings
Feedback · Rule change request → Business-rule owner · conditional
- Data flow
- Query and control
- Human feedback
Approved-tool reference pattern
A reference pattern for reviewable answers. Identity enforcement, parameterization, business correctness, and narrative checks are different controls. It is not a deployed product and not a native sequence inside every platform.
1. Interpret the question
Unclear parameters stay unresolved until someone clarifies the period, entity, or metric.
2. Call a named allowed tool
The request uses a validated schema. The model does not receive a free-form warehouse prompt as the execution path.
3. Enforce policy outside the model
Authorization and business-policy checks run in the platform path, separate from narrative generation.
4. Execute an approved calculation
The governed platform path runs the approved query or calculation. This diagram does not claim every vendor precompiles every query.
5. Return provenance with the result
The result carries the definition version, time, scope, and limitations that are actually available.
6. Cite the result in the narrative
Interpretation cites that result. A statement without a supporting result stays flagged.
7. Review consequential findings
A person reviews consequential findings. Denied requests, invalid parameters, and missing evidence are separate branches, not successful answers.
Denied and missing-evidence branches
- An invalid parameter or an unnamed tool stops before execution.
- A policy denial is recorded as a denial, not rewritten into an answer.
- Missing evidence stays missing. The narrative does not fill the gap.
See the same boundary applied to numbers you can inspect in the worked Finance variance example. Finance margin review. Revenue example: reconciled movement with unresolved population coverage. Energy example: overlapping records and commercial review. The role of each Google Cloud product is on the Google Cloud page.
Why model-first architecture fails
Connecting a model directly to raw enterprise data, without governed logic or semantic preparation in between, produces answers that look confident and are not reproducible. Two people can ask the same question and get two different numbers when the model invents the formula, grain, or threshold. An approved query may still calculate the metric. The failure is letting the model redefine it.
Layer by layer
Select a layer to understand its role, responsibilities, and controls within the complete system. Every summary is always visible; select a layer for expanded technical detail. Every detail is reachable by keyboard and on mobile — nothing important is hidden behind hover. For more on how the Agentic AI Runtime layer is constrained, see Enterprise AI Agents, Governed by Design.
CRM, ERP, financial systems, and other enterprise sources of record.
- Data remains in place inside systems the organization already operates and governs.
- Orisdale does not require a separate copy of the enterprise's source-of-truth systems.
Calculations, thresholds, classifications, and KPI definitions, controlled before AI interpretation.
Business context, relationships, and operating rules prepared for AI consumption.
Snowflake, Databricks, Google Cloud, and Alteryx One provide governance and compute.
AI experiences constrained by approved tools, data, and policies.
The interface where business users and executives interact with governed intelligence.
Control boundary
Monitoring, Control, and Human Review
Quality, access, cost, and behavior monitoring, with human approval in consequential workflows.
Security and governance
Deterministic logic, AI interpretation, and human review form one connected governance boundary around every Orisdale system.
Deterministic logic
Calculations, thresholds, and classifications are defined, reviewed, and controlled before any AI interpretation.
AI interpretation
The AI runtime explains and contextualizes governed outputs within approved tools and permissions.
Human review
Consequential decisions retain human approval, with monitoring for quality, access, cost, and behavior.
Deployment patterns
The same reference architecture deploys on Snowflake, Databricks, Google Cloud, or a combination, depending on where an organization’s governed data and AI runtime already live. See how each platform fits on the Platforms page.
Single-platform intelligence system
Governed logic, semantic intelligence, and the AI runtime all run inside one enterprise platform's native governance boundary.
Governed preparation plus enterprise data platform
A governed preparation layer standardizes business logic before publishing AI-ready data into the enterprise data platform.
Cross-platform governed intelligence system
Shared governed logic and semantic definitions reconcile data across more than one enterprise platform before AI interpretation.
Gemini Enterprise reference pattern
A proposed pattern, not a demonstrated Orisdale deployment and not a Google or Alteryx endorsement. Alteryx One prepares governed logic and workflows. BigQuery hosts both the enterprise source data and the governed analytical outputs under one storage boundary, not two sequential hops. Gemini Enterprise is the hosting choice: its Agent Platform is where technical teams build and govern an agent, and its app is the separate business-facing experience, when that path applies. Orisdale designs the decision, semantic context, implementation, and validation. Snowflake and Databricks remain peer platforms.
Model-agnostic by design
Governed business logic and semantic intelligence remain stable while the approved model or platform-native AI service can change according to the customer's architecture and governance requirements.
These are technical runtime options — not universal dependencies, not all used in every implementation, and not partnership claims. The runtime remains controlled by the approved customer architecture.
Technical runtime options
- Claude
- OpenAI
- Gemini
- Platform-native AI
Guardrails
- Approved models only
- Governed context and tools
- Monitored outputs
- Business logic remains deterministic where it should.
- Semantic context is prepared before model interpretation.
- Data remains governed by the enterprise platform.
- Model access is constrained by approved tools and permissions.
- Outputs identify source, scope, and limitations where appropriate.
- Human approval remains in consequential workflows.
- Monitoring covers quality, access, cost, and behavior.
Controls to establish for deployment
These are design requirements and customer-specific decisions. They are not a claim that any control is already deployed.
| Control | What has to be decided |
|---|---|
| Identity and tool permissions | Which user or service identity each permitted tool uses. |
| Query and result scope | Which results may cross the runtime boundary, and what is minimized before they do. |
| Version, period, and freshness | Which rule version, semantic version, reporting period, and freshness the answer uses. |
| Two validations | A calculation can match a contract while the narrative still needs separate evidence review. |
| People | Who approves a consequential finding, who owns a rule change, and who watches audit and monitoring. |
| Failure and missing data | What the experience does when data is unavailable, stale, contradictory, or out of scope. |