AI credit analysis needs evidence before confidence

A fluent summary can make a wrong assumption sound credible. My starting point for credit AI is that a reviewer must be able to identify the basis of a statement and understand what happens when that basis changes.

That requirement shapes the architecture we are pursuing with FINKI. A language model alone does not meet it.

A knowledgebase must preserve disagreement

Consider a fictional deal. The financing plan expects a receipt in June. The contract makes payment conditional on acceptance, and the current schedule places acceptance in August.

The system should show the conflict and its sources. It should not blend the documents into a plausible date.

That requires more than a searchable collection of paragraphs. Contracts, obligations, payments and projects need explicit relationships, version references and information status. A proposed assumption should remain distinguishable from a verified fact.

Sector context changes the questions

Film revenue may depend on rights and delivery materials. An energy project needs different operating and contractual assumptions. A generic label such as "secured revenue" cannot answer both cases.

A taxonomy defines the relevant concepts and relationships. A sector pack specifies the information and checks required. Version both so a reviewer can reconstruct the rules behind an analysis.

Give calculations to defined tools

A model can interpret a clause or draft an explanation. Financial calculations should use specified inputs and a reproducible method. Record the formula version and date. Missing data should produce a visible gap, not an invented number.

Specialist agents then need structured handoffs. A contract agent might identify the acceptance condition; a calculation tool can test the delay; another step can prepare a question for the responsible person.

Each handoff needs sources, affected records, uncertainty, an owner and a rule for when the work becomes stale. It also needs access boundaries. Bank A's agent must not use Bank B's private terms.

Learning needs approval too

A human correction is feedback, not automatically a universal rule. Establish whether it generalises and whether the underlying data may be used for that purpose.

Test proposed changes to models, prompts or rules against known cases, including failures. Approve releases and retain the ability to identify earlier versions. Confidential deal information should not become shared learning material without an appropriate basis and controls.

Evaluate the change, not just the answer

In a demo, ask for the source of a recommendation. Then change the relevant evidence. The earlier work should become visibly outdated where appropriate, and the replacement should be reviewable.

That is a more useful test than confident wording. Use the evaluation checklist.

These are technical design principles, not a claim of autonomous credit approval or proven production-bank performance gains.