Financial AI needs a decision record that customers can edit.

A financial assistant can sound attentive while leaving the customer with a difficult question: which parts of this conversation now count as instructions? Exploring an alternative, correcting a date and authorizing an action are different acts. A useful interface should keep those distinctions visible after the conversation moves on.

An October 16, 2026 preprint compares risk-input and sampling variation across seven models and 800 profiles; client outcomes remain unmeasured. Paper

Open Market Notes proposes a customer-editable decision record. This is an original product-design argument, not a tested intervention. Its central question is practical: when a customer changes one important fact, can they see which conclusions must be reconsidered, and which permissions have stayed exactly as they were?

A conversation needs more than a transcript

A transcript preserves words, but it does not necessarily preserve their status. “Perhaps next summer” could be a tentative idea, an answer about timing, or a quotation from somebody else. If software stores all three as the same customer preference, a later summary can look coherent while describing a plan the customer never adopted.

The SEC's robo-adviser bulletin notes that recommendations depend on the information requested and received. Bulletin

Our proposed record would distinguish what the customer stated, what the service inferred, and what remains unknown. It would also separate the subject of a statement from its scope. Wanting flexibility for one planned expense does not, by itself, describe the person's attitude toward every other financial goal. A local correction should not silently rewrite a global profile.

The distinction is especially important when a service remembers earlier conversations. Memory should make a correction easier to carry forward. It should not make the customer fight an old summary that reappears whenever a new session begins.

A hypothetical move makes the problem concrete

Consider a fictional customer, Lin, discussing money set aside for a move. Lin initially says the move is eighteen months away, then corrects the deadline to eight months. Later, Lin asks what the planning discussion would look like if the move were delayed by a year. No account is connected, and no transaction is requested in this example.

A poorly specified interface could overwrite the eight-month deadline with the hypothetical delay. Another could preserve the original eighteen-month figure in a background summary even while acknowledging the correction in chat. Both failures concern the meaning and persistence of information before any question about choosing a financial product arises.

In our proposed interface, the confirmed deadline remains eight months. The delayed-move scenario appears in a separate comparison, visibly labeled exploratory. Conclusions that relied on the eighteen-month deadline become marked for review. When Lin closes the comparison, the service returns to the confirmed plan without treating exploration as consent to change it.

The record need not resemble an engineering console. A compact panel could show six things: the question being explored; the relevant statement and its source; whether it is confirmed, assumed, disputed or withdrawn; the goal it applies to; the conclusions that depend on it; and when the customer last confirmed it. These fields are our proposed design, not a checklist prescribed by the cited sources.

Explanations should point to actual records

W3C's PROV data model distinguishes entities, activities and agents when describing provenance. Specification

That provides a limited technical reference point. Our additional requirement is customer-facing: selecting “Why did this change?” should reveal the recorded input change and the affected draft, rather than merely request a fresh explanation from the language model. A plausible explanation generated afterward does not establish which information the system actually used.

This does not require exposing hidden model reasoning. The service can record the documents and input fields supplied to a calculation, the calculation version, and the resulting draft. Where it cannot determine whether a field affected a conclusion, it should say that the conclusion needs review rather than invent a precise causal account.

Editing the active record also needs a clear meaning. Removing an assumption from future planning is different from deleting every historical record. A customer should be told which action occurred. Likewise, reverting a draft is not a promise that a completed real-world transaction can be reversed. The interface must not borrow the language of an undo button for an outcome it cannot undo.

Three tests for whether correction really works

We suggest three product tests, each with an explicit expected behavior. First, explore several hypothetical deadlines, close those branches and start a new session. The confirmed deadline should survive. The test fails if an exploratory value becomes the live plan without a recorded customer decision.

Second, correct an input that appears in a chat summary, a planning worksheet and a saved draft. Check all three surfaces. The test passes only if the new value propagates where appropriate and dependent conclusions are refreshed or flagged. A polite acknowledgment in the chat window is insufficient.

Third, dispute an inference without supplying a replacement. Lin might say, “You cannot assume that about my move.” The system should be able to retain an unknown value and explain what remains unresolved. If its form demands a confident answer before the customer can proceed, the form itself is manufacturing certainty.

Measure the effort required to complete these tests. Count how often a withdrawn assumption returns, how many steps a correction takes, and whether a customer can identify the current confirmed version. Report the denominators and test conditions. These are proposed evaluation measures, not results we have obtained or established industry benchmarks.

The strongest objection is additional friction

More records can mean more screens, more personal information retained and more opportunities to misunderstand a label. A service that asks customers to approve every harmless wording change could train them to click through the one change that matters. Exhaustive disclosure can become another form of opacity.

The answer is selective visibility. Show changes that alter a goal, a constraint, a substantive conclusion or an authorization. Keep routine wording edits in the background. Offer a short explanation first, with the underlying record available on request. Do not interpret a customer leaving the screen as confirmation.

There is also a legitimate competing interpretation of inconsistent outputs: the customer may be seeking a range of possibilities. Forcing every exploratory conversation into one persistent answer would defeat that purpose. The aim should therefore be to preserve the boundary between exploration and commitment, not to minimize every difference between drafts.

A conventional rules-based service could implement much of this design. The proposal does not depend on a more powerful language model. Nor does a tidy record establish that the financial reasoning is sound. A system can accurately document a poor conclusion; provenance and correctness need separate evaluation.

A correction needs somewhere to go

The CFPB's 2023 chatbot report warns about customers being trapped without access to human support. Report

For our proposed service, escalation should carry the disputed statement, the current version and the customer's requested correction. A human reviewer should not have to reconstruct the issue from a long chat, and the customer should not have to repeat unrelated financial details. The service should identify who owns the review and distinguish a received request from a resolved one.

Data minimization matters here. A decision record should retain what is necessary to understand the disputed conclusion, with access and retention rules appropriate to the service. It should not become an excuse to collect every available detail about a household. A customer-editable interface is useful only if the underlying system respects the same boundaries.

Control is something a customer can exercise

The proposed tests would establish whether a product handles certain corrections and exploratory scenarios as designed. They would not establish better returns, suitability for a particular person, or compliance with every jurisdiction's rules. Those questions require different evidence and qualified review.

Accuracy alone does not settle who has authority. A service can explain why it questions a proposed change, identify conflicting facts or decline to provide a conclusion it cannot support. But it should make that disagreement explicit. Quietly replacing the customer's stated goal with the service's preferred goal would conceal a decision about who gets to decide.

Still, the design question is worth asking now. Customers should be able to inspect the version of their circumstances that a financial AI is using, correct it without starting over, and explore alternatives without accidentally adopting them. The meaningful promise is not that the assistant never changes its answer. It is that the customer can understand what changed, challenge it, and retain control of what happens next.

This article discusses product design and evaluation. It is not investment advice.