DEV Community: FeasibilityproAI Analysis

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

FeasibilityproAI Analysis — Sat, 17 Oct 2026 11:54:42 +0000

An AI system can produce a spreadsheet that looks correct, contains plausible formulas, and returns a coherent financial result while still encoding the wrong assumptions.

That is a difficult failure to detect because spreadsheet quality has several dimensions. A workbook may be syntactically valid but semantically wrong. Its formulas may calculate correctly while referencing the wrong inputs. Its output may be internally consistent but depend on unsupported source data.

These are different failure modes, and they require different controls. For financial models, the engineering objective should not be to make a language model responsible for every step. It should be to separate interpretation, calculation, validation, and professional approval so that each can be tested independently.

This article develops one possible implementation pattern for AI-assisted financial modelling. It is an educational architecture, not a description of any proprietary product.

1. Define what is being validated

Before designing a validation pipeline, distinguish five objects:

Input: a value extracted from a document, spreadsheet, or user instruction.
Assumption: the interpretation of that input used by the model.
Evidence: the source that supports, qualifies, or contradicts the assumption.
Model output: a result produced by formulas under specified assumptions.
Professional decision: the judgment made after considering the output, uncertainty, and context.

These objects should not collapse into a single generated answer. Consider a hypothetical development feasibility model. An AI system extracts a construction cost from a project document and proposes entering it into a workbook.

The extraction may be correct, but that does not establish that the figure is current, applies to the relevant asset, or uses the correct unit. Even after the assumption has been approved, the resulting calculation still needs validation.

A useful validation system therefore asks separate questions:

Was the source read correctly?
Was the value interpreted correctly?
Is the assumption suitable for this model?
Did the calculation execute correctly?
Does the output behave as expected when inputs change?
Is the result sufficiently supported for professional review?

A single confidence score cannot adequately answer all six.

2. Keep language interpretation separate from calculation

Language models are useful for interpreting ambiguous instructions, extracting information, identifying relationships, and proposing structured data.

They should not be the sole authority for consequential arithmetic.

A safer design separates the workflow into distinct stages:

Source documents and workbook
            |
            v
AI-assisted extraction
            |
            v
Structured candidate assumptions
            |
            v
Schema and provenance validation
            |
            v
Human approval of material inputs
            |
            v
Deterministic calculation engine
            |
            v
Independent validation checks
            |
            v
Human review and release

This separation creates meaningful test boundaries.

For example, if a residual land value changes unexpectedly, an engineer can investigate whether the cause was an extracted input, a changed assumption, a formula defect, or a validation failure. The architecture does not guarantee that every error will be caught, but it makes errors easier to locate and investigate.

The calculation engine should receive typed, validated inputs and execute explicitly defined formulas. It should not need to infer the intended mathematics from a natural-language explanation each time a calculation runs.

3. Make assumptions machine-readable

A common weakness in AI-assisted workflows is treating generated prose as if it were a reliable data interface.

Instead, require the model to propose structured records. The exact schema will depend on the application, but a candidate assumption might look like this:

{
  "name": "construction_cost",
  "value": 1250,
  "unit": "currency_per_square_metre",
  "source_reference": "document_03",
  "source_location": "page_12",
  "status": "pending_review"
}

The number and unit above are illustrative, not market evidence.

A production schema would normally need additional fields, such as currency, applicable area definition, source date, geographic scope, extraction status, and approval metadata where relevant.

The important point is that the value is not accepted merely because the model returned valid JSON.

Validation should cover several layers:

Structural validation

Are required fields present?
Are types correct?
Are unexpected fields rejected or explicitly handled?
Are enumerated values valid?

Semantic validation

Is the unit appropriate for the assumption?
Is the value within a defensible range?
Does the value match the intended asset and geography?
Are required dates and scope definitions present?

Provenance validation

Does the referenced source exist?
Can the reviewer locate the supporting passage or cell?
Does the source actually support the proposed interpretation?
Is the evidence current enough for the intended use?

A schema can enforce structure. It cannot, by itself, establish that an assumption is commercially reasonable.

4. Validate calculations independently

Once assumptions are approved, calculations should run through deterministic code or a controlled spreadsheet calculation engine.

Deterministic means that the same defined inputs, formulas, and calculation rules produce the same result under the same execution conditions. It does not mean the model is economically correct.

Validation should include at least four categories.

Formula and dependency checks

Confirm that formulas use the intended cells, units, and dependency relationships. Detect broken references, unexpected hard-coded values, circular dependencies where prohibited, and missing required formulas.

Where a spreadsheet is involved, the validation layer should distinguish a formula cell from a displayed value. A cached result alone may not establish that the formula was recalculated using the latest inputs.

Accounting and reconciliation checks

Where applicable, test identities and reconciliations defined by the model specification.

Examples include:

Total costs reconcile to their component categories.
Financing sources and uses reconcile.
Cash flows reconcile to the specified timing and period conventions.
Intermediate outputs reconcile to downstream calculations.

The checks must be derived from the actual model specification. Not every financial model has the same identities or conventions.

Boundary and type checks

Reject or flag invalid inputs, incompatible units, missing required values, impossible dates, and calculations that divide by zero.

A value being numeric does not mean it is valid for the model.

Regression tests

Maintain a set of known test cases. After changing formulas, extraction logic, or calculation code, compare the results with approved expected outcomes.

Tests should cover normal cases, boundary conditions, missing data, and known failure scenarios. Expected results must come from independently checked calculations or approved specifications, not from the same model output being tested.

5. Test behavior, not just individual numbers

A model can pass isolated formula checks while behaving badly when assumptions change.

Sensitivity testing examines whether outputs respond in ways consistent with the model's defined relationships.

For a hypothetical development model, useful tests might include:

Increasing a cost assumption while holding other inputs constant.
Delaying revenue-generating activities.
Reducing expected revenue.
Changing financing assumptions within permitted ranges.
Combining adverse assumptions to examine downside exposure.

These are diagnostic tests, not universal assertions about every model.

For example, increasing construction cost would generally be expected to reduce residual land value in a conventional residual valuation model when all other inputs remain fixed and the additional cost is not offset elsewhere. If the output increases instead, the system should flag the behavior for investigation.

The test does not automatically prove that the model is defective. There may be a legitimate dependency or offsetting rule. The purpose is to make the behavior explicit and explainable.

A practical test suite should distinguish:

Invariant checks: conditions that must always hold.
Expected directional checks: relationships that should hold under specified conditions.
Scenario tests: outputs under deliberately changed assumptions.
Regression tests: comparisons with previously verified cases.

Directional checks need careful design. Hard-coding intuitive rules without accounting for model dependencies can produce false alarms.

6. Treat human review as a defined control

Adding a human approval button is not sufficient. The reviewer needs the information and authority required to make a meaningful decision.

A useful review interface should expose:

The proposed assumption and its unit.
The original source and relevant location.
The extraction or interpretation proposed by the AI.
Any transformations applied to the source value.
The downstream calculations affected.
Validation failures and unresolved warnings.
The difference between the current and proposed model state.

Review priority should reflect materiality and uncertainty. A minor formatting issue does not require the same treatment as an unsupported assumption that materially changes a financial result.

A possible approval policy is:

Condition	System action
Required source missing	Block the assumption
Unit or schema invalid	Reject or quarantine the candidate
Material assumption lacks approval	Prevent release
Calculation reconciliation fails	Block release pending investigation
Sensitivity test produces an unexplained result	Escalate for review
All required checks pass	Permit the next review stage

Passing automated checks should not be treated as proof that a model is suitable for a real-world decision.

The approval policy must also define who can approve an assumption, what evidence is required, how overrides are recorded, and when an approval expires or must be revisited.

7. Preserve an audit trail

A useful audit trail records the sequence of changes, not just the final workbook.

For each material assumption, record the source reference, extracted value, proposed interpretation, approved value, reviewer, timestamp, and reason for any override.

For each calculation run, record the model version, input version, calculation version, validation results, and output version.

Where AI is involved, also consider recording the model or service version and the relevant processing configuration, subject to privacy, security, and retention requirements.

This is important because an identical output can arise from different assumptions, while a changed output can result from either changed inputs or changed calculation logic.

Auditability requires enough information to reconstruct why a result was produced. A generated explanation that merely sounds plausible is not a substitute for that record.

8. Avoid common validation mistakes

Mistake 1: Treating valid JSON as correct data.

A schema proves that a response meets structural constraints. It does not prove that a source was interpreted correctly or that the value is appropriate.

Mistake 2: Asking the same AI system to verify its own answer.

A second model-generated explanation may identify useful issues, but it is not independent evidence of correctness. Independent checks should use source evidence, deterministic calculations, explicit invariants, or separately established expected results.

Mistake 3: Checking only the final output.

A plausible headline result can hide errors in intermediate calculations, units, timing, or assumptions. Validate the calculation chain as well as the final number.

Mistake 4: Treating human approval as a rubber stamp.

Reviewers need access to evidence and the ability to reject, amend, or escalate proposed assumptions. Otherwise, the control exists mainly on paper.

Mistake 5: Confusing model correctness with decision quality.

A model may calculate exactly as specified and still be unsuitable because its assumptions are weak, its evidence is stale, or relevant risks are omitted.

9. A practical implementation sequence

Teams building this capability can start with a narrow, testable scope.

Select one model and document its calculation rules.
Define a schema for a small set of material assumptions.
Require source references for those assumptions.
Validate types, units, required fields, and source availability.
Route material assumptions for human approval.
Run calculations outside the language-model interpretation step.
Implement reconciliation, boundary, regression, and sensitivity checks.
Record model versions, approvals, overrides, and validation outcomes.
Test the workflow against deliberately introduced errors.
Expand only after the failure modes and review burden are understood.

Evaluation should measure more than whether the pipeline completes. Useful measures include unsupported-assumption detection, source-traceability coverage, validation failures caught, false-positive rates, reviewer override frequency, and reproducibility across controlled test cases.

These measures need explicit definitions and representative test data. No performance figure should be claimed without a documented evaluation method.

Conclusion

Human-in-the-loop validation is most effective when it is designed into the system rather than added at the end.

AI can help interpret documents, propose structured assumptions, and explain relationships. Deterministic calculation, independent validation, source traceability, and accountable human approval address different parts of the problem.

The engineering objective is not to eliminate professional judgment. It is to ensure that the judgment is applied to a result whose assumptions, evidence, calculations, and limitations can be inspected.

For a financial model, a plausible number is only the beginning of the validation process.

What Context Does an AI Spreadsheet Copilot Need Before It Can Explain a Workbook?

FeasibilityproAI Analysis — Fri, 09 Oct 2026 06:32:32 +0000

A spreadsheet copilot can explain a number and still get the story behind it wrong. Imagine a real estate feasibility workbook showing a lower development profit than expected. The number is visible, and a language model can describe it in seconds. But explaining why it changed requires more than reading a cell. The answer may depend on construction costs, revenue assumptions, formulas across multiple worksheets, the selected scenario, or the date of the underlying data.

This is where spreadsheet AI becomes an engineering problem rather than simply a language-generation problem. To explain a workbook reliably, a system must understand how its contents relate to one another, distinguish calculated outputs from assumptions, and establish whether the numbers it sees reflect the current calculation state.

A spreadsheet is more than its visible values

A straightforward implementation might extract cell values, convert them into text, and send that text to a language model. For small, simple tables, this can be sufficient. The approach becomes less reliable when a workbook contains multiple worksheets, named ranges, nested formulas, imported data, scenario models, or links between calculations.

Consider a simplified workbook in which Inputs!B2 contains construction cost per square metre, Model!D12 calculates total construction cost, and Summary!C8 reports development profit.

If a user asks why profit has fallen, the system needs to trace the relevant calculation chain. It must determine which formulas depend on the construction-cost assumption, whether that assumption changed, and whether other inputs changed at the same time. Even then, a dependency is not automatically a complete explanation. The fact that a cost input contributes to profit does not establish that it caused the entire decline. The first requirement is a structured representation of workbook context, not a longer prompt.

Build a model of the workbook before generating an answer

The system needs to preserve more than cell addresses and displayed values. It should capture worksheet structure, formulas, number formats, named ranges, relevant metadata, and the relationships between calculations.

For each cell, a useful representation includes its worksheet and address, stored value, formula where applicable, data type, number format, workbook version, and available source information.

These fields help prevent subtle interpretation errors. A value displayed as 12.5% has a different meaning from a currency amount or a quantity, while a hard-coded assumption should not be confused with a formula-generated result. Formatting can help identify the intended presentation, but it does not establish the business meaning of a number on its own.

Dependencies are equally important. A cell record tells the system what is stored in a location; a dependency record tells it which other cells contribute to that calculation.

For example, a simplified relationship might be:
Inputs!B2 → Model!D12 → Summary!C8

This relationship can be represented as a directed graph, allowing the system to trace upstream inputs from a requested output. Real workbooks are more complicated: formulas can branch, reference other worksheets, use named ranges, or contain constructs the extraction system cannot resolve.

The system should preserve those limitations. An unresolved reference must remain unresolved rather than being silently replaced with an assumed relationship.

Keep extraction, calculation and explanation separate

One architectural mistake is to ask the language model to perform every step: interpret the workbook, calculate the result, diagnose the change, and explain it. A more dependable design separates these responsibilities.

The extraction layer reads workbook structure and records the available evidence. The calculation layer establishes numerical results using an appropriate spreadsheet engine or a separately verified deterministic implementation. The explanation layer uses those results to answer the user's question.

This separation matters because reading a formula is not the same as evaluating it. For example, the openpyxl documentation explicitly states that openpyxl does not evaluate formulas. A system using it can inspect formula expressions, but it cannot assume that the cached result represents a freshly recalculated workbook.

The calculation process should therefore expose its status to the explanation layer. The system needs to distinguish an extracted value from a recalculated result, and a recalculated result from one that has passed the relevant validation checks. These distinctions should be represented as data, not left for the language model to infer.

Give the language model structured evidence

Once the workbook has been parsed and the relevant calculations established, the system can assemble a context package for the requested answer. Suppose a user asks why development profit changed. The package might identify the target cell, its formula, the relevant upstream dependencies, the selected scenario, the workbook version, and the status of the calculation. It should also identify missing evidence, such as an input whose source date is unavailable.

A simplified representation could look like this:
{
"workbook_version": "v17",
"target_cell": "Summary!C8",
"scenario": "Base case",
"formula": "=Revenue-Costs",
"dependencies": [
"Model!D12",
"Model!D18"
],
"calculation_status": "verified",
"evidence_status": "partial",
"limitations": [
"Source provenance for one input is unavailable"
]
}

This is an illustrative example, not output from an actual workbook. Its purpose is to show how a system can communicate what it knows and what remains uncertain. A schema can enforce required fields, permitted status values, and the structure of cell references. The system can then reject malformed responses or flag references that do not exist in the relevant workbook version.

However, valid JSON does not prove that an explanation is correct. Structural validation can establish that an answer follows a contract; it cannot establish that the narrative accurately describes the business logic. That requires separate evidence and validation.
Retrieve context according to the question
Sending an entire workbook to a language model is often inefficient. Large files may contain historical worksheets, unrelated calculations, repeated formatting, and data that has no bearing on the question. Instead, context retrieval should follow the task.

When a user asks what drives a particular output, the system should retrieve the target formula, its relevant dependencies, units, scenario metadata, and available source records. When the question concerns changes between workbook versions, it should compare the relevant formulas, values, and metadata across those versions.

A question about whether an assumption is reliable requires a different set of evidence. The system may need the source, publication date, geography, definition, and available quality checks. The numerical value alone cannot answer that question.

This is where spreadsheet context differs from ordinary text retrieval. The system is not merely searching for related passages. It must identify the correct calculation relationships and select evidence that supports the specific question. Retrieval also needs boundaries. Dependency expansion should be limited to relevant parts of the workbook, and incomplete formula chains should be reported explicitly. A system that cannot resolve every relationship should not imply that it has examined the complete model.

Treat uncertainty as part of the data model

Consider a construction-cost assumption with no recorded source date or geographic reference. The copilot may still be able to explain how the assumption affects development profit. It cannot establish from that workbook alone whether the assumption is current or appropriate for the project. Three questions must remain distinct: what the calculation produces, whether the underlying evidence is reliable, and whether the resulting project outcome is acceptable.

The first can often be answered through model logic. The second requires appropriate supporting evidence. The third involves professional judgment and decision-making beyond the calculation itself. Combining all three into a single confidence score would conceal important differences. Instead, the system should report missing provenance, unresolved references, conflicting inputs, and uncertain calculation freshness in explicit terms. If the workbook does not establish something, the explanation should not invent a plausible answer to fill the gap.

Test the failure cases, not just the successful examples

A spreadsheet copilot may perform well on straightforward questions while failing on the cases that matter most. Testing should therefore examine whether it handles cross-sheet dependencies correctly, distinguishes hard-coded values from formulas, detects stale results, respects scenario selection, and reports missing source information.

It should also be tested against renamed worksheets, broken references, formula errors, ambiguous labels, and mismatches between the workbook version and the evidence supplied to the model.

These tests measure different properties. Retrieval accuracy determines whether the system found the right cells. Calculation correctness determines whether the numerical result is valid under the specified calculation process. Explanation fidelity determines whether the narrative matches the available evidence. Uncertainty handling determines whether the system acknowledges what it cannot establish. A single overall accuracy score can hide failures in any one of these areas.

The implementation should begin with a limited set of workbook structures and question types. Each expansion should follow testing of the new structures and their failure cases, rather than an assumption that support for one workbook implies support for spreadsheets generally.

A practical engineering sequence

A first implementation should start by extracting and normalizing workbook contents. It can then resolve supported formula references, build dependency relationships, establish calculation status, and retrieve the context needed for a particular question.

Only after those steps should the language model generate an explanation. The resulting response should be checked against the supplied evidence, its schema, the relevant workbook version, and the calculation status. Material explanations should remain subject to human review before being used in consequential decisions.

This sequence does not eliminate every error. It makes errors easier to detect, isolate, and investigate because extraction, calculation, retrieval, and explanation have distinct responsibilities.

It also makes limitations visible. If a formula cannot be resolved, a calculation cannot be verified, or source information is missing, the system can report that specific limitation instead of producing a confident but unsupported answer.

Conclusion

The hard part of an AI spreadsheet copilot is not describing a number. It is establishing where the number came from, which assumptions affect it, whether the calculation is current, and what the available evidence can actually support.

That requires structured workbook context, explicit dependency relationships, a calculation process separate from language generation, and validation that goes beyond checking whether a response is well formed.

For financial modelling and real estate feasibility analysis, these distinctions are particularly important. A fluent explanation may sound convincing, but a traceable explanation gives an analyst something they can inspect, challenge, and verify. The objective should not be to make every answer sound certain. It should be to make every answer accountable to the evidence.

Structured Outputs for AI-Generated Financial Models: Schemas Before Spreadsheets

FeasibilityproAI Analysis — Sat, 03 Oct 2026 06:04:37 +0000

Generating a financial model with an LLM is not primarily a spreadsheet-generation problem. It is a data-contract problem. When an LLM is asked to create a financial model directly in Excel, several important decisions can become implicit. What is an input? Which numbers are assumptions? Which values came from external evidence? Which numbers are calculated? What units are being used? Which fields are mandatory?

A spreadsheet can represent all of these things, but it is not necessarily the best place to define the contract between an LLM and a financial-modeling system. A more reliable approach is to first represent the model as structured data, validate that structure, perform deterministic calculations, and only then render the result into a spreadsheet.

Why the spreadsheet should not be the first output

Consider a simple development model with inputs such as gross floor area, saleable area, selling price, construction cost, professional fees, financing assumptions, and development timing.

A prompt such as:
Create an Excel development feasibility model from these assumptions. may produce a workbook that looks reasonable. That does not mean the model is correct.

For example, construction cost might be calculated using gross floor area:

construction_cost = GFA × construction_cost_per_sqm

But another implementation could use saleable area:
construction_cost = saleable_area × construction_cost_per_sqm
Both can result in valid Excel formulas.

The difference is a modelling decision, not a spreadsheet-formatting decision. The same problem occurs with percentages, currencies, time periods, unit conversions, missing assumptions, and the distinction between user inputs and derived values.
The system needs to represent those decisions explicitly before Excel becomes involved.

Start with a structured model specification

A useful intermediate representation can describe the financial model without depending on a particular spreadsheet.
For example:
{
"model": {
"name": "development_feasibility",
"currency": "USD",
"period": "monthly"
},
"inputs": [
{
"id": "gfa",
"value": 25000,
"unit": "sqm",
"source_type": "user_input"
},
{
"id": "construction_cost",
"value": 1800,
"unit": "USD/sqm",
"source_type": "assumption"
}
],
"calculations": [
{
"id": "construction_cost_total",
"formula": "gfa * construction_cost",
"unit": "USD"
}
]
}
The representation is deliberately simple. The important part is that the model's meaning exists independently of the workbook. The application can validate the structure before any spreadsheet is generated. It can also determine whether a calculation references a known input and whether the units and expected data types are consistent.

What a schema actually gives you

JSON Schema is useful because it defines the expected structure of the data. A schema can require that value is a number, that unit is a string, and that source_type belongs to an approved set of values.

For example:
{
"type": "object",
"properties": {
"id": {
"type": "string"
},
"value": {
"type": "number"
},
"unit": {
"type": "string"
},
"source_type": {
"type": "string",
"enum": [
"user_input",
"assumption",
"verified_evidence"
]
}
},
"required": [
"id",
"value",
"unit",
"source_type"
],
"additionalProperties": false
}

This prevents the model from returning something structurally invalid, such as a text description where a numeric value is required. Modern structured-output APIs can use JSON Schema to constrain model responses. OpenAI's current documentation also distinguishes schema-constrained structured outputs from simply requesting valid JSON. But schema validation has a clear limit.

It can establish that:
{
"construction_cost": 1800
}

contains a number. It cannot establish that 1800 is the correct construction-cost assumption for a particular project. That requires evidence or professional judgement. This distinction is important when designing systems for financial modelling.

Separate structural validation from model validation

There should be more than one validation layer. The first layer checks the structure of the response. It can validate required fields, data types, enumerations, object structure, and permitted properties.
The second layer checks whether the proposed model makes sense. It can check units, dependencies, calculation references, period consistency, missing assumptions, sign conventions, and other modelling rules.

A response can pass the first layer and still fail the second. For example, this is structurally valid:
{
"gfa": 25000,
"construction_cost": 1800,
"currency": "USD"
}

But if the calculation engine expects construction cost in USD per square foot, the model has a semantic problem even though every field has the correct basic data type. A schema therefore should not be treated as a financial-model validator. It is one part of the validation system.

Keep deterministic calculations deterministic

LLMs are useful for interpreting natural-language instructions and converting them into structured representations. They are less appropriate as the final authority for calculations that can be expressed deterministically.

Suppose the model specification contains:
gfa = 25,000 sqm
construction_cost = 1,800 USD/sqm
The calculation:
25,000 × 1,800
does not need probabilistic reasoning.

The calculation engine should perform it. This separation makes the system easier to test because the calculation can be evaluated independently of the language model. It also makes changes easier to trace. If the construction-cost assumption changes, the system can identify the affected calculation rather than relying on the LLM to regenerate an entire workbook.

Excel becomes the presentation layer

Excel remains useful because financial professionals can inspect formulas, modify assumptions, test scenarios, and work with a familiar interface. The important design decision is not to remove Excel. It is to avoid making Excel the only representation of the model.
The Excel JavaScript API provides ranges for reading and writing values and formulas. Microsoft's documentation describes Range as the basic object for working with cells and contiguous blocks, with separate values and formulas properties. That means a validated model specification can be translated into a workbook in a controlled way.

For example, the renderer might write an input value to a specific range and write a formula to another range.
const inputRange = worksheet.getRange("B5");
inputRange.values = [[25000]];

const outputRange = worksheet.getRange("B10");
outputRange.formulas = [["=B5*B6"]];

The important point is that the formula is being generated from an already validated model definition. The LLM is not deciding what every spreadsheet cell should contain during workbook construction.

Provenance should be part of the data

Financial models contain different kinds of numbers. A user-provided input is not the same thing as an external market observation. An assumption is not the same thing as a calculated output. Those distinctions should remain visible in the structured representation.

For example:
{
"id": "sale_price",
"value": 4200,
"unit": "USD/sqm",
"source_type": "verified_evidence",
"source_id": "market_source_017"
}
is materially different from:
{
"id": "sale_price",
"value": 4200,
"unit": "USD/sqm",
"source_type": "assumption"
}
The numeric value is identical. The provenance is not. A system should also avoid allowing the LLM to invent source identifiers. If a source identifier represents external evidence, it should come from the evidence layer or from an explicitly supplied source. Otherwise the system can create the appearance of provenance without actually having verifiable provenance.

Do not make the schema a second spreadsheet

There is a temptation to put everything into the schema.
Every cell.
Every formula.
Every formatting property.
Every Excel address.
Every chart.
That creates another problem.
The schema should represent the meaning of the financial model rather than reproduce the entire workbook.
This is useful:
revenue = units × price_per_unit
This is implementation detail:
cell = H47
formula = "=SUM(H31:H46)"
font = "Calibri"
font_size = 11

The first describes model logic. The second describes spreadsheet presentation. Keeping those concerns separate makes the system easier to maintain.

Schema changes should be treated like API changes

The model schema will evolve.
A first version might contain:
gfa
construction_cost
selling_price
A later version might introduce:
gfa
saleable_area
construction_cost
selling_price
phasing
If older model specifications cannot be identified or interpreted after a schema change, reproducibility becomes difficult.
A simple version field can help:
{
"schema_version": "1.2"
}

Schema changes can then be tested in the same way that API changes are tested. Maintain representative model fixtures and validate them whenever the schema or calculation engine changes. This is particularly important when an LLM is involved because the model may produce different structures as prompts, schemas, or model versions change.

What structured outputs do not solve

Structured outputs do not make the underlying financial assumptions correct.

They do not verify market evidence.
They do not determine whether a comparable is appropriate.
They do not establish that a construction-cost assumption is realistic.
They do not replace review of development logic.
They do not make an LLM a financial analyst.
Their value is more specific.
They create a stronger boundary between probabilistic language generation and deterministic software.

That boundary makes the system easier to validate, test, debug, and audit.

The practical rule

For AI-generated financial models, the useful principle is simple. Let the LLM interpret the request and propose a structured representation. Validate that representation before using it. Keep material calculations deterministic. Preserve the provenance of important inputs. Use Excel to expose the resulting model to the professional user. The interesting engineering question is therefore not whether an LLM can create an Excel file.

It can.

The more important question is whether the system can explain what each material number represents, where the number came from, how it was calculated, and which assumptions affect it. That is why structured outputs should come before spreadsheets. AI-Assisted. Human technical review required before publication.

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.