I have spent much of my professional life between business, data and enterprise technology.

One problem keeps returning: producing an answer is often easier than establishing what that answer actually means.

AI makes producing answers dramatically faster. But before we AI, we need to understand which data is relevant, what it means, which rules apply and who has the authority to decide.

That thought became the name of my project: before-we-ai.

It starts with a specific business question and asks:

What must be true for this answer to deserve trust?

The system traces the answer back to its sources and assumptions, tests what can be verified and makes visible what still requires a business decision.

A plausible answer is not necessarily a reliable one

Imagine a shipbuilder asking:

What will it cost to build vessel S42?

The available sources contain a bill of materials, purchase prices, labour hours and overhead rates. AI can combine them and calculate a credible total.

But which design revision applies? Does “cost” mean expected or actual cost? Is the purchase price the approved costing basis? Are labour hours recorded per vessel or for a production batch? Which overhead rule is current?

These are not technical details around the answer. They determine what the answer represents.

A calculation can therefore be correct and still answer the wrong question.

From data discovery to answer readiness

The project began as an experiment in understanding unfamiliar business data.

Modern AI can inspect tables, follow spreadsheet formulas and propose relationships remarkably quickly. I wanted to explore how far this could reduce the effort required to understand a new data landscape.

But finding a field called Purchase_Price does not establish that it is the price the organisation intends to use for expected costing. Reproducing an existing workbook does not prove that the workbook still follows the approved policy.

That changed the direction of the project.

Instead of asking whether AI can understand the data, I began asking:

What must be true for this particular answer to deserve trust?

This moves the focus from broad “AI readiness” to the readiness of one intended answer.

The same data may be adequate for exploration and insufficient for a financial decision. Readiness depends on the intended use and what could happen if the answer is wrong.

What the draft product looks like

The first version is deliberately simple.

A user supplies files or database extracts, asks a business question and clarifies the intended result. The system inspects the sources, establishes what a reliable answer would require and presents a readiness assessment.

The user should not have to design a semantic model or translate the question into technical language.

The system asks only the focused questions that the available sources cannot resolve—for example, which BOM revision is approved or whether labour hours apply per vessel or per batch.

Later, once the answer is sufficiently supported, the product can also execute the final calculation.

But the calculated number is not the core product.

The readiness decision is.

How it works

It begins with a normal business question:

What will it cost to build vessel S42?

Before calculating anything, the system clarifies what the requested answer should mean. Is this expected or actual cost? Should it use the currently approved design? Should the result include overhead?

It then works backwards from that clarified question and establishes what a reliable answer would require.

For vessel costing, it needs to know which design applies, which material prices are valid and how labour and overhead should be treated.

Some of this can come from established domain knowledge. General costing principles provide a starting point and help the system recognise what it should look for.

More knowledge is discovered in the supplied sources. The system can follow formulas, identify relationships and reconstruct how an existing workbook calculates its result.

But observation is not the same as approval.

The fact that a workbook uses Purchase_Price shows how that workbook currently works. It does not establish that Purchase_Price is the company’s approved basis for expected costing.

Where the sources cannot establish business intent, the system asks a focused question or looks for an authoritative document.

The result is a growing body of validated knowledge about how this type of answer should be produced in this organisation. Each piece retains its origin, scope and validation status.

The system then applies that knowledge to the current sources, tests the important dependencies and determines whether the answer is ready.

In simple terms:

Ask → Clarify → Establish what a reliable answer requires → Validate the sources → Fill important knowledge gaps → Assess readiness → Answer

The system does not start from zero each time. Confirmed knowledge can be reused for later questions when its scope still applies.

This is where the longer-term value begins to emerge: each assessment can improve the organisation’s usable knowledge without pretending to model the entire enterprise in advance.

The Readiness Map

The Readiness Map shows how well the requirements for the intended answer are supported.

It connects what the answer depends on with the available evidence, confirmed business knowledge and unresolved gaps.

Executable checks can establish that identifiers match across files, formulas reproduce recorded totals or two sources contradict each other.

They cannot decide which source or rule the organisation intends to use.

That distinction remains visible in the result.

The readiness decision is intentionally not expressed as a percentage. “83% trustworthy” would imply a precision the system does not have.

Instead, the assessment gives one of three controlled outcomes:

• Ready — all material dependencies are sufficiently supported.
• Ready with limitations — a clearly defined, narrower answer is justified.
• Blocked — an unresolved dependency could materially change the answer.

“Ready with limitations” must mean something precise. In the vessel example, the permitted answer might exclude overhead because no valid overhead rule has been established.

If the selected material-price basis remains unconfirmed and could materially change even that narrower result, the correct decision is blocked.

Stopping is therefore not a failed run. It is a useful result when the available evidence does not justify greater confidence.

What the system learns

The knowledge used by before-we-ai comes from sources with different levels of authority.

Established domain knowledge provides general principles. For example, material cost depends on component quantities and an applicable price.

Source inspection reveals how the available files and systems appear to work. It may show that a workbook calculates material cost by multiplying BOM quantity by purchase price.

Organisational knowledge establishes what the company intends. An approved policy or authorised person may confirm which BOM revision and price basis must be used.

These statements are related, but they are not interchangeable:

Observed: The workbook uses Purchase_Price.

Confirmed: Purchase_Price is the approved basis for expected vessel costing.

AI can discover the first statement. It cannot safely authorise the second.

Confirmed knowledge is therefore stored together with its source, scope and validity. A rule applying to expected costing for one vessel family should not silently become a universal company rule.

Over time, this creates a reusable knowledge base grounded in actual business questions and validations.

The architecture, briefly

The first implementation uses one AI agent. The essential design choice is the separation of responsibilities around it.

AI interprets the question, proposes possible meanings and determines what should be checked.

Executable components inspect schemas, extract spreadsheet formulas, run SQL and perform reconciliations.

Approved documents or people with the relevant authority establish what the organisation intends.

The readiness layer decides what the available support permits the system to claim.

The high-level flow is:

Business question
→ clarify the intended answer
→ establish what a reliable answer requires
→ inspect the available sources
→ propose meanings and checks
→ collect evidence and confirmation
→ assess readiness
→ produce, limit or block the answer

The principle behind this architecture is simple:

The model may propose. Evidence may demonstrate. Authority establishes intent. Readiness controls the answer.

What this could become

The immediate goal is modest: demonstrate one complete answer path using a realistic business question and a limited set of sources.

A meaningful result would not merely produce a vessel-cost total. It would be able to say:

I can reproduce the number in the workbook, but I cannot yet confirm that it represents the current approved expected cost.

It should then identify exactly what is missing, why it matters and how the gap can be resolved.

If this works with real data, before-we-ai could sit between enterprise data and AI applications as an answer-readiness control layer.

Reports, analytics tools and agents could consume an answer together with its readiness status, evidence and limitations.

It would complement data platforms, catalogues and semantic models rather than replace them. Those systems organise data and context at scale.

before-we-ai makes a narrower decision:

Is the available context sufficient for this particular answer?

Each resolved question can add scoped, reusable organisational knowledge. The knowledge base grows through actual work rather than through an attempt to describe the entire enterprise in advance.

Why I am building it

before-we-ai brings together the areas in which I have worked for many years: finance, enterprise data, reporting and transformation.

It also reflects what interests me most about AI.

The opportunity is larger than producing answers faster. AI can help expose how business knowledge is distributed and where apparently settled calculations still depend on unspoken assumptions.

But plausible reasoning and justified confidence remain different things.

Capability is not authority, and plausible reasoning is not evidence.

before-we-ai is my attempt to turn that distinction into a working system.

This was not my first AI-supported project, but it was the most complex so far—and the first time the process genuinely felt like working with a development partner. That experience depended heavily on learning how to use agents effectively: matching the model and reasoning level to the task, choosing the right execution environment, and balancing speed against limited credits. Claude Fable and GPT-5.6 Sol made that shift especially tangible.

The next step is a small real-world test: one meaningful question, the sources currently used to answer it, and an honest decision about whether the result deserves trust.

Feedback and co-work wellcome

The project is open on https://github.com/happychriss/before-we-ai/—feedback, contributions, and sharing are very welcome.