What is a Decision Topic?

A Decision Topic is anything leadership wants Decision AI to keep watching - a KPI, a customer segment, a contract renewal window, a board question, or a specific risk. Each Decision Topic runs continuously against your Knowledge Graph and produces a Decision Brief whenever something material changes. In the DataBlueprint product UI, Decision Topics appear simply as 'Topics' in the left navigation.

What is a Decision Brief?

A Decision Brief is a board-ready summary produced when a Decision Topic refreshes. It includes the question, the finding, the supporting evidence (with row-level traceability to source systems), and a recommended next move with projected impact.

What is an AI credit?

Credits power DataBlueprint's Decision AI activities - asking questions, refreshing Decision Topics, generating Decision Briefs, and running risk scans across your Knowledge Graph. Consumption depends on the complexity of the request.

What is a Knowledge Graph?

A live, unified map of every entity in your business - customers, contracts, products, costs, people - and the relationships between them, built automatically from every system you connect.

How is DataBlueprint different from a BI tool like Tableau or Power BI?

BI tools show tables and dashboards and require a data team to model and maintain them. DataBlueprint understands business relationships across all your systems, answers strategic questions in plain language, and surfaces recommended actions with traceable evidence. BI tells you what happened; Decision AI tells you why and what to do.

Is DataBlueprint read-only?

Yes, by default. DataBlueprint connects to all source systems in read-only mode. Agent write-back to systems like HR, CRM, and PSA is opt-in per system on the Business tier and requires explicit per-action approval.

Where does AI inference run?

All AI inference runs on a private LLM powered by AWS Bedrock, inside your AWS environment. Prompts, completions, and query results are never sent to OpenAI, Anthropic public endpoints, Google, or any external model provider. AWS Bedrock contractually guarantees customer inputs and outputs are never used to train shared models.

Knowledge Graph vs Data Warehouse: What's the Real Difference?

A data warehouse stores rows. A Knowledge Graph stores meaning. Here is how DataBlueprint uses both — and why the graph is what makes Decision AI possible.

Most companies already have a data warehouse. Snowflake, BigQuery, Redshift, Postgres — somewhere, the rows live. So a fair question keeps coming up in DataBlueprint demos: if we already have a warehouse, why do we need a Knowledge Graph?

The short answer: a warehouse stores data. A Knowledge Graph stores relationships, definitions, and business meaning on top of that data. They are not competitors. They are layers.

What a data warehouse actually does

A warehouse is a high-performance store for rows and columns. It is brilliant at:

Holding billions of records cheaply
Running aggregate SQL fast
Powering BI dashboards

What it does not do is tell you what those rows mean. A column called cust_id in fct_invoices and a column called account_ref in crm_accounts may refer to the exact same customer — but the warehouse has no idea. A human analyst has to know that, write the join, and remember it next quarter.

What a Knowledge Graph adds

A Knowledge Graph is a model of your business expressed as entities (Customer, Invoice, Job, Technician, Contract) and relationships between them (a Customer has many Invoices; a Job was performed by a Technician; a Contract covers a set of Sites).

DataBlueprint builds this graph automatically from your existing systems through a read-only connection — we never write back to source data. The graph then becomes the substrate that a private LLM powered by AWS Bedrock reasons over when an executive asks a question.

The practical difference

Ask a warehouse: "Why did margin drop 4 points in the Northeast last month?"

The warehouse cannot answer that. It can only return rows you wrote SQL for.

Ask the same question to DataBlueprint: the Knowledge Graph already knows that margin = revenue − cost, that cost rolls up from labor + parts + travel, that labor connects to Technician utilization in your PSA system, and that the Northeast region is defined the same way in your ERP and your CRM. The private LLM walks those relationships, traces the change to its source, and returns a Decision Brief with the cause and a recommended next step.

That is the difference. The warehouse holds the answer somewhere. The graph knows where to look and what it means.

You need both

DataBlueprint sits on top of your warehouse. We do not replace it. We use it as one of many read-only sources, alongside your CRM, ERP, PSA, ticketing, and finance systems. The graph is the layer that turns scattered tables into a model of your business — the layer that makes a question like "which customers are about to churn and why" actually answerable.

Where to go next

If you are evaluating whether a Knowledge Graph belongs in your stack, the easiest test is to write down the five business questions your dashboards still cannot answer. Those are the questions a graph is built for.