Infrastructure layer
CDK / CloudFormation defines the whole stack: VPC, EKS, S3, ECR, Cognito, ACM, and least-privilege, model-scoped roles.
This page is the deep dive behind our working demos—document research, voice intake, and web lead capture. It is written for technical buyers who want to see data flow, security controls, and deployment layers. Office owners evaluating fit should start on Builds; we walk architecture on the assessment call. CPA and HVAC demos stay live; the research stack is spun up on demand so it is not sitting hot when idle. Models for summaries, qualification, and retrieval are optional layers on reliable intake, storage, and handoffs—not autonomous agents running the business.
A security-conscious, cloud-native pipeline for uploading documents, embedding and indexing content with SWAG semantic profiles, and running structured research workflows with SWAG+CRAG retrieval-augmented generation. Orchestration runs on managed Kubernetes with Qdrant vector search, object storage, network policies, and model inference on Amazon Bedrock. SWAG reranks and filters candidates before CRAG grading (fewer grading tokens). The edge is served over HTTPS behind Cognito authentication on a private demo endpoint. Portable SWAG core is also available separately — see the SWAG research notes.
CDK / CloudFormation defines the whole stack: VPC, EKS, S3, ECR, Cognito, ACM, and least-privilege, model-scoped roles.
Showcase UI (streaming gateway), research agents, ingestion, vector store, cache.
HTTP NLB (active) or ALB HTTPS + Cognito (after ACM DNS validates). Network policies restrict internal traffic.
Amazon Bedrock (Claude for synthesis and grading, Titan embeddings), tracing, and optional web fallback.
Public HTTPS via ALB + Cognito on a private demo endpoint. Internal traffic restricted by NetworkPolicies.
flowchart TB
subgraph external["Outside AWS"]
User["Demo user"]
Trace["Tracing optional"]
Web["Web search optional"]
end
subgraph aws["AWS account"]
CDK["CDK / CloudFormation"]
SM["Secrets Manager"]
subgraph vpc["VPC"]
NAT["NAT Gateway"]
NLB["NLB HTTP"]
ALB["ALB HTTPS plus Cognito"]
subgraph eks["Managed Kubernetes"]
subgraph showcase["showcase"]
UI["Showcase UI SSE gateway"]
end
subgraph agents["agents"]
LG["Research agents"]
end
subgraph rag["rag"]
Ing["Ingestion API"]
Qdrant["Vector store"]
Redis["Cache"]
end
subgraph system["cluster add-ons"]
ALBC["Load balancer controller"]
EBS["Block storage CSI"]
end
Node["Worker nodes"]
end
S3["Object storage"]
Cognito["Cognito user pool"]
Budget["Model budget alerts"]
Bedrock["Bedrock Claude and Titan"]
end
end
User --> NLB
User -.->|after cert ready| ALB
ALB --> Cognito
Cognito --> ALB
NLB --> UI
ALB -.-> UI
UI -->|SSE events| LG
UI --> Ing
LG --> Qdrant
LG --> Ing
Ing -->|SWAG filter CRAG grade| Bedrock
LG --> Bedrock
LG -.-> Trace
LG -.-> Web
Ing --> S3
Ing --> Qdrant
Ing --> Bedrock
SM -.-> UI
SM -.-> LG
SM -.-> Ing
CDK --> vpc
CDK --> Cognito
CDK --> Budget
CDK --> SM
ALBC --> ALB
EBS --> Qdrant
NAT --> Bedrock
NAT --> Trace
Single vector index — embeddings and SWAG profile metadata in the same payload. Search widens the candidate pool, then runs SWAG rerank + noise filter on multi-candidate requests (strict defaults: one chunk per document, no backfill padding, chrome hard gate). Optional CRAG sends a small capped set to a fast grading model. Sibling expansion is off by default. Shared by search API, UI Search, and agent tools. Modes: baseline · swag · crag · swag+crag. Configurable per corpus — see SWAG article.
flowchart LR Q[Query] --> R[Vector retrieve] R --> P[Ensure SWAG profiles] P --> S[SWAG rerank and noise filter] S --> G[CRAG grader capped] G -->|relevant| F[Return filtered chunks] G -->|ambiguous| RW[Rewrite query] RW --> R G -->|irrelevant| W[Optional web fallback] W --> F F --> A[Researcher or UI]
The Search tab in the reference deployment defaults to Vector → SWAG with baseline compare. Scripted demo paths run frozen validation queries with the right topic filter — chrome trap, AP lane, cafeteria lane. CRAG modes are labeled optional; agents still use SWAG→CRAG for safety.
| Scripted path | Topic lane | What it proves |
|---|---|---|
| Chrome trap (RAG body) | Validation / chrome | SWAG promotes body over README chrome |
| Chunking quality | Validation / chrome | Same trap — substantive chunk at top-1 |
| AP · three-way match | Accounts payable | Domain lane + rerank on PO content |
| Cafeteria · food safety | Ops / food safety | Isolated ops corpus, not mixed noise |
| CRAG · cross-domain bait (optional) | All topics | Full stack may return empty on mixed-domain bait |
Same query through each pipeline with optional baseline compare. Lead demos with SWAG alone; switch to SWAG→CRAG when discussing agent safety.
| Mode | What it shows | Typical outcome on messy HTML |
|---|---|---|
| SWAG | Default demo. Rerank + noise filter | Body promoted; duplicates dropped — use lift cards |
| Baseline | Vector similarity only (naive RAG) | Chrome and nav chunks often at #1 |
| CRAG | Grader scores vector top-K (optional) | Some mis-ranked chunks still pass |
| SWAG → CRAG | SWAG clean → CRAG grade (agents; optional demo) | Fewer hits; empty when grader rejects |
Enable Compare against baseline to see purged vs kept chunks side by side. Showcase regression and the product eval harness (messy corpora, strong baselines, retrieval + answer gates) are how we keep the demo honest. Retrieval policy knobs live in ingestion config.
Each qrel defines corpus, question, expected retrieval (gold doc + traps), and expected answer. One command scores retrieval metrics and, with --generate, answer correctness + citation + hallucination rate against brutal thresholds. Honest fail is a feature — it separates demo regression from product proof.
| Corpus | Messiness | Example trap |
|---|---|---|
| retail-furniture | Deprecated sizing, duplicate policies | v1 sizing guide vs v2 |
| terraform-cloud | Version docs, acronyms | Terraform 1.2 legacy vs 1.5 |
| legal-contracts | Archived MSAs, cross-refs | MSA v1 $10k cap vs v3 |
| medical-admin | HIPAA/PHI/BAA | 2019 infection policy outdated |
| mixed-garbage | Contradictions, partial PDFs | Conflicting refund policies |
UI gateway streams agent progress. Researchers call ingestion SWAG+CRAG (not raw vector search); traces go to the optional tracing service.
sequenceDiagram
actor User
participant Edge as Edge HTTPS Cognito
participant UI as Showcase UI gateway
participant LG as Research agents
participant Ing as Ingestion API
participant Q as Vector store
participant BR as Bedrock
participant Web as Web search optional
participant Trace as Tracing optional
User->>Edge: HTTPS
Edge->>UI: Forward
User->>UI: Research topic
UI->>LG: Start streamed run
LG-->>UI: Run started
LG->>LG: Coordinator plan
LG-->>UI: Plan review interrupt
User->>UI: Approve plan
UI->>LG: Resume
Note over LG,Ing: researchers use SWAG then CRAG per sub-question
LG->>Ing: Search with SWAG then CRAG
Ing->>Q: Vector retrieve candidates
Q-->>Ing: Chunks plus SWAG metadata
Ing->>BR: SWAG rerank and CRAG grade capped
BR-->>Ing: Reranked graded chunks
alt weak RAG
Ing-->>LG: web fallback
LG->>Web: Web search
Web-->>LG: Web snippets
else good RAG
Ing-->>LG: Filtered chunks
end
LG->>BR: Synthesize findings
LG-->>UI: Critique review interrupt
User->>UI: Synthesize or more research
LG-->>UI: Report
LG-->>Trace: Traces
Uploads are size-capped and rate limited at the API gateway. Chunking uses structural markdown split (nav vs body). Indexing stores Titan vectors and heuristic SWAG profiles on each chunk in one pass.
sequenceDiagram actor User participant Edge as NLB or ALB Cognito participant UI as Showcase UI participant Ing as Ingestion participant S3 as S3 participant BR as Bedrock participant Q as Qdrant User->>Edge: HTTP or HTTPS Edge->>UI: Forward User->>UI: Upload file UI->>Ing: Ingest request Ing->>S3: Store raw Ing->>Ing: Chunk and classify nav or body Ing->>BR: Titan embeddings BR-->>Ing: Vectors Ing->>Ing: Heuristic SWAG chunk profiles Ing->>Q: Upsert vectors and SWAG payload Ing-->>UI: Done
| Control | Implementation |
|---|---|
| Edge auth | Cognito @ ALB (private demo endpoint) |
| TLS | ACM-managed TLS certificate |
| IAM | Least-privilege, model-scoped roles per workload — each service can call only what it needs |
| Secrets | AWS Secrets Manager + Kubernetes secrets; nothing hard-coded in images |
| Upload cap | Enforced on the UI gateway and ingestion service |
| Rate limits | Per-client limits on ingest and research endpoints |
| SSRF | URL ingest blocks private IPs, metadata, and bad redirects |
| Network | NetworkPolicies restrict internal traffic to required paths only |
| Spend | AWS Budget alerts on model usage |
| Layer | Provisions |
|---|---|
| Core infrastructure | VPC, EKS, S3, ECR, Cognito, ACM certificate, and least-privilege model-scoped roles |
| Cluster bootstrap | EBS CSI, ALB controller, external secrets, autoscaler, and storage classes |
| Application workloads | Vector store, cache, ingestion, research agents, showcase UI, and network policies |
| Edge access | HTTP or HTTPS + Cognito ingress depending on certificate status |
Reference lifecycle for demo and non-production environments—park when idle to control spend.
stateDiagram-v2 [*] --> Parked Parked --> Running: deploy stack Running --> Stopped: stop Stopped --> Running: start Running --> Parked: park Stopped --> Parked: park
| Mode | What runs | Relative cost |
|---|---|---|
| Parked | Object storage and images only | Minimal |
| Stopped | Control plane only — no nodes or load balancer | Reduced |
| Running | Full stack, on demand | Full (only while live) |
Inbound calls are handled by Amazon Connect, captured by a Node.js Lambda, stored in DynamoDB, and pushed to the team via SNS email alerts. Optional model-assisted summaries can be added where they help staff respond faster. A lean, managed-services footprint — VPC isolation added when a deployment calls for it. Provisioned with AWS CDK (CloudFormation).
PSTN / SIP inbound to a claimed DID, routed by an Amazon Connect contact flow.
Connect + Lambda + DynamoDB + SNS — pay-per-request throughout, with VPC isolation added when needed.
Bedrock summarization layered on top; staff alerts and durable records always land first.
Email alert on every lead, leads queryable in DynamoDB, and a CRM-webhook-ready path.
A claimed phone number routes into a Connect contact flow that invokes a single Lambda handler. The handler persists the lead, publishes a notification, and — only when enabled — asks Bedrock for a short summary. The whole stack is defined in CDK.
flowchart LR Caller["PSTN caller claimed DID"] --> Connect["Amazon Connect inbound contact flow"] Connect -->|invoke function| Lambda["AWS Lambda handler"] Lambda -->|store lead plus raw event| DDB["DynamoDB leads table"] Lambda -->|publish new lead alert| SNS["Amazon SNS notifications"] Lambda -.->|optional summary| BR["Amazon Bedrock"] SNS -->|email subscription| Ops["Operator or CRM inbox"] CDK["AWS CDK to CloudFormation"] --> Connect CDK --> Lambda CDK --> DDB CDK --> SNS
Every inbound call runs the same path. Persistence and the staff alert are guaranteed; the model summary is an optional step that never blocks the record or the notification.
sequenceDiagram
actor Caller
participant C as Amazon Connect
participant L as Lambda handler
participant D as DynamoDB
participant B as Bedrock optional
participant S as SNS
participant Ops as Staff inbox
Caller->>C: Inbound call on claimed DID
C->>C: Run inbound contact flow
C->>L: Invoke function with contact data
L->>D: PutItem lead plus raw event
opt summary enabled
L->>B: summarize
B-->>L: Short summary
end
L->>S: Publish new lead alert
S-->>Ops: Email notification
C-->>Caller: Disconnect
| Layer | Service | Configuration |
|---|---|---|
| Voice channel | PSTN / claimed DID | Phone number attached in Connect; standard inbound routing |
| Telephony + flow | Amazon Connect | Managed instance with an inbound contact flow; Contact Lens and flow logs |
| Compute | AWS Lambda | Single handler function; Node.js; short timeout |
| Storage | Amazon DynamoDB | On-demand table keyed by lead, indexed by contact; retain-on-delete |
| Notifications | Amazon SNS | Topic with an email subscription |
| Optional assist | Amazon Bedrock | Model-generated summary, only when enabled |
| IaC | AWS CDK → CloudFormation | Single voice intake stack |
| Control | Implementation |
|---|---|
| IAM | Least-privilege function role scoped to only the services it uses |
| Data | On-demand storage with retain-on-delete; keeps the structured lead and raw event |
| Observability | CloudWatch metrics, logs, and alarms for Lambda and Connect |
| IaC lifecycle | CloudFormation drift detection and change sets |
| Footprint | Lean managed-services footprint; VPC isolation and Lex or a knowledge base added as needs grow |
Website visitors submit a lead form to an HTTP API. Lambda validates the payload, qualifies the request (rules-based with optional model scoring), writes to DynamoDB, and sends a notification email through SES. Static frontend hosted separately (Amplify, S3, or CMS embed). Serverless throughout — no servers to patch. Provisioned with AWS SAM (CloudFormation).
An HTML form on a separately hosted frontend (Amplify, S3 + CloudFront, or existing CMS) POSTs JSON.
API Gateway HTTP API → Lambda → DynamoDB → SES. Pay-per-use, nothing to patch.
Rules-based scoring by default; optional Bedrock model scoring when it earns its place.
Instant email with score, grade, and summary; JSON response to the visitor; CRM-hook-ready payload.
A form POST hits an HTTP API that proxies to one Lambda. The function validates, optionally qualifies, persists, and notifies — then returns JSON to the visitor. The whole stack is a single SAM template.
flowchart LR Visitor["Website visitor HTML form"] -->|"POST JSON"| API["API Gateway HTTP API"] API --> Lambda["AWS Lambda processor"] Lambda -->|save lead| DDB["DynamoDB leads table"] Lambda -.->|optional scoring| BR["Amazon Bedrock"] Lambda -->|send email| SES["Amazon SES verified sender"] SES -->|score grade summary| Owner["Sales or owner inbox"] API -->|JSON response| Visitor SAM["AWS SAM to CloudFormation"] --> API SAM --> Lambda SAM --> DDB
Validation and persistence run on every submission; scoring is optional. The visitor gets a JSON response while the owner gets an email with the grade and summary.
sequenceDiagram
actor Visitor
participant API as API Gateway HTTP API
participant L as Lambda processor
participant B as Bedrock optional
participant D as DynamoDB
participant M as SES
participant Owner as Sales inbox
Visitor->>API: POST JSON lead
API->>L: Invoke proxy integration
L->>L: validate
opt scoring enabled
L->>B: qualify
B-->>L: score plus grade
end
L->>D: save lead
L->>M: send email
M-->>Owner: Lead email score grade summary
L-->>API: 200 JSON
API-->>Visitor: Response
| Layer | Service | Configuration |
|---|---|---|
| Web channel | Static frontend | HTML form; hosted on Amplify / S3 + CloudFront / existing CMS |
| Edge / API | API Gateway HTTP API | Single POST endpoint with CORS preflight; access logs to CloudWatch |
| Compute | AWS Lambda | Processor function; Python; short timeout |
| Storage | Amazon DynamoDB | On-demand table keyed by lead; encrypted at rest; point-in-time recovery |
| Notifications | Amazon SES | Verified sender; email to the owner with score, grade, and summary |
| Optional assist | Amazon Bedrock | Optional model scoring; rules-based fallback |
| IaC | AWS SAM → CloudFormation | Single SAM template |
| Control | Implementation |
|---|---|
| IAM | Least-privilege function role scoped to only the services it uses |
| Data | Encrypted at rest; point-in-time recovery; on-demand billing |
| CORS | Locked to your site's origin in production (open only in the sandbox demo) |
| Tracing | X-Ray tracing on Lambda; API and Lambda logs in CloudWatch |
| Hardening | Production fronts the API with WAF and adds CRM integration |
Best for teams drowning in PDFs, policies, and research requests: ingest documents, index for retrieval, and run guided research workflows with human-readable output.
Best for businesses that live on the phone: after-hours capture, routing by intent (appointment, sales, support, urgent), and immediate staff alerts with structured summaries.
Best for marketing sites and landing pages: structured lead intake, qualification (rules or optional model assist), durable storage, and email notifications without running servers.
These examples span serverless AWS patterns and Kubernetes-based CRAG/RAG pipelines. We apply the same delivery discipline on-prem, in hybrid setups, and when standing up new infrastructure—and we can walk through which deployment and model layers fit your environment on a call.
Ask for a live walkthrough, deployment checklist, or a diagram scoped to your environment and growth plans.