Files
talk-to-data-case-study/linkedin_post.md
@gabriel.pereira 9e9ae249bc docs: add talk-to-data case study
Add anonymized architecture, governance examples, diagrams, and interview materials.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-09-11 10:36:16 -03:00

44 lines
2.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# LinkedIn post draft
Sales teams should not need an email chain to answer a routine quotation question.
In a proof of concept, I designed a governance-first semantic analytics flow for quotation data:
**SAP → Snowflake → dbt → Semantic Views → Cortex → Chatbot**
The business problem was simple: more than 30 salespeople could need help validating a quote, discount, or product classification. A question that looked small could take 530 minutes because the answer depended on manual lookup and internal communication.
The solution was not “put an LLM on top of raw tables.”
I first created a semantic contract:
- curated quotation dimensions and facts;
- business-friendly synonyms for natural-language questions;
- centralized discount calculations;
- explicit policy-exception flags;
- lineage from source data to the consumer-facing model.
Then Cortex applied the controls around that contract:
- data freshness warning for the daily batch;
- role-based access;
- protection of sensitive information;
- escalation when a discount exceeded policy;
- audit logging for queries and decisions.
The semantic model was consumed in two ways:
1. Snowflake's interface for analytical exploration.
2. An internal chatbot workspace for direct questions, with prompt engineering to refine the response experience.
The estimated user outcome was reducing routine quote research from 530 minutes to less than one minute. That is an estimate based on the existing human workflow, not a production benchmark—and that distinction matters.
The main lesson: **governance belongs in the data and semantic layers, not only in the prompt.**
The POC also created a reusable delivery pattern for future use cases: define the business contract, expose only the right data, add guardrails, then choose the lightest useful interface.
I documented the anonymized architecture, decisions, and lessons learned here:
[GitHub repository link]
#DataArchitecture #Snowflake #dbt #DataGovernance #EnterpriseAI #TechnicalDelivery