PLATFORM ARCHITECTURE

Semantic Drift Intelligence™ Platform

A two-plane semantic observability platform — the SDI control plane in the On Point BI Azure tenant, a lightweight client agent deployed inside your Azure environment.

Semantic Drift Intelligence™ is deployed as a production-grade, AKS-based platform. The control plane hosts the multi-tenant drift engine, semantic registry, governance services, and reporting infrastructure. A lightweight agent is deployed inside each client’s Azure tenant to extract semantic artifacts from SQL warehouses, BI tools, documentation systems, and AI logs — and transmit only semantic units to the control plane for analysis. The agent never accesses raw data, communicates outbound-only over HTTPS, and requires no VPN.

The agent extracts meaning, not data. No raw data ever leaves your environment.

The SDI agent connects to data sources using read-only access, normalizes definitions into semantic units, and transmits those units to the control plane over outbound-only HTTPS authenticated with Entra ID Workload Identity Federation. No raw data, no query results, and no record-level information is ever transmitted outside the client Azure tenant.

ON POINT BI AZURE TENANT

SDI Control Plane

Multi-tenant API, drift engine, semantic registry, reporting service, and job runner. Powered by AKS clusters, Azure SQL, Service Bus, Storage, Key Vault, and Application Gateway with WAF. Manages drift detection, scoring, governance workflows, and continuous monitoring across all client deployments.

CLIENT AZURE TENANT

SDI Client Agent

Lightweight AKS-hosted agent deployed per client. Ingests SQL, BI logic, documentation, and AI logs. Extracts semantic artifacts only. Authenticates via Entra ID Workload Identity Federation. Outbound-only HTTPS. No inbound ports. No VPN required.

ON POINT BI AZURE TENANT

SDI Control Plane

The control plane is the multi-tenant intelligence layer that runs the drift engine, hosts the semantic registry, manages governance workflows, and delivers reporting across all client deployments. It operates exclusively on semantic artifacts and governance signals — no client data ever resides here.

The control plane never accesses client data directly. It operates on semantic units, governance signals, and platform telemetry only.

Core Azure Infrastructure

The control plane is deployed on enterprise-grade Azure infrastructure designed for multi-tenant operations, high availability, and regulatory compliance.

AKS Clusters

• System node pool (D4s_v5) for platform operations

• API node pool (D8s_v5) for multi-tenant API and drift engine workloads

• Jobs node pool (D4s_v5) for scheduled ingestion and analysis jobs

• No public AKS API server — private cluster configuration

Azure SQL

• Hosts the SDI control plane database (sdi_controlplane)

• Stores semantic registry, drift event records, governance state, and tenant configuration

• Private endpoint — not publicly accessible

Azure Service Bus

• Topics: agent-events, drift-alerts

• Queue: jobs-scheduled

• Manages asynchronous communication between client agents and control plane services

Azure Application Gateway with WAF

• Hosts api.sdi and app.sdi endpoints

• AGIC for ingress routing to AKS services

• WAF enabled for protection against web application attacks

Azure Key Vault

• Stores secrets for all control plane services and LLM provider credentials

• Secrets mounted into pods using CSI Secret Store Provider for Azure

• User Assigned Managed Identities scoped to platform operations

Azure Storage Account

• Containers: model-snapshots, config-exports, reports

• Stores semantic model snapshots, configuration exports, and generated reports

Control Plane Services

Semantic Registry

• Canonical repository for business definitions, metrics, and semantic metadata

• Full version history with lineage and ownership tracking

• Single reference point for all downstream drift comparison and governance operations

Drift Engine

• Combines deterministic rules, embedding-based comparison, and LLM reasoning to detect semantic inconsistencies

• Compares definitions across SQL, BI logic, documentation, and AI agent behavior

• Scores drift events by severity and business impact

• Generates recommended remediations with explanations

Multi-Tenant API

• Kubernetes namespace: sdi-api

• Handles all client agent communications and UI requests

• Enforces tenant isolation and per-client API scopes

• Authenticated via Entra ID OIDC tokens

Job Runner

• Kubernetes namespace: sdi-jobs

• Manages scheduled drift detection jobs, ingestion orchestration, and retry logic

• Consumes from Azure Service Bus jobs-scheduled queue

Reporting Service

• Generates drift reports, governance summaries, and registry exports

• Stores outputs to Azure Storage Account reports container

• Powers the UI drift viewer and governance dashboard

Governance Workflow Engine

• Manages ownership assignment, resolution tracking, and audit logging

• Routes drift alerts through approval workflows

• Produces auditable change records for every definition resolution

CLIENT AZURE TENANT

SDI Client Agent

The client agent is a lightweight AKS-hosted deployment inside the client’s Azure tenant. It extracts semantic artifacts from SQL warehouses, BI tools, documentation systems, and AI logs — normalizes them into semantic units — and transmits only those units to the control plane for analysis. No raw data leaves the client environment at any point.

The agent extracts semantic artifacts only. Your data stays in your environment.

Client Agent Infrastructure

AKS Cluster

• System node pool (D4s_v5) for agent platform operations

• Agent node pool (D4s_v5) for ingestion and normalization workloads

• Private cluster — no public AKS API server

Azure Key Vault

• Stores SQL connection strings, API tokens, and service credentials

• Secrets mounted into agent pods using CSI Secret Store Provider for Azure

• User Assigned Managed Identity scoped to agent operations only

Log Analytics Workspace

• Captures agent operational logs, ingestion run history, and error events

• Feeds into monitoring and alerting configuration

User Assigned Managed Identity

• uami-sdi-agent per client and environment

• Federated credential mapped to Control Plane Entra App

• Scoped to specific client tenant and subscription

Agent Workloads

Agent Core

• Ingests SQL warehouses, BI tool metadata, documentation sources, and AI agent logs using read-only access

• Normalizes semantic artifacts into a unified structure for drift comparison

• Transmits semantic units to the control plane API over outbound-only HTTPS

• Never transmits raw data, query results, or record-level information

Agent Scheduler

• Manages scheduled ingestion jobs on a configurable cadence

• Handles retry logic for failed ingestion runs

• Reports job status and errors to Log Analytics

Supported Ingestion Sources

Data and BI Sources

• SQL warehouses — Azure Synapse, Snowflake, Databricks, SQL Server, and equivalents via read-only access

• Power BI — semantic models, DAX measures, and report-level logic

• Other BI tools — metadata and logic extraction where API access is available

Documentation and AI Sources

• Documentation systems — Confluence, SharePoint, GitHub, Markdown repositories

• AI agent logs — behavior monitoring for semantic drift and hallucination pattern detection

• SSO integration — Azure AD, Okta, or equivalent for access control

SECURITY AND IDENTITY

A Zero-Trust, Data-Residency-Safe Security Architecture

The SDI security model is built on Azure-native identity and networking primitives that satisfy the access control, data residency, and audit requirements of regulated industries. Every design decision reinforces the same principle: the control plane never touches client data, and every cross-tenant operation is authenticated, scoped, and auditable.

Identity and Authentication

✓ All cross-tenant communication uses Entra ID Workload Identity Federation with OIDC tokens — no stored credentials or service account passwords

✓ Client agents authenticate to the control plane using their User Assigned Managed Identity with a federated credential mapped to the Control Plane Entra App

✓ Authentication is scoped to a specific client tenant and subscription — no cross-client access is possible

✓ All secrets stored in Azure Key Vault and mounted into pods via CSI Secret Store Provider — secrets never appear in environment variables or configuration files

Networking and Data Residency

✓ Client agent uses outbound-only HTTPS to the control plane — no inbound ports, no VPN required

✓ Control plane runs on private AKS with no public API server — public access only through Application Gateway with WAF

✓ All client data remains in the client Azure tenant — the agent transmits semantic artifacts only, never raw data

✓ Private subnets for AKS, SQL, and Service Bus in both control plane and client agent environments

✓ Optional Private DNS zone for internal SQL access in client agent environments

DEPLOYMENT

Two Deployment Sequences — Control Plane and Client Agent

SDI deployment follows two documented sequences. The control plane is deployed once as the shared multi-tenant infrastructure. The client agent is deployed per client, per environment — following a standardized sequence that ensures consistent, governed operations from day one.

Control Plane Deployment

Deploy VNet and subnets

private networking foundation for all control plane resources

Deploy Azure Key Vault

secrets infrastructure ready before any service deployment

Deploy Log Analytics Workspace

observability active from the first resource

Deploy AKS cluster

system, API, and jobs node pools with private configuration

Deploy Application Gateway with AGIC

WAF-protected ingress routing to AKS services

Deploy Azure SQL, Service Bus, and Storage Account

data persistence and messaging layer

Deploy User Assigned Managed Identities and federated credentials

identity layer before workload deployment

Deploy Kubernetes workloads

API, jobs, and system namespace services

Validate ingress and API availability

end-to-end connectivity confirmed before client agent deployment begins

Client Agent Deployment

Deploy VNet and subnets

private networking for agent AKS cluster

Deploy Azure Key Vault

agent secrets infrastructure

Deploy Log Analytics Workspace

agent operational logging active from deployment

Deploy AKS cluster

system and agent node pools with private configuration

Deploy User Assigned Managed Identity and federated credentials

Workload Identity Federation configured before workload deployment

Deploy ConfigMap

agent configuration injected before pod startup

Deploy agent core and scheduler

ingestion and normalization workloads active

Validate outbound connectivity to control plane API

authenticated connection confirmed

Run ingestion test job

end-to-end semantic artifact extraction and transmission validated

IMPLEMENTATION TIMELINE

Production-Ready in Four Weeks

The client agent deployment and initial drift detection configuration follow a four-week implementation timeline from environment provisioning to executive enablement and go-live.

WEEK 1

Environment Provisioning and Ingestion Setup

Client Azure environment provisioned using Infrastructure-as-Code. AKS cluster deployed and configured. SQL, BI, and documentation sources connected with read-only access. Agent core and scheduler deployed and validated.

WEEK 2

Drift Detectors and Registry Initialization

Semantic Registry initialized with priority metric definitions. SQL and documentation ingestion pipelines running. Drift detectors deployed and producing initial drift event data. Embedding and LLM comparison layers active.

WEEK 3

Validation and Governance Workflow Configuration

End-to-end drift detection validated across all connected sources. Governance workflows configured — ownership assigned, resolution tracking active, audit logging enabled. Drift Viewer accessible and populated.

WEEK 4

Executive Enablement and Go-Live

Executive briefing on drift findings and platform capabilities. Team enablement for Drift Viewer, governance workflows, and registry management. Platform live in production.

OPERATIONAL REQUIREMENTS

What You Need to Implement SDI

Technical Requirements

• Azure subscription with AKS provisioning permissions for client agent deployment

• Read-only SQL access to priority data warehouses

• BI workspace or metadata access for Power BI semantic model ingestion

• Documentation sources accessible via API — Confluence, SharePoint, GitHub, or Markdown repositories

• SSO integration via Azure AD, Okta, or equivalent

• Networking configuration for outbound HTTPS from client agent to control plane

• Optional: AI agent logs for AI drift monitoring

Organizational Requirements

• Metric owners identified for priority KPI families

• SQL, BI, and documentation contacts established for source connection approvals

• Governance contacts identified for workflow ownership and sign-off

• Agreed drift triage process — how drift events will be reviewed and resolved

• Access approvals completed prior to agent deployment

EXPLORE FURTHER

Continue Your Evaluation

Overview

Return to the SDI overview — the problem of semantic drift, how the two-plane platform works, and the outcomes organizations achieve.

Maturity Model

The four-phase SDI maturity model — from semantic observability through governed workflows, prevention agents, and closed-loop remediation. See where your organization is today.

Pricing

The $120,000 one-time implementation, Professional and Enterprise subscription tiers, Phase 2 Accelerators, and add-ons — all on one transparent page.

Schedule a Strategy Session

Talk to our team about your organization’s semantic governance environment and whether SDI is the right fit.

Schedule a Strategy Session →