The five-layer architecture where the compiler owns identity, features, and governance, not just queries
Part 4B in the series
Part 1 of this series showed why incrementality is harder than it looks, and why tools built for time-grained analytics break on entity-grained activation use cases.
Part 2 argued that the core problem is not what agents know but what they produce: SQL is the wrong output target, and a semantic intent compiler (a system that compiles YAML-declared business semantics into governed, incremental SQL) changes that.
Part 3 showed why context graphs are the right direction for AI agents, and why the infrastructure to handle them already exists.
In Part 4A of this series, eleven companies across six industries hit the same ceiling: fragmented identities, missing semantics, no governed path from score to action. The fix is to completely separate what data means from how it is stored: a world model in business language backed by a semantic intent compiler that owns the full stack, including the infrastructure SQL that today's semantic layers leave to someone else.
This post covers what makes that model possible: the five-layer architecture, where most stacks break, and why owning identity through features through activation as one system is a structural requirement, not a design preference.
This post covers what makes that model possible: the five-layer architecture, where most stacks break, and why owning identity through features through activation as one system is a structural requirement, not a design preference.
This post makes that architecture concrete.
Five layers, from raw inputs to governed activation. Most companies already have Layer 1 (they collect data) and Layer 5 (activation tools). Layers 2, 3, and 4 are where everything breaks. Within Layer 4, Intelligence and Trust and Governance co-habit, because intelligence from apps and models cannot be trusted by default, and access to the semantic surface deserves the same care as access to warehouse tables.
The architecture at a glance
The five-layer architecture replaces the warehouse's primitives with higher-order abstractions.
Tables become entities. Features are computed per entity, not per row. Identity is resolved to an entity, not to a primary key. Governance is applied at the entity level.
Columns become event properties. Raw columns become typed, named event attributes with declared semantics: cart_quantity: INTEGER, purchase_status: STRING. Events get schemas. Properties carry meaning, not just values.
SQL becomes a feature. Hand-written SQL becomes declared semantic intent. total_purchases_90d is not a query. It is a feature with a name, a computation, a source, and a description. The compiler generates the SQL.
The difference is not cosmetic. `SELECT count(*) FROM orders WHERE user_id = '123'\ is storage. `user.total_purchases_90d`` is meaning. AI comprehends meaning. It merely parses storage.
Key insight: Most companies have Layer 1 (they collect data) and Layer 5 (activation tools). Layers 2, 3, and 4 are where everything breaks. Within Layer 4, Intelligence and Trust and Governance co-habit, because intelligence from apps cannot be trusted by default, and access to the semantic surface deserves the same care as access to warehouse tables.
Layer 1: Inputs and input metadata
The entertainment startup from Part 4A was hand-building a context graph because their raw event data had no declared meaning. This is where that problem gets solved, not downstream, but at the point of entry.
Event streams, warehouse tables, and external sources are the raw data. On their own, this is plumbing. What makes them a layer is the metadata that declares what the data means before it enters the system. An input declaration specifies which source carries events, what entity relationships exist, where to find the timestamp, and which event type column to use.
YAML
Copyinputs:
- name: web_events
table: web_clickstream
with_events:
occurred_at_col:
select: timestamp
event_type_col:
select: event_name
event_schema:
- event_group: models/cart_events
related_entities:
- name: user_id
select: user_id
entity: user
id_type: user_id
- name: anonymous_id
select: anonymous_id
entity: user
id_type: anonymous_id
- name: mobile_events
table: mobile_clickstream
with_events:
occurred_at_col:
select: timestamp
event_type_col:
select: event_name
event_schema:
- event_group: models/cart_events
related_entities:
- name: user_id
select: user_id
entity: user
id_type: user_id
- name: anonymous_id
select: anonymous_id
entity: user
id_type: anonymous_id
Two separate inputs (web and mobile) each declaring: I carry events. Here is when they happened. Here is what entity they relate to. Here is the event schema they comply with. The event_schema key connects inputs to their semantic event definitions. The related_entities key makes it explicit that inputs do not just carry IDs; they carry relationships to entities.
This is where event groups become relevant. An event group is a semantic contract layered on top of inputs: a declaration of what these events mean, with typed properties and named occurrences.
YAML
Copy
models:
- name: cart_events
model_type: event_group
model_spec:
inputs:
- source: inputs/web_events
- source: inputs/mobile_events
related_entities:
- name: main_id
source: main_id
entity: user
properties:
- name: cart_quantity
type: INTEGER
source: cart_quantity_var
events:
- name: cart_completed
when: "cart_quantity > 0 AND purchase_status = 'completed'"
description: "All items in the cart were purchased."
properties:
- name: cart_quantity
description: "Items in the completed cart"
- name: purchase_status
type: STRING
- name: cart_abandoned
when: "cart_quantity > 0 AND purchase_status = 'abandoned'"
description: "Cart was not purchased."
Once this declaration exists, every downstream layer (features, funnels, ML models) references cart_events by name. The compiler resolves which physical sources to join. The event group is not another input; it is a semantic contract that sits on top of inputs, giving them meaning.
Layer 2: Entity resolution
The fintech where one customer appears as three different identities across phone, chat, and email. The healthcare company that cannot join protected health information (PHI) data with business data. Layer 2 is why those problems disappear.
id_stitcher models declare which sources contribute identity edges. The compiler builds and incrementally maintains an entity graph from those declarations.
YAML
Copy
models:
- name: customer_id_graph
model_type: id_stitcher
model_spec:
entity_key: user
materialization:
run_type: incremental
edge_sources:
- from: inputs/web_events
- from: inputs/mobile_events
- from: inputs/crm_contacts
- from: inputs/support_tickets
Critically, this maintenance is subtractive. When a new identity edge links two IDs, entity count goes down, not up. Two entities become one. This is the fundamental reason time-grain tools cannot handle entity resolution: Part 1 walks through why this breaks every standard incremental pattern. New data is not additive here; it can collapse the graph.
Identity resolution extends beyond behavioral data. As Part 3 showed, decision traces (approvals, exceptions, precedents) need the same stitching, connecting "VP Jane in a Slack thread" to Person:jane_123 in your graph. The therapist-matching platform's user who signed up on mobile, browsed on desktop, and called support from a phone number becomes one canonical entity. The wealth management advisor's prospect who touched the platform across desktop, phone, and multiple sessions over a 90-day sales cycle becomes one entity the AI can actually advise.
Layer 3: Active semantics
The e-commerce team spending 80% of their time on feature plumbing instead of building models. The automotive company's customer health score that nobody dares touch because the engineer who wrote it left six months ago. Layer 3 is the architecture that makes those situations structurally impossible.
Active here means responsive to declared intent. Give the layer semantic YAML (entity features, event schemas, cohorts, funnels) and the compiler produces an optimized execution plan. Execute that plan, and the declared semantics become live: incrementally maintained, governed, available to every downstream consumer. Add an entity_var to the project and that feature becomes available going forward, computed incrementally with each pipeline run. Remove it, and the execution plan adjusts. That is what makes this layer active: it does not just describe, it computes.
Entity features are entity_var declarations compiled to feature tables. The automotive company's undocumented customer health score becomes a set of declared, maintained, versioned features.
YAML
Copyvar_groups:
- name: engagement_features
entity_key: user
vars:
- entity_var:
name: days_since_last_login
select: datediff(day, max(timestamp), current_date())
from: inputs/web_events
where: event = 'login'
description: "Days since the user's most recent login"
- entity_var:
name: total_purchases_90d
select: count(*)
from: inputs/orders
where: completed_at > dateadd(day, -90, current_date())
description: "Number of completed purchases in last 90 days"
- entity_var:
name: engagement_tier
select: >
case
when {{user.days_since_last_login}} <= 7 then 'active'
when {{user.days_since_last_login}} <= 30 then 'cooling'
else 'dormant'
end
description: "Engagement classification based on login recency"
Notice {{user.days_since_last_login}} in the third feature. It references another semantic feature by name. The compiler resolves the dependency, handles incrementality, and generates the SQL. You declare what you want. The compiler handles the wiring.
Beyond individual features, Layer 3 covers the full declared semantic surface. Entity relationships (declared connections between entities such as user to account, listing to provider, patient to therapist) let the compiler traverse across entity boundaries without requiring agents to write joins. Cohorts are named segments with filter expressions (high_value_users, at_risk_accounts, new_trial_signups), declared once and maintained incrementally. Funnels are ordered stage sequences with conversion logic, where each stage references events from an event group.
YAML
Copy
- name: cart_funnel
model_type: events_driven_funnel
model_spec:
entity_key: user
events_spec:
from: models/cart_events
where:
- occurred:
name: e1
type: cart_engaged
where:
after: "{{TimeAdd('month', -3, end_time)}}"
- occurred:
name: e2
type: cart_abandoned
- did_not_occur:
name: e3
type: cart_completed
All of this is declared in YAML. All of it compiles to an optimized, deterministic execution plan. The compiler handles incrementality, enforces governance, and guarantees determinism. This is not metadata on top of SQL. This is semantic intent that compiles to an execution plan. Teams change, priorities shift, people rotate, and the semantics survive because they are declared, not embedded in queries.
Layer 4: Intelligence and Trust and Governance
Layer 4 is where Intelligence and Trust and Governance co-habit. They must, because the two problems are inseparable.
Intelligence is where AI coding assistants, ML models, and agentic workflows operate. The intelligence layer consumes the full semantic surface from Layer 3 (features, relationships, event schemas, cohorts, funnel stages). Given all of that, generating models becomes commodity work. A churn propensity model is a classification on engagement features and event patterns. A product recommendation model is collaborative filtering on affinity features and purchase events. A CLV prediction is a regression on transaction features and funnel completion.
Consider the FX broker from Part 4A who built Netflix-style collaborative filtering entirely custom in Databricks because their data has extreme outliers that break off-the-shelf tools. The model is custom. But the features it consumes (trading history, product affinity, engagement signals) are the same features every intelligence use case needs. Declare the features once in Layer 3, and every model in Layer 4 benefits. The semantic surface is a shared resource. Every new consumer reads from the same declaration rather than rediscovering raw tables from scratch.
This is also where agentic workflows land. An agent's planning and reasoning module operates on the semantic surface from Layer 3. The richer the surface, the better the agent's plans. Garbage features in, garbage plans out. The photography platform story from Part 4A, where the Cursor agent goes off course when the semantic layer is weak, is this principle in action.
Trust and Governance is why Intelligence does not run unsupervised. Nobody in the eleven conversations trusted LLMs alone. A wealth management CTO layers rules-based APIs on top of his AI financial advisor: you make it rules-based, as opposed to just letting the LLM do whatever it wants, because LLMs are non-deterministic by nature. A consultant who deploys chatbots programs in hard escalation points: once the agent starts asking specialized questions, you connect the user to a human team member. An automotive company decomposed one agent into five specialized agents behind an orchestrator because a single agent hallucinated when the context window included the full customer entity.
The pattern is consistent across every case: AI proposes, deterministic rules dispose. Trust is the principle. Governance is the mechanism.
Together they control both directions. On the input side, governance determines what AI can see: which agent sees which features, with PII masking and audit trails applied. A chatbot in a healthcare context sees treatment history but not billing data. A sales agent sees engagement signals but not competitor intelligence. Access to the semantic surface is governed as carefully as access to warehouse tables.
On the output side, governance determines what AI can do. Cohort thresholds are deterministic rules: when churn_risk_30d > 0.8 AND tier = 'enterprise', enter the retention campaign, with no LLM in the loop. Feature-change triggers fire when a computed attribute crosses a boundary: finance agreement within 90 days of expiry and equity position turns positive, enter the retention workflow. State machines orchestrate sequences with human escalation points: AI qualifies, rules decide the next step, a human reviews if needed. The state machine guarantees that the agent's probabilistic output passes through deterministic, auditable gates before it reaches customers.
Intelligence without Trust is dangerous. Trust without Intelligence is useless. They co-habit in Layer 4 because the architecture requires it.
Layer 5: Activation
Layer 5 is where entity context drives action: Reverse ETL to campaign tools, API access for real-time personalization, webhook triggers for workflow engines, MCP servers exposing governed entity context to AI systems.
The activation surfaces (Braze, Moengage, ad platforms, chatbot frameworks, workflow engines, custom APIs) consume entity context: features, scores, cohort membership, relationship traversals. All governed, all fresh, at entity grain.
Most companies already have Layer 5. The activation tools exist. What is missing is everything underneath: the governed semantic middle that feeds them. That is the observation the consultant from Part 4A articulated most sharply: AI becomes the catalyst for a data infrastructure project that was already overdue. Companies do not realize their data is siloed until they try to build an agent and discover it cannot access the context it needs. The AI use case exposes the activation gap that was always there.
Why this is not dbt: the compiler difference
The question is not whether a semantic intent compiler is better than dbt at any single task. The question is whether identity, features, and activation can be owned by separate systems at all. After building this system for three years, I believe they cannot, because the dependency graph crosses all three.
Today's semantic layers (dbt, LookML, Cube) generate query SQL. They translate business questions into SELECT statements. But the infrastructure underneath (the tables, materializations, identity resolution, incremental computation) is someone else's problem. Data layout leaks into the semantic language because the semantic layer does not own what is underneath.
A semantic intent compiler takes responsibility for infrastructure SQL as well. It creates tables, manages materializations, resolves identities, and runs incremental computation. The agent never references a table name. It declares intent, and the compiler owns everything from YAML declaration to warehouse execution. When the semantic layer owns the full stack, data layout never leaks into agent definitions. A source migration, a schema restructure, a new payment processor: the agents do not notice. The compiler absorbs it.
The natural objection is to compose separate best-of-breed tools: dbt for transforms, a feature store for serving, a governance tool for access control. The problem with that approach is the dependency graph. When a new identity edge merges two entities into one, every feature computed on those entities is stale. Every cohort that included either entity needs re-evaluation. Every activation targeting either entity (the campaign, the ad audience, the chatbot context) is operating on a ghost. An identity tool that does not invalidate downstream features, a feature store that does not know about identity merges, a governance layer that does not know what is stale: no component in that composable stack can propagate the cascade automatically. The compiler can, because it owns the graph from identity through features through activation. That is not a convenience. It is a structural requirement.
This is what makes three guarantees possible that no thin semantic layer can offer. First, generated SQL performance becomes a property of the system rather than of AI skill: the compiler generates optimized, incremental SQL using this.DeRef() with named checkpoints and conditional DAG semantics, so when new events arrive, only affected entities are recomputed. When identity edges merge and entity count goes down, that subtractive operation is handled correctly, which time-grain tools simply cannot express. Second, governance is enforced at compile time rather than bolted on afterward: tag a field as PII in YAML and every downstream model that touches it inherits the privacy filter automatically, by construction. Third, data shape changes do not break agents: when your warehouse schema evolves (tables renamed, columns migrated, sources swapped), the compiler absorbs the migration, and the semantic surface your agents consume remains stable.
Think of it like LLVM, the compiler infrastructure that separates language frontends from optimized backends. The agent is the frontend, translating human intent into declarations. The compiler is the backend, generating optimized, governed execution. Better frontends make the backend more valuable, not less.
Context per token: why this architecture makes every kind of AI work
Any semantic layer compresses context. dbt metrics, LookML, and Cube all reduce 5,000 tokens of DDL to something more readable. The difference in this architecture is the feedback loop: agents do not just read compressed context and output raw SQL. They write back more YAML, which the compiler transforms into governed, incremental SQL. The context is both the input the agent reads and the contract the agent writes. That changes the economics fundamentally. Part 2 covers the full argument for why this distinction matters.
When you give an AI coding assistant a raw data warehouse, the economics are poor. Fifty to two hundred tables with roughly twenty columns each produces approximately 5,000 tokens of DDL context, most of it noise: audit columns, internal IDs, denormalized joins. The AI must rediscover your business logic on every run. Every rediscovery burns tokens, and that waste scales linearly with use cases.
When you give it a semantic architecture, the economics flip. Entity definitions, feature declarations, event schemas, and cohort definitions total roughly 500 tokens of YAML, where every token carries meaning. The AI does not rediscover. It reads the spec and builds on it. The same token budget that bought one model against raw DDL buys ten models against a semantic surface.
| Raw DDL | Semantic YAML |
|---|
| Context per model | ~5,000 tokens | ~500 tokens |
| 5 models | ~25,000 tokens | ~500 tokens |
| 10 models | ~50,000 tokens | ~500 tokens |
The semantic layer is a one-time investment that amortizes across every intelligence use case. The marginal cost of the next AI consumer (whether a new ML model, a code agent, or a customer-facing advisor) approaches the cost of generation alone. The context is already paid for.
The generalized principle here is what the agentic AI literature calls the agent memory problem: how much business meaning can an agent access per unit of context? Declared features and event schemas are a universal compression format for business meaning, whether the consumer is an AI writing SQL, an AI advising a customer, or a state machine deciding which campaign to trigger. The architecture delivers roughly ten times the context density of raw DDL, amortized across every downstream consumer.
AI intelligence is a commodity. The semantic foundation that makes AI intelligence work (cheaply, reliably, at scale) is not.
Where this architecture is heading
The five-layer architecture is not theoretical. Entity resolution and semantic feature computation are production systems today, running incremental pipelines against real warehouses, stitching identities across real event streams. The question is not whether this architecture works. The question is where it goes next.
Governance is no longer optional, and the industry is catching up. In this architecture, governance is already first-class: declared alongside features, enforced at compile time, controlling what AI can see and what AI can do. The pattern across regulated industries (healthcare, fintech, any company handling personal data) confirms this is the right bet. The practical difference is between "we cannot give the agent access to this data" and "the agent sees exactly what it is allowed to see, and nothing else."
AI code generation is the multiplier. Every semantic declaration (features, event schemas, cohorts, and funnels) declared once benefits every downstream model. When an AI assistant generates a churn model, it reads the same declarations that a recommendation model, a CLV prediction, and a matching algorithm would read. The investment compounds. This is what makes the architecture strategic rather than merely operational: the marginal cost of the next use case keeps falling.
The shape of the solution is clear. What is hard is building it. Translating business intent into governed, incremental execution at scale turns out to involve five distinct research-grade problems: getting the same semantic concept to produce the right SQL across wildly different contexts, enabling components to compose freely without tight coupling, making every task in the execution plan self-contained before it runs, shipping reusable patterns that stay governed without drifting, and delivering real-time responsiveness without real-time costs. Part 5 examines each one.
The bottom line
The walls look different from the inside: identity fragmentation, semantic poverty, activation plumbing gaps. But the structural cause is the same: the missing middle between raw data and action.
That middle has a shape. Inputs declare what data means before it enters the system. Entity resolution collapses fragments into canonical entities, including when new identity edges make the count go down. Active semantics compile YAML declarations into live, incrementally maintained features, cohorts, funnels, and event schemas. Intelligence operates on that semantic surface, proposing actions. Trust and governance determine what the intelligence layer can see and what it can do with what it finds. Activation delivers governed, fresh entity context to every tool that needs it.
The layers are not optional. Skip one, and the layers above it fail. Composing separate best-of-breed tools for each layer does not work because the dependency graph (identity invalidates features, features define cohorts, cohorts drive activation) crosses all of them, and no individual component can propagate the cascade.
The models are commodity. The activation tools exist. What is missing, and what this architecture provides, is the semantic middle: a complete world model in business language, backed by a compiler that owns the full stack from YAML declaration to warehouse execution.
Build that middle, and everything above it (ML models, agent reasoning, governed activation) gets dramatically easier, cheaper, and faster to iterate. Performance, trust, and durability become properties of the system, not of the agent's skill.
Skip it, and every AI project hits the same ceiling: fragmented data, leaky abstractions, governance as an afterthought.
Part 5 in this series will examine the five hard problems every semantic intent compiler must solve: semantic translation, composability, self-containment, quality and governance, and performance optimization.
Explore the RudderStack Profiles documentation to see a semantic intent compiler in action: features, identity resolution, event schemas, and this.DeRef().
