Architecture Portfolio · 2026

PulseRAG: Grounding LLMs
in Live Enterprise Data

Siddharth Rao · Enterprise Architect · TOGAF Certified Design + Build phase · single-file portfolio piece

Architecture layers per query

Systems federated · CRM / ERP / Ticketing

Adaptive output formats

ADRs · TOGAF-documented

Abstract

Enterprise teams routinely ask questions whose answers are distributed across multiple systems of record — CRM pipelines, ERP fulfilment data, IT ticketing queues — with no single system capable of answering them. Traditional RAG addresses document retrieval; it does not address cross-system synthesis.

PulseRAG closes that gap with a natural-language query layer that classifies intent, decomposes a query into parallel sub-queries per system, federates across heterogeneous enterprise connectors, and renders the response in the format the answer demands — table, chart, card, or prose. The system runs on Google's own model family — Gemini 3.1 Flash-Lite for cheap, high-volume intent classification and Gemini 3 Flash for cross-system synthesis — with seeded mock connectors for demonstration and every architectural tradeoff documented as a formal ADR.

cross-system synthesis connector federation intent classification adaptive output rendering freshness policy TOGAF ADM gemini 3 flash

§1 Problem Statement

1.1 The joins that don't exist anywhere

Between 2022 and 2025, enterprise teams broadly adopted RAG to reduce LLM hallucination. The pattern is largely uniform: documents are chunked, embedded, and retrieved by similarity against an embedded query. This handles document-level knowledge well.

It does not handle operational questions. A Sales Director asking "which at-risk deals have fulfilment issues that could affect close?" needs an answer that lives in three systems simultaneously — CRM deal stage, ERP fulfilment status, and the ticketing queue for account friction. No vector store contains that join, and no single system of record can answer it alone.

The gap, precisely

This is not a retrieval problem — it's a federation problem. The answer exists, distributed across systems that were never designed to talk to each other. A human spends 30–45 minutes context-switching across three logins to assemble it manually. PulseRAG automates that federation.

Figure 1

The cross-system synthesis gap — why no single system of record can answer the question

This is the exact pattern OpenAI's Frontier platform and Strategy's Mosaic now market as a "semantic layer for the enterprise" — the gap validated, the framing evolved.

1.2 Where document RAG fails vs. where PulseRAG applies

Query type	Example	Document RAG	PulseRAG
Cross-system synthesis	"At-risk deals with fulfilment issues this quarter?"	Fails — no join	Core use case
Live operational status	"Open P1 tickets right now?"	Stale answer	Live connector
Inventory & fulfilment	"SKUs below reorder threshold today?"	No document exists	ERP connector
Pipeline health summary	"How is Q2 tracking against target by stage?"	Stale if indexed	CRM connector
Document lookup	"What is our refund policy?"	Handles correctly	Out of scope

The worked failure example

A document RAG system has no document that answers "which at-risk deals have fulfilment issues that could affect close?" The nearest indexed content might be a sales playbook — returned with high cosine similarity, factually correct, and completely wrong for the question. The generation layer produces a fluent, confident, and useless answer.

PulseRAG routes the same query to three connectors simultaneously — CRM for deal stage and risk flags, ERP for fulfilment status, Ticketing for open account friction — then joins the results and renders a ranked deal table, the format the answer actually demands.

§2 Pipeline Overview

A query passes through five layers between input and rendered answer. Query Intelligence determines which connectors are needed; Connector Federation queries them in parallel; the Freshness & Cache layer decides live-vs-cached per query type; Synthesis & Render merges results into the format the answer demands.

Figure 2

System context, 30,000ft — PulseRAG as the federation layer between user and enterprise systems

Figure 3

Five-layer architecture — responsibility and implementation per layer

1 · Application

NL query input

Adaptive output render

Source attribution

2 · Query Intelligence

Intent classification

Query planning

Sub-query generation

3 · Connector Federation

CRM · ERP · Ticketing

Parallel async fetch

Standard interface

4 · Freshness & Cache

TTL policy per type

Live bypass — high sensitivity

In-memory Map

5 · Synthesis & Render

Cross-system merge

Grounded response

Format selection

Query Intelligence runs on Gemini 3.1 Flash-Lite (cheap, fast, high-volume classification); Synthesis & Render runs on Gemini 3 Flash (stronger reasoning for the cross-system merge) — a deliberate cost/latency split across two Gemini tiers.

§3 Pipeline Components

3.1 Query planning & intent classification

Every incoming query passes through a structured Gemini 3.1 Flash-Lite prompt that returns which connectors are required, what output format the answer demands, and how sensitive the data is. No labelled training set is needed — classification is driven entirely by prompt structure, which keeps iteration fast during the design phase and keeps per-query cost near-zero.

Receive query

NL input

Classify intent

Gemini 3.1 Flash-Lite

Plan sub-queries

per connector

Fetch connectors

Promise.all()

Freshness check

TTL routing

Synthesise

Gemini 3 Flash

Render output

table/chart/card/prose

3.2 Connector federation model

CRM, ERP, and Ticketing connectors implement a standard interface — a query-in, JSON-out contract with a fixed schema shape modelled on Salesforce, SAP, and Jira respectively. Sub-queries fan out in parallel via Promise.all(); the connector interface is designed to be real-API-swappable without touching the intelligence or synthesis layers.

In production, that swap point is Apigee as the API gateway in front of each system of record, with Application Integration handling the connection and transformation logic per system — Google's own answer to exactly the "systems that were never designed to talk to each other" problem this project is built around.

Figure 4

Connector interface and parallel execution — a standard interface enabling heterogeneous system federation

3.3 Freshness policy decision tree

Not every query needs a live fetch. High-sensitivity queries — deal risk, ticket SLA breach, inventory thresholds — bypass cache entirely. Lower-sensitivity aggregate queries, like pipeline health by stage, are served from a 5-minute TTL cache to reduce redundant connector load.

Query type	Sensitivity	Policy
At-risk deals · fulfilment risk	High	Bypass cache — always live
Inventory reorder threshold	High	Bypass cache — always live
Open P1 tickets · SLA risk	High	Bypass cache — always live
Pipeline health by stage	Medium	5-minute TTL

3.4 Adaptive output format selection

The synthesis prompt returns a format signal alongside the answer content — table, chart, cards, or prose — which drives the render layer directly. This separates content generation from presentation: the LLM decides what shape the answer needs; the renderer just executes it.

Figure 5

Intent → output format mapping — how query intent determines the rendering strategy

3.5 Stack and component decisions

Every component choice below is a deliberate, documented tradeoff for a zero-infrastructure portfolio build — see §6 for the full ADR set.

§4 Pipeline Simulator

Run the pipeline across four enterprise query scenarios end-to-end. Each run shows intent classification, connector activation, freshness routing, synthesis, and adaptive output rendering with realistic timing. This simulator uses pre-scripted scenario responses and seeded JSON connector data — no external API calls are made.

Design phase · simulator caveat

In the build phase, Gemini (3.1 Flash-Lite for classification, 3 Flash for synthesis) replaces the scripted intent classifier and synthesiser, enabling arbitrary natural-language queries. Production deployment would replace mock connectors with live Salesforce, SAP, and Jira integrations behind Apigee, fronted by a Cloud Run proxy.

pulserag · pipeline simulator

idle

Scenario

receive query

NL input parsed

—

classify intent

Gemini 3.1 Flash-Lite

—

plan sub-queries

per connector

—

fetch connectors

parallel · Promise.all()

—

freshness check

TTL routing

—

synthesise

Gemini 3 Flash

—

render output

adaptive format

—

// select a scenario and run simulation

Rendered output

Run the simulation to see the adaptive-rendered response.

Execution steps

Classify & plan. Gemini 3.1 Flash-Lite returns required connectors, output format, and sensitivity tier from the raw query text.

query intelligence layer

Federate. Sub-queries fan out to the relevant connectors in parallel; seeded JSON stands in for live Salesforce/SAP/Jira responses.

connector federation layer

Route on freshness. High-sensitivity queries bypass cache; medium-sensitivity queries check the 5-minute TTL store first.

freshness & cache layer

Synthesise & render. Connector results are merged into one grounded answer, with source attribution and the format the question actually needs.

synthesis & render layer

§5 Tech Stack

Inference

Gemini 3 Flash + Flash-Lite

Two-tier model split: Flash-Lite handles high-volume intent classification at minimal cost, Flash handles cross-system synthesis where reasoning quality matters more.

Connectors

Seeded JSON

Salesforce / SAP / Jira-schema mocks. Same field names, same relationships, same response shape as real APIs — swap-in ready.

Cache

In-memory Map + TTL

Zero infrastructure. TTL policy is a first-class routing concern, not an afterthought — see §3.3.

Frontend

Static HTML · vanilla JS

Zero build step, Firebase Hosting compatible. No bundler, no framework dependency for the design phase.

Hosting

Firebase Hosting

Free Spark-tier CDN hosting, zero config, global edge caching. Single index.html deploy via the Firebase CLI.

Classification

Structured Gemini prompt

No labelled dataset required — intent, format, and sensitivity are all extracted from one structured Gemini 3.1 Flash-Lite prompt.

§6 Architecture Decision Records

Every significant architectural choice is formally documented following TOGAF principles — design precedes build, decisions are traceable.

ADR-001

Gemini 3 Flash + Flash-Lite as a two-tier inference layer

Accepted

Context

Intent classification and response synthesis have very different cost/quality requirements — classification runs on every query and needs to stay cheap; synthesis is where reasoning quality is actually visible to the user.

Decision

Route classification to gemini-3.1-flash-lite and synthesis to gemini-3-flash, both via the Gemini API. Note: Google's API terms require EEA/Switzerland/UK developers to use the paid tier rather than the free AI Studio tier available elsewhere — this build runs on paid, pay-as-you-go Gemini at demo-scale cost (well under $1 for the full simulator's worth of calls).

Consequence

Two model calls to reason about instead of one, but each stage runs the right-sized model for its job. Production would move both calls behind Vertex AI for SLA guarantees, quota management, and regional data residency controls.

ADR-002

Browser-side API calls vs. backend proxy

Accepted

Context

A zero-infrastructure build has no server to hold secrets.

Decision

Call the Gemini API directly from the browser for the build phase.

Consequence

Exposes the API key in client code — acceptable for a portfolio demo, not for production. A Cloud Run service in front of Vertex AI is the correct pattern at that point: it holds the credentials, enforces per-user quota, and scales to zero between requests.

ADR-003

Mock connectors over real enterprise integrations

Accepted

Context

Real Salesforce/SAP/Jira credentials aren't available for a public demo.

Decision

Connectors return seeded JSON with realistic, real-API-matching schemas.

Consequence

No live data, but the connector interface is designed to be swapped for real APIs without touching the intelligence or synthesis layers.

ADR-004

Scenario-scoped query matching for design phase

Accepted · design phase only

Context

The design-phase simulator must run without Gemini API calls, demonstrating the full pipeline visually at zero cost and zero latency variance.

Decision

Pre-script four scenario responses with keyword-triggered routing.

Consequence

Design simulator does not handle arbitrary queries; out-of-scope queries return a graceful fallback. Fully replaced by live Gemini 3.1 Flash-Lite / Gemini 3 Flash calls in the build phase.

ADR-005

Adaptive output format selection by intent

Accepted

Context

Different questions demand different answer shapes — a ranked list, a trend, a status snapshot.

Decision

The synthesis prompt returns an explicit format signal that drives the render layer.

Consequence

Presentation logic stays fully decoupled from content generation, at the cost of one extra field the LLM must get right.

ADR-006

In-memory TTL cache over Memorystore

Accepted · demo scope

Context

A single-user browser demo doesn't need distributed cache invalidation.

Decision

Use a plain in-memory Map keyed by query type with a TTL policy per §3.3.

Consequence

Cache doesn't survive a page reload and isn't shared across users — acceptable at demo scope; Memorystore (Google Cloud's managed Redis-compatible service) is the documented production path.

ADR-007

Static single-file HTML delivery

Accepted

Context

A portfolio artifact needs to be trivially cloned, opened, and reviewed with zero setup.

Decision

All CSS, JS, and simulator logic self-contained in one index.html. No bundler, no framework, no build step.

Consequence

Larger single file and no component reuse across pages — an explicit tradeoff for reviewer friction over engineering purity at this scope.

ADR-008

Freshness policy as a query-type routing layer

Accepted

Context

Not every query needs a live round-trip to a connector; some can tolerate a short-lived cache.

Decision

Route each query type to either a live bypass or a 5-minute TTL cache based on declared sensitivity.

Consequence

Reduces redundant connector load on aggregate queries while keeping high-stakes answers always current.

§7 MVP Scope & Production Path

This is a portfolio-grade MVP. The gap to production is well-defined and documented openly — a deliberate engineering decision, not a limitation to hide.

Implemented — design phase

Five-layer architecture diagram & portfolio pagestatic, no build step

Four-scenario pipeline simulatorpre-scripted, keyword-routed

Adaptive output renderertable · chart · cards · prose

8 formal ADRsTOGAF ADM discipline

Deferred to production

Live Salesforce / SAP / Jira via OAuthreplaces seeded JSON

Cloud Run backend proxyreplaces browser-side Gemini calls

Memorystore distributed cachereplaces in-memory TTL Map

Multi-tenant auth & audit loggingreplaces single-user demo

MVP	Production
Gemini API · direct, paid tier	Vertex AI Gemini with SLA, quota management, VPC-SC
Mock JSON connectors	Live Salesforce, SAP, Jira via Apigee + Application Integration
Browser-side API calls	Cloud Run backend proxy
In-memory TTL cache	Memorystore with distributed invalidation
Static HTML	Angular application with component separation, deployed on Firebase Hosting
Single-user demo	Multi-tenant with Identity Platform auth, Cloud Audit Logs, IAM access control

§8 Documented Tradeoffs

Every limitation below is surfaced deliberately, with a clear statement of what production would require.

LLM inference — Gemini paid tier, by necessity

Gemini 3.1 Flash-Lite and Gemini 3 Flash handle classification and synthesis respectively. Google's terms require EEA/Switzerland/UK developers onto the paid Gemini API tier rather than the free AI Studio tier — this is stated plainly rather than glossed over, and demo-scale cost is negligible. Production would move both calls behind Vertex AI for SLA guarantees and quota management.

Mock connectors

No live credentials required. Connectors return seeded JSON with realistic schemas — the interface is designed to be swappable for Apigee-fronted live connections without touching the intelligence or synthesis layers.

Browser-side API calls

Gemini is called directly from the browser, exposing the API key in client code. Acceptable for a portfolio demo, not for production — a Cloud Run proxy in front of Vertex AI is the correct pattern.

Design vs. build phases

The portfolio page (design phase) uses pre-scripted scenario responses and no external calls. The build phase wires Gemini for real intent classification and arbitrary query handling. Both live in the same repository.