DEV Community: FeasibilityproAI Analysis

Human-in-the-Loop Validation for AI-Generated Financial Models

FeasibilityproAI Analysis — Fri, 18 Sep 2026 11:00:03 +0000

AI can now generate surprisingly complete financial models. Give a sufficiently detailed prompt and a modern AI system can produce assumptions, schedules, formulas, scenario structures, and summary outputs in a fraction of the time that a traditional modelling workflow might require. That changes the bottleneck.

The difficult part is no longer only building the spreadsheet. It is establishing whether the generated model actually represents the business logic that the modeller intended. This distinction matters because a financial model can be mathematically consistent and still be wrong. A formula can calculate exactly what it was written to calculate while implementing the wrong assumption, applying the wrong timing convention, referencing the wrong cell, or interpreting a business instruction incorrectly.

That is why human-in-the-loop validation should be treated as part of the architecture of an AI-assisted financial modelling system rather than as a final visual inspection before someone opens the workbook. Recent guidance and research point in the same direction. ICAEW's 2026 discussion of AI-generated financial models recommends treating AI output as a draft that requires close human review, while PwC describes human-led validation as important for checking completeness, accuracy, reliability, business alignment, and source quality.

Generation and validation are different problems

A useful way to design these systems is to separate model generation from model validation.
The generation process might take natural-language requirements, source documents, assumptions, or structured inputs and convert them into a financial model. The resulting workbook or structured model can then be passed through deterministic calculations and automated validation before a human reviewer examines the remaining issues.
Conceptually, the workflow looks like this:
Source data and requirements
↓
AI model generation
↓
Deterministic calculation
↓
Automated validation
↓
Exception review
↓
Human validation
↓
Approved model

The important point is that the system does not ask the same component to generate the model and then declare its own output correct.

The AI system can propose the model structure and logic, but independent checks should establish whether the resulting model satisfies predefined requirements. The human reviewer then deals with questions that cannot be resolved reliably through mechanical checks alone. This separation becomes especially important when the model contains assumptions about timing, business rules, accounting treatment, project phases, or scenario interpretation.

A model can be internally consistent and still be wrong

Consider a simplified development model with land cost, construction cost, development period, revenue, operating expenses, financing, and an exit value. Suppose the AI generates all the formulas correctly from a syntactic perspective. Every cell contains a valid formula, there are no broken references, and the workbook recalculates without errors.

That does not establish that the model is correct. Imagine the project is supposed to generate operating revenue only after completion, but the generated model begins recognizing revenue during construction. The formulas may still be perfectly valid. The spreadsheet may balance. The summary page may display plausible-looking numbers.

The error is semantic rather than syntactic. The same problem can occur when an AI system interprets a cost assumption incorrectly, uses a different definition of area than the source data, applies an assumption to the wrong period, or changes the dependency between two schedules.

This is one reason human review remains important. A human reviewer can ask whether the model represents the intended scenario rather than merely whether the spreadsheet executes successfully.

Validation should happen at several levels

A robust validation process should not rely on a single test. The first level is structural validation. This checks whether the generated model contains the expected components and whether those components are connected in a sensible way. Required assumptions should be present, expected schedules should exist, output sections should be populated, and unexpected hard-coded values or missing dependencies should be flagged.

The second level is formula validation. Here the system checks whether formulas exist where they should, whether formulas are consistent across periods, whether references are valid, and whether unexpected changes appear in repeated calculation structures. Checks for broken references, circular references, inconsistent ranges, and formulas replaced by hard-coded values can often be automated.

The third level is numerical validation. Instead of asking whether an output "looks reasonable," the system tests known relationships within the model. For example, if total revenue is defined as the sum of periodic revenue, that relationship can be tested directly. If total project cost is defined as the sum of several cost categories, the reconciliation can be performed independently of the AI that generated the workbook.

The fourth level is semantic validation, and this is where human judgement becomes particularly important. The reviewer needs to establish whether the assumptions and calculations correspond to the intended business scenario. Automated tests can tell you that a formula works. They cannot always tell you that it is the right formula for the question being asked.

Deterministic checks are particularly valuable

Financial modelling contains many relationships that do not need probabilistic judgement.
If a model specifies that:
Total Cost = Land Cost + Construction Cost + Other Costs

the validation system can calculate both sides independently and compare them.
If:
Cash Balance[t] =
Cash Balance[t-1]

Cash Inflows[t]
Cash Outflows[t]

the system can test that relationship for every relevant period.
If a revenue schedule is driven by units and price:
Revenue[t] = Units[t] × Price[t]

The validation process can independently recalculate the expected result. These tests are valuable because they establish explicit pass/fail conditions. The validation result does not depend on another language-model response saying that the number "appears reasonable."

For financial models, this distinction is important. Where a calculation has a clearly defined mathematical relationship, the validation system should use that relationship as the reference rather than asking another probabilistic model to judge the answer.

Recent work on financial AI validation makes a similar argument: benchmark performance alone is not sufficient evidence for a production financial AI system, because the complete system also includes data, retrieval, generation, tool use, orchestration, monitoring, and human escalation.

Provenance should travel with the assumption

Another important part of validation is provenance. When an AI-generated model contains an assumption such as a construction cost, occupancy rate, price, interest rate, or development period, the reviewer should be able to understand where that value originated.
For example, instead of simply storing:
Construction Cost = 125

a model could maintain metadata such as:
Value: 125
Unit: USD / sq ft
Source: User-provided assumption
Status: Confirmed

The exact implementation will vary between systems, but the principle is straightforward: important assumptions should be traceable. This becomes more important when AI systems transform information before placing it into a model. If an input has been extracted from a document, inferred from context, converted between units, or derived from another assumption, the validation process should make that transformation visible.

The OECD's 2026 work on AI in finance similarly emphasizes traceability, validation, monitoring, and retention of model instances so that problematic behaviour can be investigated later rather than disappearing when a system is updated.

Do not use AI as the only validator

One of the easiest mistakes to make is to build a workflow that looks like this:
AI generates model
↓
AI reviews model
↓
Model approved

A second AI pass can certainly be useful. It can identify missing sections, obvious inconsistencies, unusual formulas, or potential errors. But it should not be the sole approval mechanism.

If the same underlying reasoning process can introduce an error, asking a similar system to validate the output does not provide the same level of independence as an external deterministic check or human review.

A stronger architecture separates responsibilities:
┌─────────────────┐
│ AI generation │
└────────┬────────┘
↓
┌─────────────────┐
│ Calculations │
│ and rules │
└────────┬────────┘
↓
┌─────────────────┐
│ Automated │
│ validation │
└────────┬────────┘
↓
┌─────────────────┐
│ Human review │
└────────┬────────┘
↓
Approval state

This does not eliminate AI-generated errors. It creates multiple opportunities for those errors to be detected.

Human review should focus on exceptions

Human-in-the-loop does not mean that a modeller should manually inspect every cell in every generated workbook. That would remove much of the efficiency gained from automation. A better design is to automate the repeatable checks and send exceptions to a human reviewer.

A validation report might therefore look like:
Structural checks: PASS
Formula checks: PASS
Reconciliation checks: PASS

Missing assumptions: 2
Unexpected formula changes: 1
Timing interpretation: REVIEW REQUIRED
Source provenance: 1 item unresolved
The reviewer can then concentrate on the areas where judgement is actually required.
This is a more practical division of labour. Computers are well suited to repeating deterministic tests across thousands of cells and periods. Humans are better positioned to resolve ambiguous requirements, interpret business context, and challenge assumptions. PwC similarly recommends tailoring the level of human review to the complexity and risk of the use case, with more rigorous validation for higher-stakes financial outputs.

Test the model by changing its assumptions

Validation should not stop with the base case. A useful model should respond coherently when important assumptions change. Suppose construction cost increases by 10%. The model should show the corresponding effect on total development cost and any downstream cash-flow metrics that depend on it.

Suppose the development period changes. Timing-sensitive costs and revenues should move accordingly. Suppose an input is set to zero. If that input is genuinely part of the calculation chain, the relevant outputs should respond. These tests can expose broken dependencies that may not be visible when reviewing the base case alone.

The purpose is not to determine whether a particular scenario is commercially attractive. The purpose is to verify that the model behaves according to its defined logic when its inputs change.

Define the approval state explicitly

Another useful design decision is to make model status explicit. A generated model should not automatically become an approved model.

A simple state machine could be:
GENERATED
↓
AUTOMATED VALIDATION
↓
┌───────────────┐
│ │
PASS FAIL
│ │
↓ ↓
HUMAN REVIEW REPAIR
│ │
├── APPROVED ───┘
│
└── CHANGES REQUIRED
This creates an audit trail around the model itself. It also prevents a common operational problem: treating an AI-generated artifact as if it has already passed the organization's review process simply because it exists and produces numbers.

The role of the human is changing

Human-in-the-loop validation does not necessarily mean that AI has failed to automate financial modelling. It means that the nature of the human role changes.

Instead of spending most of the time manually constructing repetitive formulas, a modeller may spend more time defining assumptions, establishing validation rules, reviewing exceptions, testing model behaviour, and challenging the interpretation of the generated model.

That shift is consistent with recent industry research. The Financial Modeling Institute's 2026 survey of 63 financial-modelling professionals across 26 countries found that none of the respondents said they would be confident relying on an AI-generated financial model for a high-stakes business decision without independent human review.

The implication is not that AI-generated modelling has no value. It is that generation and approval should be treated as different stages of the workflow.

A practical validation framework

For an AI-assisted financial modelling system, a useful validation framework can therefore combine five elements.

First, validate structure. Confirm that the model contains the expected inputs, schedules, calculations, and outputs.

Second, validate formulas and relationships. Check references, repeated formulas, reconciliations, dependencies, and other deterministic relationships independently of the generation process.

Third, validate provenance. Make important assumptions traceable to their source and record transformations where relevant.

Fourth, test behaviour. Change important assumptions and confirm that the model responds according to its defined logic rather than merely producing a plausible base case.

Fifth, require human approval for unresolved semantic questions. The reviewer should be able to challenge assumptions, interpretation, timing, and other aspects that automated checks cannot reliably resolve. This produces a more useful definition of validation than simply checking whether a spreadsheet opens without errors.

The goal is controlled automation

The strongest argument for human-in-the-loop validation is not that humans are always better than AI or that AI should never be trusted. The practical argument is that different parts of a financial modelling workflow have different verification requirements.

AI can be useful for generating structures, translating requirements into model components, drafting formulas, and accelerating repetitive work. Deterministic systems can test calculations and reconciliations. Provenance mechanisms can make assumptions traceable. Automated validation can identify exceptions. Human reviewers can resolve ambiguity and determine whether the model represents the intended business logic.

The result is a workflow in which the model does not become trusted merely because an AI system generated it. It becomes reviewable because its assumptions can be traced, its calculations can be tested, its behaviour can be challenged, and its unresolved questions can be presented to a human before approval. For financial modelling, that distinction is fundamental.

Generation produces a model. Validation produces evidence about the model. Human review determines whether that evidence is sufficient for the intended use.

Keep the LLM Out of the Math: Deterministic Boundaries for Financial Modelling Agents

FeasibilityproAI Analysis — Fri, 11 Sep 2026 09:57:15 +0000

Large language models are increasingly being used as interfaces to financial software. Instead of opening a spreadsheet and navigating through dozens of tabs, a user can describe a change in ordinary language and ask an AI system to identify the relevant assumption, run a scenario, compare two cases, or explain why an output changed. That interaction model is useful because financial models are often difficult to navigate even for experienced users, particularly when the underlying workbook contains many assumptions, formulas, dependencies, and scenario-specific adjustments.

The architectural problem begins when the language model is also made responsible for performing the financial calculation itself.

That may seem reasonable at first. The model understands the request, it has access to the relevant numbers, and modern LLMs can perform arithmetic. For a simple calculation, the distinction may not matter much. In a real financial model, however, the calculation is rarely an isolated operation. A single assumption can affect a long chain of formulas, and the correctness of the final result depends not only on arithmetic but also on which assumptions were selected, how they were interpreted, which dependencies were recalculated, and whether the resulting state is consistent with the model.

This is why a financial AI system should separate language reasoning from numerical execution.

The language model should be responsible for understanding the user's intent and translating that intent into a structured operation. A deterministic calculation layer should then validate the operation, execute the relevant formulas, and return structured results. The language model can come back into the process afterward to explain those results in terms that a human can understand.

That division of responsibility is not about pretending that LLMs cannot do mathematics. It is about giving each part of the system a job that can be tested and trusted independently.

The difficult part is usually not the arithmetic

Consider a request such as:
What happens to the project if construction costs increase by 8%?
The arithmetic implied by the question is straightforward. If the relevant construction cost is $10 million, an 8% increase produces $10.8 million.

The difficult part is determining what the user actually means by "construction costs" in the context of the model.

The workbook might contain total construction cost, construction cost per square metre, separate hard and soft costs, costs distributed across multiple development periods, or different cost assumptions for different scenarios. The model might also calculate financing costs from the timing and amount of construction expenditure. If the assumption changes, those financing costs may need to change as well. A scenario may need to be created instead of modifying the base case.

None of those questions can be answered by arithmetic alone. They are interpretation and model-structure questions.

Once the correct variable has been identified and the intended operation has been validated, however, there is little reason for the language model to calculate the resulting financial outputs itself. The application already has a place where those calculations can be performed deterministically.

This distinction becomes particularly important because recent evaluations of spreadsheet agents show that the hard part of real financial spreadsheet work is not simply generating an individual formula. End-to-end tasks involve multiple worksheets, dependencies, debugging, formatting, and selecting the correct cells or model components. SpreadsheetBench 2, for example, evaluates agents on realistic multi-sheet business workflows and reports substantial reliability gaps in current systems.

A financial agent should translate intent into an operation

A useful way to think about the LLM is as a translation layer.
The user speaks in terms of business intent:
Increase construction cost by 8% and show me the effect on the project.
The application needs something much more precise:
{
"operation": "scenario_change",
"target": "construction_cost",
"change_type": "relative",
"change": 0.08
}
This structured object should not immediately be treated as a valid instruction.
It is a proposed operation that needs to pass through validation.
The system can check whether construction_cost exists in the model, whether the operation supports a relative change, whether the percentage is expressed in the expected format, and whether the user is asking to create a scenario or modify an existing assumption. It can then pass the validated operation to the calculation layer.

This creates a useful separation:

The LLM therefore does not disappear from the workflow. It simply stops being the authority for the numerical result.

That distinction is important because it gives engineers something concrete to test. The interpretation step can be evaluated against expected structured operations, while the calculation engine can be tested independently using known inputs and outputs.

Structured output does not solve the reliability problem by itself

One of the easiest mistakes to make is assuming that structured output automatically makes an AI system reliable.

It does not. A model can return perfectly valid JSON that describes a completely inappropriate operation.
For example:
{
"operation": "set_assumption",
"target": "construction_cost",
"value": -5000000
}
The JSON is valid. The instruction may be nonsensical.

The application therefore needs to distinguish between syntactic validity and semantic validity.

Syntactic validation answers questions such as whether the required fields exist and whether their data types are correct. Semantic validation asks whether the operation makes sense in the context of the actual financial model.

That second layer might check whether the target variable exists, whether the unit is compatible with the variable, whether the value falls within an acceptable range, whether the requested operation is supported for the current scenario, and whether changing that assumption requires additional calculations to be performed.

This is also where authorization belongs. If an agent is allowed to change assumptions, the application should decide which operations the user is permitted to perform. The LLM should not determine its own authority simply because it has generated a plausible tool call.

Tool design matters more than giving the model more freedom

Agent frameworks often make it easy to expose a large collection of tools to a language model and allow the model to decide what to do next.

That flexibility is useful for some applications, but financial modelling generally benefits from narrower interfaces.

Imagine giving an agent a generic spreadsheet-editing function that allows it to select arbitrary cells, change their values, rewrite formulas, and modify formatting. The model may be capable of using such a tool, but every additional degree of freedom increases the number of ways in which an incorrect interpretation can become a damaging state change.

A better approach is to expose operations that correspond to meaningful financial-model actions.
For example:
get_assumption()
set_assumption()
create_scenario()
calculate_scenario()
compare_scenarios()
get_dependencies()
The difference is subtle but important.
With a generic spreadsheet tool, the model decides both what the user means and how that meaning should be implemented in the workbook.

With a domain-specific interface, the model decides what operation the user appears to be requesting, while the application determines how that operation is safely executed.

For example, the model might produce:
{
"function": "set_assumption",
"arguments": {
"scenario": "construction_cost_upside",
"target": "construction_cost_per_gfa",
"value": 1850,
"unit": "USD/m2"
}
}
The application can then resolve construction_cost_per_gfa, verify the unit, check whether the scenario exists, validate the value, and determine which downstream calculations must be recalculated.

The agent is still useful, but the financial model retains control of its own state.

Deterministic calculations are valuable because they can be tested

Moving arithmetic out of the LLM is not enough on its own. The calculation layer must also be engineered properly.

A deterministic function is valuable because its behaviour can be inspected and tested independently of the language model.
For example:
def development_margin(revenue, total_cost):
if revenue == 0:
raise ValueError("Revenue cannot be zero")

return (revenue - total_cost) / revenue

The important property here is not that the formula is sophisticated. It is that the function has a clearly defined contract.

Given the same valid inputs, the function should produce the same result. That allows ordinary software-testing techniques to be applied.

You can test expected values, invalid inputs, boundary conditions, and changes to the underlying calculation logic. You can also run regression tests against known model cases whenever the calculation engine changes. Scenario testing becomes especially useful.

If construction cost increases while all other assumptions remain unchanged, the system should produce a predictable direction of change in the relevant outputs. If the model contains financing costs that depend on construction expenditure, those dependencies should be explicitly represented and tested rather than relying on the language model to remember them.

The calculation engine should therefore be treated as software, not as a hidden extension of the prompt.
Spreadsheet automation makes the distinction even more important
The argument becomes stronger when the AI agent operates directly on spreadsheets.
A spreadsheet is not simply a two-dimensional database of values. It is a computational environment containing formulas, references, dependencies, named ranges, formatting conventions, multiple worksheets, and often business logic that is encoded indirectly through the workbook's structure.

That creates a much larger surface area for errors. Recent financial spreadsheet benchmarks reinforce this point. WorkstreamBench evaluates agents on end-to-end financial spreadsheet tasks and measures accuracy, formula quality, and format against professional standards. Its results indicate that even strong agents can degrade substantially as workflows move beyond relatively small chains of calculations.

BlueFin reaches a similar conclusion from another direction. Its benchmark contains challenging professional-finance spreadsheet tasks, and frontier models perform poorly on some of the dynamic-correctness requirements.

That does not mean spreadsheet agents are useless. It means that "the model can edit the spreadsheet" should not be confused with "the model can reliably maintain the financial logic of the spreadsheet." Those are different capabilities.

A robust architecture should therefore make the financial model's rules explicit wherever possible and use the LLM to navigate, interpret, and communicate rather than silently becoming the spreadsheet's calculation engine.

The number should carry its provenance

There is another reason to separate calculation from language generation: a financial output needs more context than its value.

Suppose an agent returns:

Development profit: $12.4 million

The number may be correct, but a professional user will often have a more important question:
Why is it $12.4 million?

A useful system should be able to trace that result back through the assumptions and calculations that produced it.
For example:
Development profit
|
+-- Revenue
| |
| +-- Area assumptions
| +-- Pricing assumptions
|
+-- Development costs
|
+-- Construction cost
+-- Professional fees
+-- Financing
The implementation does not need to expose this exact diagram to the user, but the underlying system should preserve enough information to reconstruct the dependency chain. That may include the model version, scenario, input values, units, calculation function, source references, and validation results.

The advantage is not merely auditability. It also makes debugging much easier.If the final result looks wrong, an engineer can determine whether the problem originated with the source assumption, the interpretation of the user's request, the dependency mapping, or the calculation itself.

Without provenance, all of those failures collapse into one generic problem: "the AI gave the wrong answer."

Evidence and assumptions should not be treated as the same thing

This becomes especially important when an AI system retrieves information from external sources.
Imagine an agent finds a market report containing a rental figure.
The retrieved figure is evidence.
It is not automatically a model assumption.
There is a chain of decisions between those two things. The system needs to know what the source actually said, which period it referred to, what geography it covered, what unit it used, and whether the figure is appropriate for the model being constructed.
Only after that assessment should the value become an explicit modelling assumption.
A useful representation might look like:
{
"evidence": {
"source": "market_report.pdf",
"page": 18,
"metric": "average_rent",
"period": "2026-Q2",
"value": 42
}
}
The model can then contain a separate assumption:
{
"assumption": {
"name": "monthly_rent",
"value": 42,
"unit": "currency/m2/month",
"source_reference": "market_report.pdf:p18"
}
}
The distinction allows someone reviewing the model to challenge either the evidence or the modelling decision without confusing the two.
This is one of the areas where AI systems can otherwise become difficult to audit. A generated answer may look authoritative even though the underlying number passed through several undocumented interpretation steps.

The LLM becomes more useful after the calculation

Once the calculation engine has produced a structured result, the language model can return to the workflow.
This is where it can provide substantial value without being responsible for the underlying arithmetic.
Suppose the calculation engine returns:
{
"scenario": "construction_cost_upside",
"construction_cost_change": 0.08,
"profit_change": -1200000,
"margin_change": -0.047
}
The LLM can explain what happened in context:
The 8% increase in construction cost reduces projected development profit by $1.2 million under this scenario. The model also shows a reduction in margin of approximately 4.7 percentage points. These changes reflect the assumptions and dependencies contained in the current model, so the scenario should be interpreted as a sensitivity to those assumptions rather than as an independent forecast.
The difference is important.
The LLM is not deciding that profit fell by $1.2 million.
The calculation engine has already established that result.
The LLM is translating the result into useful language.
That makes the generated explanation easier to review because every important numerical statement can be traced back to structured output.

A good financial agent should be replayable

A useful engineering test for an AI financial workflow is to ask whether another engineer could reproduce the calculation without asking the LLM to perform the reasoning again.
Suppose the system records:
{
"model_version": "2026.09",
"scenario": "construction_cost_upside",
"inputs": {
"construction_cost": 12500000,
"revenue": 18000000
},
"operations": [
{
"function": "apply_relative_change",
"target": "construction_cost",
"change": 0.08
},
{
"function": "development_profit",
"target": "profit"
}
]
}
Another process should be able to take the same model version, inputs, and operations and reproduce the result.

This property is useful for much more than formal auditing. It helps with debugging, regression testing, incident investigation, and model review.There is growing research specifically around reproducibility and determinism in tool-using financial agents, including work examining whether identical inputs can produce consistent trajectories and evidence-aligned decisions.

The broader engineering principle is straightforward: if a result matters, the system should retain enough information to reproduce how that result was obtained.

Human review becomes more meaningful when the architecture is explicit

"Human in the loop" is often presented as a solution to AI reliability problems, but simply putting a person at the end of an opaque workflow does not necessarily make the workflow safe.

A reviewer needs something meaningful to inspect.
A well-designed financial agent can expose a chain such as:
User request
↓
Interpreted operation
↓
Validated target
↓
Evidence / assumptions
↓
Deterministic calculation
↓
Changed outputs
↓
Generated explanation
The reviewer can then ask the right question at the right layer.
If the target variable is wrong, the interpretation needs attention.
If the source assumption is unsuitable, the evidence needs attention.
If the formula is wrong, the calculation engine needs attention.
If the calculation is correct but the narrative overstates what it proves, the explanation needs attention.

That is far more useful than asking someone to read a polished paragraph and decide whether it "looks right."
The architecture also limits the blast radius of an AI mistake
There is a practical reason to keep these boundaries separate. LLMs will make interpretation errors.

The objective should therefore not be to build a system that assumes the model will never make a mistake. The objective should be to make sure an interpretation error does not automatically become an uncontrolled financial-model mutation.
If the LLM proposes:
construction_cost_per_gfa = 1850 USD/m²
the application can reject it if the unit is incompatible, the variable does not exist, the value is outside an allowed range, or the requested scenario cannot be modified.

The model has made a mistake, but the system has contained it. This is a much more realistic approach to AI reliability than trying to eliminate every possible model error.

The practical rule

For financial modelling agents, the most useful rule is simple:
If a result must be reproducible from the same inputs, the LLM should not be responsible for producing the result.
That does not mean LLMs have no place in financial modelling.
They can be extremely useful for interpreting requests, extracting assumptions from documents, identifying ambiguity, selecting appropriate operations, summarising scenario changes, and explaining model outputs.

The calculation layer should remain responsible for arithmetic, formula execution, dependency propagation, validation, scenario calculation, and other operations where reproducibility matters.

The provenance layer should preserve enough information to explain where the inputs came from and how the outputs were produced.

The human reviewer should be able to inspect the chain rather than simply trusting the final prose.

Conclusion

The interesting engineering question is not whether a language model can calculate an eight-percent increase.

It can.
The harder question is what happens when that calculation becomes one step in a financial model containing hundreds of assumptions, thousands of formulas, cross-sheet dependencies, external evidence, and scenario logic. At that point, asking the LLM to perform everything in one conversational loop creates an unnecessary reliability problem.

A better architecture gives the language model responsibility for language and interpretation while giving deterministic software responsibility for numerical execution.

The LLM can translate the user's request into a structured operation. The application can validate that operation against the model. A deterministic calculation engine can execute the relevant formulas. The system can preserve provenance and return structured results. Finally, the LLM can explain those results in language that makes sense to the user.

The result is not an attempt to make the language model behave like a spreadsheet.

It is a system in which the language model acts as an intelligent interface to a financial model whose calculations remain explicit, testable, reproducible, and reviewable. For financial AI, that boundary is not a limitation. It is part of the architecture that makes the system useful.

Why Cell-Level Citations Matter in AI-Powered Excel Tools

FeasibilityproAI Analysis — Sat, 05 Sep 2026 10:22:57 +0000

An AI system can give you the right number and still give you a poor answer.

The problem is not necessarily the calculation. It is the missing chain between the number in the workbook and the evidence that produced it.

Consider a development model with a cell containing:

Construction cost = 2,200 / m²

A reviewer immediately has several questions:

Where did 2,200 come from?
What geography does it represent?
What asset type?
What date?
Is it an actual project cost, an industry benchmark, or an assumption?
Who entered it?
What happens if the source changes?

A conventional spreadsheet often stores the value but not enough of that context.

That becomes more important when AI is involved.

If an AI system extracts market information, interprets documents, proposes assumptions, and writes values into Excel, provenance cannot live only in an external log. The reviewer needs a practical way to move from the cell to the evidence.

That is why cell-level citations are useful.

The basic model: value is not provenance

A useful mental model is:

source
↓
extracted fact
↓
interpreted assumption
↓
Excel cell
↓
formula
↓
model output

Each stage answers a different question.

The source answers:

What evidence did we use?

The extracted fact answers:

What did we take from that evidence?

The assumption answers:

How did we translate the evidence into a modelling input?

The cell answers:

Where does that assumption live?

The formula answers:

How does the model use it?

The output answers:

What does the model produce under these assumptions?

AI systems often compress these stages into one response.

That is convenient for generation, but inconvenient for review.

A citation system should do the opposite: preserve the relationships.

Why a citation attached to the cell is different

Suppose an AI workflow produces this workbook:

Cell Input
B12 2,200
B13 12,000
B14 70%

An external research log might say:

B12 → source A
B13 → source B
B14 → source C

That is better than nothing, but the reviewer still has to maintain two contexts.

A cell-level citation puts the provenance closer to the object being reviewed.

Conceptually:

B12
Construction cost
2,200 / m²
│
└── Source:
report.pdf, p. 18
published: 2026-06
geography: Dubai
asset: residential

The important idea is not the particular UI mechanism.

It is locality.

When a reviewer questions a number, the evidence should be discoverable from the number.

Excel already has a useful primitive: comments

Excel's object model provides comments associated with individual cells. Microsoft's current Excel JavaScript API documentation describes comments as threads tied to a single cell and supports creating, editing, deleting, resolving and reading comment metadata.

For example, an add-in can create a comment thread on a specific cell:

await Excel.run(async (context) => {
const comments = context.workbook.comments;

comments.add(
"Assumptions!B12",
"Source: Construction Cost Report\n" +
"Published: 2026-06\n" +
"Page: 18\n" +
"Geography: Dubai\n" +
"Asset: Residential"
);

await context.sync();
});

The important part is not the API call.

It is that Assumptions!B12 is explicitly connected to its provenance.

Microsoft documents the comments API as part of the Excel JavaScript API, with comment support available from the relevant API sets.

Office Scripts provides another route for workbook automation and also supports adding comments to cells.

But don't put the whole source system into the comment

A tempting implementation is to dump everything into the cell comment:

Source:
URL:
Document:
Page:
Paragraph:
Extract:
LLM:
Prompt:
Model:
Timestamp:
Hash:
Confidence:
Reasoning:
...

That quickly becomes unusable.

The comment should be a pointer, not the entire provenance database.

A better pattern is:

Cell
↓
Citation ID
↓
Provenance record
↓
Source

For example:

B12 → SRC-00427

and the provenance record might contain:

{
"citation_id": "SRC-00427",
"source": {
"document": "construction-cost-report.pdf",
"page": 18,
"published": "2026-06"
},
"scope": {
"geography": "Dubai",
"asset": "residential"
},
"extracted_value": 2200,
"unit": "USD/m²"
}

This creates a useful separation:

Excel stores the reference.

The provenance layer stores the detail.

The citation should describe evidence, not certainty

This distinction matters.

Imagine a source says:

Construction costs for a particular benchmark category were reported at X.

The model may subsequently use X as an assumption.

The citation should not silently convert:

reported benchmark

into:

true project cost

Those are different claims.

A good provenance record therefore distinguishes at least:

SOURCE
DATA PERIOD
GEOGRAPHY
ASSET CLASS
EXTRACTED VALUE
UNIT
INTERPRETATION
MODEL ASSUMPTION

That makes it possible for a reviewer to challenge the interpretation rather than merely inspect the URL.

Citation IDs are more robust than URLs

URLs change.

Documents get replaced.

Reports have multiple editions.

A provenance record can therefore use a stable internal identifier:

SRC-00427

with metadata such as:

Source name
Publication date
Data period
Document version
Page
Location
Claim
Extraction date

The workbook then carries:

B12 → SRC-00427

rather than attempting to encode an entire research record into the cell itself.

This also makes automated validation possible.

For example:

def validate_citation(cell, provenance):
citation_id = cell.metadata["citation_id"]

if citation_id not in provenance:
    raise ValueError(
        f"Missing provenance for {cell.coordinate}"
    )

The principle is simple:

A material AI-generated input should not silently become an unexplained spreadsheet value.

Cell citations also help with AI failure modes

AI systems have several failure modes that are particularly awkward in spreadsheets.

Correct source, wrong interpretation

The model finds the right report but interprets an annual figure as a monthly figure.

A citation lets the reviewer return to the source.

Correct number, wrong scope

The number is real, but it applies to office rather than residential development.

Again, the citation provides the path back to the evidence.

Stale evidence

A source may be valid but old.

The citation exposes its publication date and data period.

Unsupported inference

The AI may produce a plausible assumption without a source.

That should result in:

citation = missing

rather than a fabricated citation.

Source substitution

A workflow may use one source during research and a different source when generating the final workbook.

A stable citation ID makes that substitution easier to detect.

Provenance should be machine-readable too

Human-readable comments are useful, but they should not be the only representation.

A production design could maintain a provenance table:

Citation ID Cell Source Page Date Scope
SRC-00427 B12 Cost report 18 2026-06 Dubai residential
SRC-00428 B13 Planning document 42 2026-05 Project
SRC-00429 B14 Market report 11 2026-07 Residential

Then validation becomes possible before the workbook leaves the system.

For example:

required_inputs = [
"B12",
"B13",
"B14",
]

for address in required_inputs:
if address not in cited_cells:
raise ValueError(
f"Material input has no citation: {address}"
)

The exact implementation can vary.

The architectural principle is more important:

material input
↓
citation required
↓
provenance record
↓
source verification

Don't cite every calculated cell

There is another trap here.

If every formula cell gets a source citation, the workbook becomes noisy.

A calculated output does not necessarily need its own external source.

For example:

=B12*B13

does not need a market citation if B12 and B13 already carry appropriate provenance.

Instead, the dependency chain should be traceable:

B12 ──┐
├──→ B20
B13 ──┘

with citations attached to the material inputs.

This gives a much cleaner separation:

External evidence
↓
Material assumptions
↓
Deterministic formulas
↓
Model outputs

The output is therefore explainable through its inputs and formulas.

A practical schema

For an AI-powered Excel workflow, a minimal citation object might look like this:

{
"citation_id": "SRC-00427",
"cell": "Assumptions!B12",
"source": {
"name": "Construction Cost Report",
"url": "https://example com/report pdf",
"published": "2026-06"
},
"location": {
"page": 18
},
"claim": {
"value": 2200,
"unit": "USD/m²"
},
"scope": {
"geography": "Dubai",
"asset_class": "residential"
}
}

In a real system, the URL would need to be an actual verified source rather than the placeholder above.

The schema can also be extended with:

data_period
source_type
extraction_method
review_status
assumption_status
supersedes

But the goal should remain restraint.

Provenance is useful when it helps someone answer:

Why is this number here?

What the AI should not decide

The system should not automatically turn every extracted fact into an approved modelling assumption.

A safer boundary is:

AI extraction
↓
candidate evidence
↓
candidate assumption
↓
human review
↓
approved model input
↓
calculation

This preserves a critical distinction between evidence and professional judgment.

A source can support a number without proving that the number is appropriate for the project being analysed.

That suitability decision belongs in the modelling workflow.

The real benefit is not citation. It is reviewability.

Cell-level citations are sometimes described as a documentation feature.

That understates their value.

They can become part of the control layer around AI-generated spreadsheets.

A reviewer can ask:

Which cells came from external evidence?
Which cells are assumptions?
Which assumptions have citations?
Are the sources current?
Does the source scope match the model?
Which outputs depend on a disputed assumption?

That is a much more useful question set than:

Did the AI get the answer right?

Because a feasibility model is rarely just an answer.

It is a chain of evidence, assumptions, formulas and outputs.

AI can help construct that chain.

It should not make the chain invisible.

A practical implementation pattern

If I were designing this workflow, I would keep five layers separate:

Source layer
Documents, reports, URLs
Evidence layer
Extracted claims + source locations
Assumption layer
Values selected for modelling
Workbook layer
Cells + formulas + citation IDs
Review layer
Human validation and overrides

Then the system can enforce simple rules:

No source
→ no evidence

No evidence
→ assumption requires review

Material assumption without citation
→ validation failure

Formula output
→ trace inputs, don't invent another citation

Human override
→ preserve the original evidence

That last rule matters.

If a reviewer changes 2,200 to 2,350, the system should not erase the original provenance.

Instead, it should preserve:

Original evidence: SRC-00427
Original assumption: 2,200
Reviewed assumption: 2,350
Reviewer: human
Reason: project-specific adjustment

Now the model contains a history of judgment rather than pretending the revised value came directly from the source.

Conclusion

The strongest AI-to-Excel workflows will not be the ones that merely write numbers into cells.

They will make those numbers inspectable.

Cell-level citations provide a practical bridge between a spreadsheet and the evidence behind it. Excel's current APIs provide mechanisms for attaching comments and related metadata to individual cells, which makes this pattern technically feasible.

The larger design principle is broader than Excel:

Keep evidence, assumptions, calculations and decisions separate, but make their relationships explicit.

That is what turns an AI-generated workbook from a collection of plausible values into something a professional can actually review.