Siva Kasina

SQL & BI Developer

Turning data into insights and value

About Me

Siva Kasina portrait placeholder

Hello! I'm Siva Kasina, a passionate SQL Database Administrator and Business Intelligence developer with experience in designing, developing and maintaining data‑driven solutions that empower organizations to make informed decisions. I specialize in building robust data architectures, optimizing database performance, and crafting insightful dashboards that tell compelling stories through data.

With a strong foundation in MS SQL Server, SSIS, SSRS and Power BI, I enjoy transforming complex datasets into actionable insights. I'm continually exploring new tools and methodologies to enhance data analytics and drive business growth.

Experience

SQL Database Administrator & BI Developer

Concur Technologies (SAP) – 2018 – Present

Database Analyst

Tech‑Intelleon Digital Solutions – 2015 – 2018

Junior SQL Developer

Global IT Solutions – 2013 – 2015

Skills

SQL Server

Expert in database design, administration, and performance tuning.

SSIS/SSRS

Experienced in ETL development and report creation.

Power BI

Proficient in building interactive dashboards and data visualizations.

Data Warehousing

Skilled in designing and implementing star/snowflake schemas.

Azure Data Services

Knowledge of Azure SQL Database, Synapse Analytics, and Data Factory.

Python

Experience in data analysis and scripting for automation.

Projects

Project 1

Enterprise Data Warehouse

Designed and implemented a scalable data warehouse integrating data from multiple sources, enabling company‑wide analytics and reporting.

Project 2

Sales Analytics Dashboard

Developed Power BI dashboards that provided real‑time insights into sales performance, customer trends, and revenue forecasts.

Project 3

ETL Automation Suite

Created a suite of SSIS packages to automate data extraction, transformation, and loading processes, reducing manual workloads.

Meridian — Trust-Aware Confluence AI Agent

An enterprise RAG and MCP agent that finds authoritative documentation, detects conflicting instructions, and generates grounded answers with live citations.

Meridian combines semantic retrieval with explicit documentation governance. It synchronizes governed pages from Confluence Cloud, generates embeddings with Amazon Titan, stores them in PostgreSQL with pgvector, and produces grounded answers using Llama 3.3 through AWS Bedrock. A custom MCP server exposes knowledge-search, grounded-answer, page-reading, and conflict-detection tools to the agent.

Meridian Financial Group and all platform content referenced in this project are fictional. The project contains no employer or client data.

View on GitHub View Technology Stack
Product view

Grounded answer with live citations

Illustrative UI — final answer panel

Does the Mosaic reporting team have read-only access to the trading ledger?

According to page-01, the MOSAIC_UI_VIEWER role grants read-only access to account views, transaction history, and case notes, but it does not specifically mention the trading ledger. Refer to page-03 for the full role catalog.

Cited pages: page-01 page-03 page-09
Why it matters

The problem

Enterprise Confluence spaces often contain duplicate procedures, old guides, draft documentation, FAQs, audit reports, and inconsistent terminology. Traditional keyword search returns several pages, while basic vector search ranks documents by semantic similarity without determining whether those documents are authoritative. That creates a serious problem: the most relevant-looking page may contain outdated instructions.

The solution

I built Meridian, a trust-aware Confluence AI agent that separates relevance from authority. The agent retrieves semantically related documentation, then applies an explainable governance policy based on document status, authority, type, freshness, and supersession relationships. Canonical procedures are promoted, while stale, draft, under-review, and superseded pages remain visible as clearly identified warnings. The final answer is generated only from the recommended evidence and includes citations to the original Confluence pages.

System design

Architecture

The ingestion pipeline synchronizes pages from Confluence Cloud, maps governance labels into retrieval metadata, creates heading-aware chunks, generates Titan embeddings, and stores the results in PostgreSQL with pgvector. At query time, the React interface calls FastAPI, which drives a Bedrock tool-calling agent against a custom MCP server. The trust-aware RAG pipeline reranks retrieved evidence and splits it into recommended and conflicting branches before Llama 3.3 generates a grounded, cited answer.

INGESTION PIPELINE QUERY PATH Confluence Cloud Incremental Synchronization Governance-Label Mapping Heading-Aware Chunking Titan Embeddings V2 PostgreSQL / pgvector Portfolio User React Interface FastAPI Bedrock Tool-Calling Agent Custom MCP Server Trust-Aware RAG (governance reranking) Recommended Evidence Conflicting Evidence pgvector + Llama 3.3 (grounded answer)
Pipeline stage Recommended evidence Conflicting / stale evidence
Agent behavior

Tool-calling agent activity

Illustrative UI — MCP tool-call timeline
  • 1
    Ran grounded RAG pipeline (answer_question)
    2,056 ms
  • 2
    Checked for document conflicts (check_document_conflicts)
    580 ms
What it does

Key capabilities

✓Live Confluence Cloud REST synchronization
✓Governance-aware document ranking
✓Heading-aware chunking
✓Titan Text Embeddings V2
✓PostgreSQL and pgvector
✓Explainable scoring reasons
✓Low-confidence rejection
✓Llama 3.3 grounded generation
✓Custom MCP server and tool-calling agent
✓FastAPI and React interface
✓Incremental refresh and safe pruning
✓Dockerized local deployment
✓66 automated tests
Design principle

Relevance is not the same as trust

For one access question, a superseded Confluence guide received a raw semantic score of 0.7594, while the canonical procedure received only 0.5691. A basic vector-search system would likely recommend the outdated guide.

Meridian applied its governance policy and raised the canonical procedure to a final score of 0.8191, while reducing the superseded guide to 0.5194 and displaying it as a warning.

Canonical — raw semantic
0.5691
Canonical — after reranking
0.8191
Superseded — raw semantic
0.7594
Superseded — after reranking
0.5194
Illustrative UI — conflict warning panel
!
Review before relying on this answer
  • page-22: document status is under review
  • page-02: page is superseded
  • page-02: page may be stale
By the numbers

Measurable results

25
Adversarial evaluation pages
152
Frozen-corpus evaluation chunks
14
Live Confluence chunks
1,024
Embedding dimensions
66
Automated tests
14/14
Unchanged embeddings skipped on refresh
0.2–0.3s
Typical retrieval latency
3–10s
Typical complete answer time
How it was built

Engineering decisions

Governance metadata as a first-class signal

Status, authority, document type, freshness, and supersession relationships are modeled explicitly, so ranking decisions are explainable rather than a black box similarity score.

Heading-aware chunking

Chunks are split along Markdown heading boundaries with controlled overlap, preserving page title and section path for stable, human-readable citations.

Low-confidence rejection before generation

A raw semantic-similarity gate (0.30) runs before any Bedrock call. Below the threshold, the agent returns an insufficient-evidence result instead of guessing, avoiding unnecessary generation cost.

Content fingerprinting for incremental refresh

Each chunk is fingerprinted so unchanged content is never re-embedded. A no-change refresh across all 14 live chunks skipped every embedding call.

Shared knowledge service across REST and MCP

FastAPI and the custom MCP server both call the same underlying knowledge service, so retrieval, reranking, and generation logic is implemented once.

Bounded, observable agent loop

The tool-calling agent enforces step and token limits and de-duplicates repeated tool calls, with every step, score, and timing surfaced back to the UI.

Stack

Technology stack

Python FastAPI React MCP AWS Bedrock Llama 3.3 70B Amazon Titan Text Embeddings V2 PostgreSQL pgvector Docker Confluence Cloud REST API boto3 psycopg
Operations

Security and production deployment

The portfolio environment runs locally in Docker so it doesn't leave cloud infrastructure idling between demos. The container topology mirrors a production-shaped deployment target:

Local portfolio environment

  • Dockerized FastAPI backend
  • Dockerized PostgreSQL with pgvector
  • Local MCP server over stdio
  • No idle cloud spend between demos

Production target

  • ECS Fargate for the API and agent
  • RDS PostgreSQL with pgvector
  • IAM task roles for least-privilege Bedrock access
  • Secrets Manager for credentials
  • HTTPS at the load balancer
  • CloudWatch for logs and metrics

Full implementation, architecture docs, evaluation corpus, Docker configuration, and automated tests are on GitHub.

View Meridian on GitHub

Contact