Turning lending documents into an AI-powered data asset
How a specialty healthcare-practice lender turned the unstructured documents
it already receives — practice-sale prospectuses, credit memos, financials —
into queryable intelligence using Snowflake-native AI, plus a reusable
framework so the next document type follows the same path.
My role: data & AI architect and hands-on builder. Over a
multi-month engagement I designed and built the applied-AI stack, the
knowledge-discovery framework, the document knowledge base, and the
productization strategy — and ran the AI-native workflow used to build it.
live AI capabilities (agent, search, semantic views, app)
67
documents run through an AI discovery pipeline (61 analyzed)
460→~25
raw source terms normalized to canonical concepts
5
data-product opportunities assessed against business needs
The through-line. Every loan the lender makes brings in unstructured
documents — practice-sale prospectuses, credit memos, financials. This work
turned those documents into queryable intelligence using Snowflake-native
AI, and codified the how into a reusable framework so the next document
type can follow the same path. The engagement connected hands-on delivery
with architecture and a repeatable discovery method.
Applied AI — from documents to governed intelligence
Delivered capabilities and the business questions they support.
Structured credit-memo analysis
The credit-memo agent combines search with structured extraction to surface borrower profiles, loan terms and risk measures for human review.
enabled by the credit-memo agent + AI_EXTRACT extraction schema
Consistent meaning across documents
Discovery across 12+ broker formats produced a controlled vocabulary and canonical extraction schema for practice economics, with the domain knowledge captured in YAML.
enabled by the Knowledge Discovery Framework + controlled vocabulary
Governed search & analytics
A Cortex Search service, governed semantic views and an internal documentation app make document knowledge accessible through defined interfaces in the analytics account.
enabled by Cortex Search + semantic views (Cortex Analyst)
Reusable discovery & delivery patterns
The framework, schema patterns and AI-assisted workflow provide a starting point for the next corpus, with model comparison and cost monitoring built into the method.
enabled by the 4-layer / 5-phase framework + dual-agent model
01 Applied AI — built and running
Four Snowflake-native AI capabilities deployed and callable in the analytics account.
Credit Memo Analyst agent LIVE
A Cortex Agent that extracts and interprets commercial-lending credit memos in natural language — borrower profiles, loan structure, risk ratings, collateral, DSCR/LTV, repayment sources. Orchestrates two tools: semantic search + a structured extraction function.
Cortex Agent · orchestration auto · 60s / 16k-token budget
search tool → credit-memo Cortex Search service
extract tool → EXTRACT_CREDIT_DATA UDF on the compute warehouse
Cortex Search service LIVE
A managed retrieval index over source documents — the backbone of document Q&A and the agent's search tool. Chunked + embedded narrative content, queried semantically.
service: READ_CREDIT_MEMO · 39 docs indexed
title column: RELATIVE_PATH · max 10 results
Semantic views (Cortex Analyst) LIVE
Five governed text-to-SQL semantic views powering self-service analytics without exposing raw tables. One is AI-extended for provider-compensation benchmarking.
A Streamlit-in-Snowflake app surfacing the benchmark data dictionary, specialty reference, and semantic-view documentation to internal users — a persona-specific serving surface.
Streamlit-in-Snowflake · internal serving surface
AI functions in the toolbox:AI_COMPLETEAI_EXTRACTAI_PARSE_DOCUMENTAI_CLASSIFY — used across discovery, extraction, and classification.
02 The Knowledge Discovery Framework
A reusable 4-layer, 5-phase methodology for turning unstructured documents into a queryable knowledge base. Developed and validated on the prospectus corpus, with discovery, model evaluation and canonical schemas guiding adaptation to another document type.
Four layers — document → decision
1
Document Ingestion & Classification
Stage, deduplicate by content, classify document type, identify the producer/template (broker ID), route by size tier.
Core principle: discovery before extraction. Let AI tell you what's in the
documents before designing the schema. Run zero-shot discovery, validate the
ontology across the corpus, then design the canonical schema. YAML is
the source of truth; HTML reports and database tables are downstream renders.
03 The document knowledge base
Document discovery and normalization for practice economics. Discovery and analysis used approximately $25 in AI inference.
99 → 67
files ingested → unique after dedup (~32% duplicates)
61
unique docs analyzed via AI_COMPLETE
12+
broker firms / dialects profiled
6
knowledge domains, consistent across all brokers
The core technical challenge: normalization
Every broker names the same metric differently — asking_price alone
has 7 variants; revenue has 20+. 460 raw financial term keys collapse to ~25
canonical concepts. There's no industry standard, so normalization is handled
at ingestion via a dual approach: AI_EXTRACT against a fixed canonical
schema (primary), plus a controlled-vocabulary mapping table (audit trail + edge
cases). Knowing that four differently-named price fields all mean the same thing
is domain knowledge that took four phases of AI discovery to build — and it's
encoded in YAML, not people's heads.
What discovery surfaced
Insight
Detail
Design implication
3 size tiers
83% of docs work with any model; 17% need a larger-context model or splitting (page/token limits)
Ingestion needs a size router, not one model path
Concept > section extraction
98% have financial data but only 89% have a "Financials" section
Ask "find the asking price," never "find the Pricing section"
Uneven coverage is real
Universal fields 85%+, common 40–85%, sparse <40%
Distinguish "not found" from "not applicable"; design products on Tier-1 fields
Dedup at ingestion
32 duplicate files removed from 99 ingested (~32%)
Content hash + file size, never filename alone
Mixed document types
76% prospectuses, 6% valuations, plus out-of-domain docs
Classify first, route to corpus-specific extraction
A model comparison (Claude vs Gemini) was captured to a results table to choose
the right model on quality × cost; the discovery corpus and source PDFs live in
a directory-enabled document stage feeding the pipeline.
04 Connecting architecture to business value
The engagement included an assessment of five data-product opportunities, mapped to business questions and user needs. The architecture work connects reusable capabilities to decisions people need to make.
Business need
Architecture response
Understand document content
Search and structured extraction make source information available for review.
Compare consistently
Canonical concepts and semantic views give equivalent terms a shared meaning.
Support different users
Persona-specific interfaces connect governed data to the questions each user asks.
Evaluate delivery value
Discovery evidence and cost analysis inform architecture and prioritization.
The consulting pattern: establish the business question,
test it against the available evidence, build the governed data and AI capabilities,
and leave the team a method it can repeat as the corpus grows.
05 The AI-native build model
How the work itself was built — a two-agent operating model that pairs a general-purpose driver with a platform specialist.
Claude Code — the driver
General development, file editing, refactoring, orchestration, git, and all the HTML/Python/SQL tooling. Holds the guardrails and drives the reasoning.
Cortex Code — the platform specialist
50+ Snowflake-native skills (data-quality, lineage, cost-intelligence, agent, semantic-view, ML). Invoked by shelling out — direct subcommands when the action is known, prompted skills when reasoning is needed.
Delegation is shell-out. Direct subcommands for known actions (no extra LLM call); prompted invocations to let the specialist's model drive a skill.
Shared guardrails. Both agents read one guardrails file — read-only default, prod protection, per-statement confirmation for DDL/DML.
Stateless bridging. A handoff log carries last-action / next-action / open-questions between agents and sessions.
Isolation. One git worktree per parallel stream so the two agents don't collide.
06 Cost & operations intelligence
Running AI in an account means watching what it costs. The work included a forensic cost analysis and reusable monitoring.
Cost analysis — a 14-day forensic reconstruction of AI/Cortex usage that identified the delegation loop between the two agents as the primary cost driver (74% of peak-day CLI spend), then tuned it.
Reusable monitoring — a set of ACCOUNT_USAGE queries plus a daily-email variant for ongoing cost visibility.
Team best-practices guide — how to keep the AI-native workflow efficient.
Economics — discovery + analysis ran ~$25 in AI inference. Model comparison and usage analysis provide a basis for estimating another corpus; inference spend is one part of delivery cost.
07 What this demonstrates
Capabilities exercised end-to-end across the engagement.
Capability
Evidence
Applied GenAI in a live account
Cortex Agent + Search + Analyst + Streamlit, all deployed and callable