DEV Community: FeasibilityproAI Analysis

From Spreadsheet Cells to Dependency Graphs: Tracing What Changes When an Assumption Moves

FeasibilityproAI Analysis — Fri, 06 Nov 2026 06:11:46 +0000

A financial feasibility model may contain hundreds or even thousands of formulas, spread across multiple worksheets and connected through a network of assumptions, intermediate calculations, and final outputs. Although an analyst sees these calculations arranged in rows and columns, the underlying logic is much closer to a software dependency system than a conventional table.

Consider a relatively straightforward development feasibility model. An analyst changes the construction cost rate because updated project information suggests that the original assumption is no longer appropriate. The change does not remain confined to one input cell. It affects the base construction cost, which may influence contingency, total development costs, financing requirements, residual land value, and ultimately the financial indicators used to evaluate the development scenario.

The difficult part is not identifying the cell that has changed. The real challenge is understanding the complete chain of calculations that depends on that cell, determining which outputs need to be recalculated, and explaining the resulting impact without losing the connection to the original workbook.

This becomes particularly important when artificial intelligence is introduced into spreadsheet workflows. A language model may understand a user's question and explain financial relationships in natural language, but that does not automatically mean it can reliably reconstruct every formula dependency in a complex workbook.

A more robust engineering approach is to represent the workbook's calculation relationships as a directed dependency graph. This provides a structured representation of how inputs, formulas, and outputs connect, allowing the system to trace the potential consequences of an assumption change before attempting to explain them.

1. Understanding the Dependency Structure Behind a Financial Model

An Excel workbook is usually designed around the way an analyst wants to organise and review information. Different worksheets may contain development assumptions, construction costs, revenue calculations, financing schedules, cash flows, and investment metrics. This arrangement is convenient for human review, but it does not necessarily communicate the complete calculation structure of the model.

A formula can reference a cell located several worksheets away, while another formula may depend on a named range, a table reference, or an intermediate calculation that is not immediately visible to the person reviewing the workbook. As a result, the physical arrangement of cells is not a reliable representation of the order in which calculations depend on one another.

For example, suppose a development model calculates base construction cost using gross floor area and a construction cost rate. Contingency is then calculated as a percentage of base construction cost, and total construction cost is derived by combining the two values. The resulting amount may feed into a broader development cost calculation, which subsequently affects the residual land value.

The logical relationships can be represented as follows:

Construction Cost Rate
          |
          v
    Base Construction Cost
          |
          v
       Contingency
          |
          v
   Total Construction Cost
          |
          v
   Residual Land Value
          |
          v
   Development Metrics

This representation is useful because it shifts attention away from the location of individual cells and towards the relationships between calculations. Instead of asking where a formula is located, the system can ask which inputs determine its value and which other calculations depend on its result.

Microsoft describes the related behaviour through Excel's calculation and dependency mechanisms, including the way formula dependencies influence recalculation.

2. Representing Spreadsheet Formulas as a Directed Graph

A directed graph provides a natural way to represent these relationships. Each node represents a cell, range, or logical model variable, while each directed edge represents a dependency between two elements.

Suppose a simplified development model contains the following calculations:

Cell / Node	Description	Dependencies
B2	Construction cost rate	Input
B3	Gross floor area	Input
C4	Base construction cost	B2, B3
B5	Contingency rate	Input
C5	Contingency	C4, B5
C6	Total construction cost	C4, C5
C7	Residual land value	Revenue, C6, Finance, Target Profit

The corresponding graph would contain an edge from each precedent to the formula that references it. For example, both B2 and B3 would point towards C4 because the base construction cost depends on both the construction cost rate and gross floor area.

The graph also makes it possible to distinguish between direct and indirect dependencies. A direct dependency exists when one formula references another cell or input directly. A transitive dependency exists when a calculation is affected through one or more intermediate formulas.

This distinction becomes important when an analyst wants to understand the full impact of changing an assumption. If the construction cost rate changes, the system needs to identify not only the immediate calculation affected by the change but also every downstream calculation that depends on it.

Microsoft's Excel JavaScript API provides methods for retrieving formula precedents and dependents, making it possible to inspect these relationships through supported Excel interfaces.

3. Extracting Dependencies from an Excel Workbook

The first engineering challenge is converting workbook formulas into a structured representation of their dependencies.

A practical implementation would begin by identifying worksheets and their formula-containing cells. It would then extract formula expressions, parse their references, resolve those references against the workbook structure, and construct the graph.

A simplified processing pipeline looks like this:

Excel Workbook
      |
      v
Read Worksheets
      |
      v
Identify Formula Cells
      |
      v
Extract Formula Expressions
      |
      v
Parse Cell References
      |
      v
Resolve Named Ranges
and Worksheet References
      |
      v
Construct Dependency Graph
      |
      v
Validate Graph Structure

For example, consider the following Excel formula:

=C4*B5

The formula cell depends directly on C4 and B5. The dependency graph therefore needs two incoming relationships:

C4 ─────┐
        ├────> C5
B5 ─────┘

This is relatively easy to process because the formula contains straightforward cell references. However, a real financial model may contain formulas such as SUM(B2:B20), references to other worksheets, named ranges, structured table references, and functions that construct references dynamically.

These cases require more sophisticated parsing and resolution logic. A simple regular expression that searches formula text for cell addresses may identify some references correctly, but it cannot be treated as a complete formula interpretation system.

The dependency extraction layer should therefore distinguish between identifying formula syntax, resolving workbook references, and determining the relationships that need to be represented in the graph. Keeping these responsibilities separate makes the system easier to test and reduces the risk of silently overlooking dependencies.

4. Identifying the Complete Impact of an Assumption Change

Once the dependency graph has been constructed, the next task is determining which nodes are affected when an input changes.

This can be handled through graph traversal. Starting from the changed input node, the system follows outgoing edges and records every downstream node that depends directly or indirectly on that input.

Consider a simplified dependency map:

from collections import defaultdict, deque

dependencies = {
    "BaseCost": {"CostRate", "GFA"},
    "Contingency": {"BaseCost", "ContingencyRate"},
    "TotalCost": {"BaseCost", "Contingency"},
    "ResidualLandValue": {
        "Revenue",
        "TotalCost",
        "Finance",
        "TargetProfit"
    }
}


def build_dependents(dependencies):
    graph = defaultdict(set)

    for formula, precedents in dependencies.items():
        for precedent in precedents:
            graph[precedent].add(formula)

    return graph


def affected_nodes(changed_node, dependencies):
    graph = build_dependents(dependencies)

    visited = set()
    queue = deque([changed_node])

    while queue:
        current = queue.popleft()

        for dependent in graph[current]:
            if dependent not in visited:
                visited.add(dependent)
                queue.append(dependent)

    return visited


result = affected_nodes("CostRate", dependencies)

print(sorted(result))

The expected output is:

[
    'BaseCost',
    'Contingency',
    'ResidualLandValue',
    'TotalCost'
]

The example demonstrates how a graph traversal can identify the downstream calculations affected by a change to the construction cost rate. The result is an impact map, not a set of recalculated financial values.

That distinction is important because dependency analysis and numerical calculation are two separate engineering responsibilities. The graph identifies which calculations may be affected, while an appropriate calculation engine evaluates the actual formulas and determines the resulting values.

For financial modelling, combining these responsibilities without clearly separating them can create problems. A system might correctly identify every affected formula but still produce an incorrect numerical result if it does not reproduce the workbook's calculation behaviour.

5. Determining the Correct Calculation Sequence

Identifying affected cells is only part of the problem. When the system needs to evaluate formulas in a particular sequence, it must also respect the dependency order.

For a directed acyclic graph, this can be achieved through topological sorting. The algorithm produces an ordering in which every precedent appears before the formula that depends on it.

Python provides a standard-library implementation through graphlib.TopologicalSorter.

from graphlib import TopologicalSorter

dependencies = {
    "BaseCost": {"CostRate", "GFA"},
    "Contingency": {"BaseCost", "ContingencyRate"},
    "TotalCost": {"BaseCost", "Contingency"},
    "ResidualLandValue": {
        "Revenue",
        "TotalCost",
        "Finance",
        "TargetProfit"
    }
}

order = TopologicalSorter(
    dependencies
).static_order()

for node in order:
    print(node)

The resulting sequence respects the relationships defined in the dependency map. Independent inputs may appear in different valid positions, but a dependent calculation will not be placed ahead of its required precedents.

This is particularly useful when building a system that needs to understand calculation order or determine which intermediate results must be available before evaluating a downstream formula.

However, topological sorting should not be confused with spreadsheet recalculation itself. It does not interpret Excel formulas, reproduce the complete behaviour of Excel functions, or handle every workbook-specific calculation feature. It provides a valid ordering for an acyclic dependency structure, while the actual numerical evaluation remains the responsibility of a calculation engine.

6. Handling Circular References and Iterative Calculations

A more difficult situation arises when formulas depend on one another in a circular relationship.

Development finance models provide a practical example. Interest expense may depend on the outstanding debt balance, while the debt balance may depend on project cash flow. If project cash flow also depends on interest expense, the model contains a circular calculation relationship.

A simple topological ordering cannot resolve this structure because there is no valid sequence in which every dependency can be evaluated only after its precedents.

Excel supports iterative calculations for workbooks that deliberately use circular references. These calculations are governed by workbook settings, including iteration limits and convergence-related parameters.

A dependency analysis system must therefore distinguish between an accidental circular reference and an intentional iterative calculation. Treating both conditions as ordinary dependencies would make the resulting graph misleading and could produce an invalid calculation sequence.

A more reliable implementation should identify strongly connected components, report the formulas involved in each cycle, and preserve the workbook's intended calculation semantics when iterative calculations are required.

The objective should not be to eliminate every cycle automatically. Some financial models are deliberately structured around iterative relationships, and replacing those relationships with an arbitrary calculation sequence would change the model's behaviour.

7. Why Excel's Calculation Chain Is Not a Dependency Graph

There is an important distinction in the underlying structure of Excel workbooks that is relevant when developing tools for spreadsheet inspection.

The calculation chain records the order in which formula cells were last calculated. It should not be treated as a complete description of the relationships between formulas and their precedents.

The dependency structure must be understood separately from the calculation sequence. A system that relies only on the calculation chain may therefore obtain information about calculation ordering without reconstructing the complete network of formula dependencies.

This distinction matters when processing .xlsx files programmatically, particularly when the objective is to understand how a change to one input affects the rest of the workbook.

The engineering process should derive the dependency relationships from formula references and workbook metadata rather than assuming that the calculation chain contains everything needed for impact analysis.

8. Integrating Dependency Analysis into an AI-Assisted Spreadsheet Workflow

Once the workbook has been converted into a structured dependency representation, it becomes possible to introduce a language model into the workflow without making the model responsible for reconstructing the entire calculation system independently.

Consider an analyst asking:

"What happens to the residual land value if construction costs increase by 8%?"

A reliable system should interpret this as a request to modify a specific assumption and investigate the consequences of that change. The language model can help understand the question, but the workbook processing layer must determine which input the analyst is referring to and how that input connects to the remaining calculations.

The first stage is request interpretation. The system identifies the proposed change and determines whether the user intends to modify an existing assumption, examine a hypothetical scenario, or simply understand the relationship between two calculations.

The second stage is input resolution. The requested assumption must be matched to a specific workbook cell, named range, or structured model variable. This step should not depend on approximate language-model interpretation alone because two different cells may have similar descriptions but very different financial meanings.

The third stage is dependency analysis. The graph identifies all direct and indirect calculations connected to the selected assumption. This provides the system with a structured understanding of which intermediate calculations and final outputs may be affected.

The fourth stage is numerical recalculation. The relevant calculation engine evaluates the workbook using the changed assumption and applies the workbook's calculation rules. The system should also preserve the original scenario so that the impact of the proposed change can be compared against the starting position.

The final stage is explanation. The language model can use the verified inputs, formula relationships, and recalculated results to describe what changed and why. The explanation should retain references to the relevant cells and formulas so that an analyst can independently inspect the underlying calculations.

This separation of responsibilities is important. The language model interprets the request and communicates the result, while deterministic workbook operations handle reference resolution, dependency analysis, and numerical calculations.

It is one possible architecture for combining AI-assisted interaction with conventional spreadsheet engineering, rather than a description of any particular proprietary product implementation.

9. Technical Limitations That Need to Be Addressed

Although dependency graphs provide a useful foundation, a production implementation must account for spreadsheet features that cannot always be resolved through straightforward formula parsing.

Dynamic references are one example. Functions such as INDIRECT can construct references from text values, which means the actual dependency may not be obvious from the formula's static structure. A parser may identify the function but still be unable to determine the referenced cell without evaluating the relevant expression.

Named ranges create a different challenge. A formula may refer to a defined name rather than a direct cell address, and the system must resolve that name against the workbook's defined-name scope. The distinction between workbook-level and worksheet-level names also needs to be preserved.

External workbook references introduce another complication. A formula may depend on a cell in a separate workbook that is unavailable during analysis. The system should retain the external dependency and identify its resolution status rather than silently treating the missing reference as an ordinary blank value.

Volatile functions require additional consideration because their values may change during recalculation even when conventional input dependencies have not changed. Similarly, dynamic arrays and structured table references can introduce relationships that require more sophisticated workbook interpretation.

Finally, different spreadsheet engines may support different formula functions and calculation behaviours. A dependency graph constructed from an Excel workbook does not automatically guarantee that another calculation engine will reproduce exactly the same results.

These limitations should be recorded as part of the analysis rather than hidden behind an apparently complete dependency map.

10. Establishing a Validation Framework

Before relying on dependency analysis in a financial modelling workflow, the implementation should be tested against a range of workbook structures and calculation scenarios.

The validation process should cover simple direct references as well as more complicated relationships involving multiple worksheets, named ranges, circular references, and external dependencies.

Validation area	Expected behaviour
Direct dependencies	Correctly identifies immediate precedents and dependents
Transitive dependencies	Identifies all downstream calculations affected by an input
Multiple inputs	Preserves every relevant dependency of a formula
Cross-worksheet references	Resolves the correct worksheet and cell address
Named ranges	Identifies and resolves defined names correctly
Circular references	Detects cycles and identifies participating formulas
External references	Reports unresolved external dependencies
Formula modifications	Updates graph relationships when formulas change
Input modifications	Identifies the correct downstream impact scope
Numerical recalculation	Produces results consistent with the selected calculation engine

The final validation area deserves particular attention because a structurally correct graph does not guarantee numerically correct results. A workbook may contain stale cached values, unsupported formulas, incomplete external references, or calculation settings that influence the final output.

For that reason, dependency validation and numerical validation should be treated as separate testing responsibilities. The first establishes whether the system understands the workbook's calculation relationships, while the second establishes whether the calculated results are consistent with the workbook's intended behaviour.

Conclusion: Making Spreadsheet Logic More Transparent

Financial models are often reviewed through their visible outputs, but the reliability of those outputs depends on the assumptions and calculations connected beneath them. A change to one input can influence several intermediate formulas and ultimately alter the financial indicators used to assess a development scenario.

Representing these relationships as a directed dependency graph provides a structured way to understand how that influence travels through the workbook. It also creates a useful foundation for impact analysis, calculation sequencing, validation, and explanation in AI-assisted spreadsheet workflows.

The broader engineering principle is that language models should not be expected to reconstruct complex financial calculations from unstructured spreadsheet content and then independently produce numerical conclusions. Formula interpretation, dependency resolution, and numerical calculation require explicit, testable mechanisms that preserve the relationship between the original workbook and the resulting outputs.

AI can make these systems easier to interact with and can help communicate complicated calculation relationships in a more accessible way. However, the underlying calculation logic must remain inspectable, and the results must remain open to independent verification.

For real estate development professionals, this is more than a technical design consideration. When an assumption changes, the important question is not simply whether a final number has moved, but whether the analyst can trace that movement back through the calculations and understand which assumptions and relationships produced the result.

A financial model becomes more useful when every material output can be traced back to the assumptions, formulas, and dependencies that determine it.

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

FeasibilityproAI Analysis — Tue, 27 Oct 2026 05:34:12 +0000

AI can generate a financial model that looks coherent, contains valid formulas, and produces a plausible result while still being wrong in ways that matter.

A formula can reference the wrong cell. A cost assumption can be expressed in the wrong unit. A revenue schedule can omit a phase. A model can calculate correctly from an unsupported market assumption.

These are different failure modes, and they need different controls. For real estate feasibility models, the objective should not be to ask whether an AI-generated workbook looks correct. It should be to establish which properties can be tested automatically, which assumptions require evidence, and which decisions must remain with a qualified human reviewer.

A useful validation architecture has five layers:

Structural validation
Deterministic calculation checks
Domain and consistency checks
Evidence and provenance checks
Human review and approval

No single layer is sufficient.

1. Separate the output from the evidence

Consider a hypothetical development model with the following inputs:

Site area and developable area
Permitted gross floor area
Unit mix or lettable area
Revenue assumptions
Construction and other development costs
Financing assumptions
Development programme
Exit assumptions

The model calculates development costs, revenue, cash flows, residual land value (RLV), and potentially internal rate of return (IRR).

For example, a model might calculate an RLV of £4 million. That output can be mathematically consistent with the workbook and still be commercially misleading if the revenue assumptions are unsupported or the construction cost basis is outdated. Validation therefore needs to test both the calculation and the justification for its inputs.

2. Layer one: validate the structure before the numbers

Before reviewing financial logic, validate the shape of the generated output. If an AI system is expected to return structured data before creating a workbook, define an explicit contract. JSON Schema is one established option for specifying required fields, data types, and constraints.

See the JSON Schema getting-started guide.
A simplified model input contract might look like this:
{
"project_id": "DEMO-001",
"currency": "GBP",
"site_area_sqm": 5000,
"gross_floor_area_sqm": 12000,
"construction_cost_per_sqm": 1800
}
This is illustrative data, not a market benchmark or a recommendation for a production schema.

A structural validator could check that:

Required fields are present.
Numeric values are actually numeric.
Areas and costs use declared units.
Currency is explicitly identified.
Values fall within defined technical bounds.
Unexpected fields are rejected or handled deliberately.
Missing values are not silently replaced with zero.

The last point is important. Zero and unknown are not equivalent. If a finance rate is missing, substituting zero can make a model appear more profitable. A missing value should normally trigger a validation error or an explicit unresolved status.

Structural validation establishes that the model can be interpreted. It does not establish that the model is economically sensible.

3. Layer two: use deterministic checks for deterministic rules

Rules that can be expressed precisely should not depend on an LLM's judgment. For example, if a model defines construction cost as gross floor area multiplied by construction cost per square metre, the expected calculation is:

\text{GFA}
\times
\text{Cost per sqm}
]
For the hypothetical inputs above:
[
12{,}000 \times £1{,}800 = £21{,}600{,}000
]
A deterministic test can independently calculate the expected result and compare it with the workbook output.
from decimal import Decimal

gfa_sqm = Decimal("12000")
cost_per_sqm = Decimal("1800")
reported_cost = Decimal("21600000")

expected_cost = gfa_sqm * cost_per_sqm

assert expected_cost == reported_cost

This test checks arithmetic for the stated formula. It does not establish that the GFA is permitted, that the cost rate is appropriate, or that the formula captures every relevant cost.

A production implementation should also define tolerances where appropriate, particularly when comparing rounded spreadsheet values or calculations involving floating-point numbers.

Other deterministic checks might include:
Revenue equals the sum of its components.

Total costs reconcile to their component schedules.
Cash flow totals reconcile across periods.
Unit counts and areas reconcile between schedules.
The reported output matches an independently calculated result.
A sensitivity case actually changes the intended input.
Required formula cells are not unexpectedly blank or replaced by constants.

Where possible, use independent calculations rather than simply checking that a formula cell contains a formula. A formula can exist and still be wrong.

4. Layer three: validate model relationships

Many serious errors are not syntax errors or arithmetic errors. They are inconsistencies between parts of the model.

Suppose a development model contains:

120 residential units in the unit schedule
116 units in the sales schedule
Revenue calculated using the sales schedule
Construction costs calculated using the unit schedule

Every formula may evaluate successfully, but the workbook contains a discrepancy that needs resolution.

Domain-level checks can flag conditions such as:

Unit counts that differ across schedules.
Areas that exceed a declared model constraint.
Revenue periods that do not align with the programme.
Cost totals that exclude a populated cost category.
An exit value that uses an inconsistent timing assumption.
A sensitivity scenario that changes revenue but leaves dependent calculations unchanged.
An IRR calculation using a cash-flow range that omits a period.

These checks should be encoded as explicit rules wherever the intended relationship is known.

Some rules require context. For example, whether a particular cost should be included in a development budget depends on the model's scope and conventions. A validator should not impose a universal rule where none exists.

Instead, it should identify the relevant condition, record the rule being applied, and send ambiguous cases for review.

5. Layer four: validate the provenance of assumptions

A financial model can pass every arithmetic test and still fail as an analytical tool.

The reason is straightforward: calculations cannot establish the truth of their inputs.

For every material assumption, a validation system should try to preserve:

The value and unit.
The source or origin of the value.
The source's date and relevant data period.
The geography and asset type, where applicable.
The transformation from source evidence to model assumption.
Any manual adjustment made by the analyst.
The model locations that depend on the assumption.

Consider a construction cost assumption of £1,800 per square metre. A validator might confirm that the figure is numeric, the unit is recorded, and the workbook uses it consistently. Those checks do not establish whether the figure is suitable for the location, asset type, specification, and cost period. That question requires appropriate evidence and professional interpretation.

An LLM may help extract candidate assumptions from documents or explain how a value is used in a workbook. The extracted result should still be checked against its source, and the resulting assumption should remain distinguishable from the underlying evidence.
A useful principle is:
Traceability makes an assumption inspectable. It does not make the assumption correct.

6. Layer five: make human review a defined state transition

Human review should not be an informal final glance after an automated process has already treated the model as complete.

A practical workflow can represent validation explicitly:

The states are illustrative, but the distinction matters. A successful automated test should not automatically mean that a model is approved. Approval should be scoped to a defined version of the workbook, its assumptions, its evidence, and its intended use.
A reviewer should be able to see:

What was generated.
Which automated checks passed.
Which checks failed or were skipped.
Which assumptions lack adequate evidence.
What changed after a correction.
Who approved the model and for what purpose.

If a material input or formula changes after approval, the system should identify which checks need to run again and whether the earlier approval remains valid. This is where versioning and change tracking become part of model governance rather than administrative overhead.

7. Design the exception path before the success path

Validation is often designed around a clean example: the model is generated, every check passes, and the user receives the output. Production systems need to handle less convenient outcomes.

A failed check should produce actionable information. “Validation failed” is less useful than “The unit count in the sales schedule differs from the unit schedule; review the linked inputs before approving revenue.”

Similarly, a warning should not disappear simply because a later stage of the workflow succeeds. For auditability, preserve the check identifier, the model version, the result, the relevant evidence, and the resolution.

8. Measure validation quality without inventing an accuracy score

A single “model accuracy” percentage can hide important distinctions. A workbook might pass every arithmetic test while containing several unsupported assumptions. Another may contain a harmless formatting issue but have fully reconciled calculations and well-documented inputs.

A more useful validation report separates categories:

Structural checks passed or failed.
Deterministic calculation checks passed or failed.
Domain checks passed, failed, or were not applicable.
Assumptions with verified, missing, or conflicting evidence.
Open exceptions and their severity.
Human review status.
The scope and version of the approved output.

If the system is evaluated over time, track false negatives and false positives for individual validation rules against a reviewed test set. Record the test cases, expected outcomes, rule versions, and known limitations.

Do not interpret a high pass rate as proof that the model is correct. It may simply mean that the checks cover only a narrow set of failure modes.

The purpose of validation is to make known risks visible and testable, not to manufacture certainty.

9. A practical implementation sequence

A team introducing validation around AI-generated financial models does not need to automate every review step at once.

A sensible sequence is:

Define the contract. Specify the required inputs, output fields, units, and missing-value behaviour.
Write deterministic tests. Start with totals, reconciliations, formula ranges, and independent calculations.
Add domain checks. Encode known cross-schedule relationships and clearly defined constraints.
Track provenance. Associate material assumptions with sources, dates, units, and transformations.
Introduce exception handling. Make failures explicit and prevent unresolved material issues from being silently treated as passed.
Define human approval. Record the reviewer, workbook version, purpose, and outstanding qualifications.
Build a regression suite. Retain representative valid and invalid examples and rerun the checks when the generation logic or validation rules change.

The test suite should include deliberate failures, not only successful examples. Examples might include missing finance assumptions, inconsistent unit counts, a formula referencing the wrong period, and a source whose geography does not match the project.

This helps test whether the validation process detects the intended problem rather than merely accepting a plausible-looking output.

Conclusion

Human-in-the-loop validation is not a person checking an AI result after the important work is finished. It is a system design in which deterministic rules handle deterministic questions, domain checks expose inconsistencies, evidence is kept separate from assumptions, and a human reviewer remains accountable for unresolved judgments.

For financial modelling, that distinction is material. A workbook can be well-formed without being economically sound, mathematically consistent without being supported by market evidence, and ready for review without being ready for a decision.

The objective is not to make every AI-generated model look trustworthy. It is to make the model's logic, assumptions, limitations, and unresolved issues sufficiently visible that a professional can challenge it before relying on the result.

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.