What to expect in month 1

How ContextBase works

Most enterprise AI tools today use retrieval-augmented generation (RAG), which returns probabilistic text summaries from indexed documents with no way to check correctness. This limits data operations, where imprecise answers produce wrong joins, miscounted records, and broken downstream systems.

ContextBase takes a fundamentally different approach. It combines the best of non-deterministic AI with the best of deterministic execution.

Non-deterministic: building meaning and crafting queries

ContextBase uses large language models to do what AI is genuinely good at: reading complex schemas, interpreting messy documentation, resolving ambiguity, and inferring meaning across dozens of systems that were never designed to talk to each other. When you ask a question, ContextBase uses that inferred meaning to craft a real SQL query against your actual data systems.

This first part is probabilistic. The LLM is interpreting your question, reasoning about your schema, and deciding how to structure the query. It may approach the same question differently each time you ask. That’s the nature of the AI layer, and it’s what makes natural language interaction possible.

Deterministic: the query runs the same way every time

The query ContextBase generates is real SQL. It runs against your real databases. And SQL is deterministic, executing the same way every time, unlike RAG.

You can see both layers: the reasoning that led to the query and the query itself. Full lineage, full visibility, no black box. Once you arrive at a query you’re satisfied with, it will run the same way every single time from that point forward. No drift, no reinterpretation, no fuzzy approximation. A validated query is a locked-in, repeatable operation.

What your team approves stays with the data

When someone validates a query, corrects a mapping, clarifies a business term, or builds a new pipeline, what they know becomes a proposal. Once a person approves it, it attaches to the tables it describes in the knowledge layer, and every later answer that reads them carries it. Answer checks shows the loop.

Scheduled scans keep the map of your systems current, and approved knowledge builds on that map.

Reliable from day 1 on your architecture

Once ContextBase connects to a data system, a first scan is complete within a few hours. At this point ContextBase is largely informed by the observable structure and patterns in your system: profiling, metadata, stored procedures, and so on. It often lacks an understanding of business-specific terminology, for example when your team uses “tier” to mean a very specific methodology.

On day 1, use ContextBase for:

Schema navigation: ContextBase knows every table, view, column, stored procedure, and relationship in your connected databases. Ask it what a table contains, what feeds into it, and what depends on it.
Stored procedure analysis: ContextBase parses SQL, T-SQL, PL/pgSQL, and PL/SQL. It explains what a stored procedure does in plain language, traces its data flow, and identifies its dependencies.
Data lineage: ContextBase can trace a data element from its sources to its destinations and reveal all actions taken upon that data.
Code repository analysis: ContextBase finds SQL embedded in application code, identifies ORM models, and traces how applications interact with databases.
Query generation: Ask a data question in plain language and ContextBase generates the SQL to answer it, against your actual schema, with your actual table and column names. Inspect it, run it, validate it.

Reliable by day 30 on your data

These capabilities improve as scans reach more of your connected systems and your team approves what it knows about them. This lets you go beyond understanding how the system works to reliably performing intensive data analysis with complex joins, transformations, and validations.

Business term resolution: Early on, you might need to say “we call that clm_alw_amt, and it means the allowed amount after the lesser-of rule.” Once a person approves that definition, ContextBase resolves the term across queries, explorations, and pipeline suggestions.
Cross-system lineage: On day 1, ContextBase knows each connected system individually. Over time, as scans accumulate and you confirm relationships, the cross-system lineage graph fills in: this Snowflake table is fed by this SSIS package, which reads from this SQL Server database.
Query accuracy: Approved join patterns and column mappings stay with their tables, so later queries start from what your team confirmed. Queries that needed guidance on Monday often run cleanly by Friday.
Documentation linking: As your team approves business terms, ContextBase gets better at matching technical asset names to the business language used in your Confluence pages, SharePoint docs, and Jira tickets. The bridge between “what the data is called” and “what the documentation calls it” strengthens over time.
Pipeline creation: Each pipeline you build adds its data flows, mapping patterns, and validation rules to ContextBase. The next pipeline is faster to create because there is more precedent to draw from.

Getting the most out of month 1

If you know it, be specific: “billing.fact_claims in the production SQL Server” beats “the claims table.”
Correct it when it’s wrong: “That’s not the right join key. We use member_id, not subscriber_id, for that relationship.” Once approved, a correction stays with the table.
Follow up within sessions: Context carries forward. After exploring a table, drill into specific columns, procedures, or relationships without re-specifying.
Read the query and its checks: Always look at the generated query and its checks. The query shows what ran; the checks show where the answer says more than the rows support.