The previous article brought together the current beliefs, aims, design principles and products behind the Finsight initiative. It explained why a governed financial AI foundation is needed, what the initiative is intended to achieve and how the Finsight products support that direction.

This article focuses exclusively on Finsight AI-Foundry.

It is not intended to be a user guide or a detailed product manual. Formal product documentation will be published separately on the Finsight Technologies website.

Instead, this introductory article discusses the main components of AI-Foundry, why they exist, how their responsibilities differ and how they work together to provide a governed foundation for financial AI.

The discussion starts with a simple question:

What foundation does a financial institution need before it can rely on AI for meaningful financial work?

The challenge is not simply access to AI

Calling a language model is no longer particularly difficult.

Modern AI frameworks can connect models to tools, retrieve documents, coordinate multiple steps and generate increasingly sophisticated answers. These capabilities are useful, but they do not by themselves provide the foundations required for reliable financial AI.

A language model may recognise the phrase Interest Rate Payout and produce a plausible description of it. However, that does not mean the model understands how the concept is defined within a particular financial product, which characteristics are important, how it relates to the institution’s business and canonical models, or how it is represented across source systems.

It also does not automatically know which mappings and validation rules apply, whether an observed value is current or historical, or whether the available evidence is strong enough to support the conclusion being presented.

A general-purpose AI framework may allow an agent to call a database, an API or a search tool. But access to a resource is not the same as understanding what that resource represents.

This distinction is particularly important in financial services. The same term may carry different meanings across businesses. The same financial concept may be represented differently across systems. A value may be technically available but unsuitable for the intended use. A plausible explanation may still lack the evidence required to support an operational, financial or regulatory decision.

These problems cannot be solved reliably through prompts alone.

Financial AI needs a governed way to connect financial meaning with operational context, supporting evidence, reusable financial behaviour and bounded execution. It must also allow institutions to incorporate their own systems, terminology and specialised behaviour without weakening the shared foundation.

Finsight AI-Foundry is intended to provide that foundation.

It is not a finished AI application, and it is not another general-purpose agent framework. It provides the semantic, evidence, capability and runtime foundations from which financial institutions can build AI assistants, investigation workflows, data-onboarding solutions and other financial AI applications.

If you are interested, please refer to the previous article, The Belief, Aim, Principles and Products Behind My Finsight Initiative, for the positioning of Finsight AI-Foundry.

From semantic definitions to usable financial context

The Finsight Semantic Foundation defines financial meaning through a semantic model and an extensible repository.

The Semantic Model describes the financial data world through objects, attributes, relationships, rules and actions. These dimensions can be applied across the business, canonical, physical and mapping layers.

The Semantic Repository organises these definitions into reusable and versioned packages. It may contain business concepts, canonical financial structures, physical data models, mappings, transformations, constraints, industry references and client-specific overlays.

Together, the model and repository provide a governed representation of financial meaning.

But declarative definitions are only the starting point. A collection of semantic files cannot resolve its own dependencies, apply client overlays, validate itself as a complete semantic state or answer runtime queries. Applications should also not read a changing collection of source files directly and independently decide how to interpret them.

Financial meaning therefore has to be transformed into a stable runtime product. This is the responsibility of the Semantic Runtime.

Its lifecycle can be summarised as:

Load → Resolve → Validate → Compile → Snapshot → Publish → Activate → Query

The important outcome is not merely a graph or an index. It is an immutable semantic snapshot representing one resolved and validated state of financial meaning.

Capabilities query this snapshot rather than interpreting the repository files themselves. This makes the result more consistent, reproducible and traceable.

If an application explains a financial concept, traces a mapping or assesses the impact of a model change, it should be possible to identify which semantic state was used to produce that result.

The boundary can therefore be expressed simply:

The Finsight Semantic Foundation defines and stores financial meaning.

The Semantic Runtime makes that meaning stable, queryable and usable at runtime.

This separation is deliberate. It allows semantic definitions to remain portable and independently governed, while the runtime technology can evolve without redefining the underlying financial meaning.

Financial behaviour should be exposed as capabilities

Once financial meaning becomes queryable, another design question appears:

How should applications use it?

One approach would be to expose internal runtime services, databases and APIs directly to an AI agent. The agent could then select tools and decide how to combine them.

This may appear flexible, but it creates a weak product boundary.

Applications would need to understand internal implementation details. Different solutions might invoke the same behaviour through different request structures. Permissions, diagnostics, versioning and evidence handling could vary from one tool to another.

AI-Foundry instead exposes reusable financial behaviour through named and typed capabilities.

A capability describes what an operation provides without requiring the consumer to understand how it is implemented.

An application might use a capability to resolve a financial concept, trace a physical field to a canonical attribute, identify applicable rules, compare semantic versions, discover a relevant data asset, retrieve operational context or assess whether data is suitable for a particular purpose.

The implementation behind that capability might use NetworkX, Neo4j, a relational database, an internal API or a proprietary calculation engine. That implementation detail does not need to become part of the consumer contract.

This creates an important separation:

What financial behaviour is provided

from

How that behaviour is implemented

The Capability Kernel maintains this boundary.

It provides the controlled mechanism through which capabilities are registered, discovered, validated and invoked. It also ensures that execution context, permissions, diagnostics and evidence references can be handled consistently.

The Capability Kernel is not a complete AI assistant or workflow engine. It provides the stable execution boundary from which those applications and workflows can be assembled.

Evidence must be produced as part of execution

Financial AI should not treat evidence as an optional list of links added to the end of a generated answer. Evidence needs to be produced and preserved as part of execution itself.

Consider an exception investigation.

A conclusion might depend on a semantic definition, an observation from a source system, the mapping version used, the canonical value produced by that mapping, a replay using a previous version and the result of a deterministic calculation.

These elements do not provide the same type of support. Some are directly observed facts. Some are derived results. Others support an interpretation or hypothesis. They may also relate to different points in time.

The Evidence Runtime provides a consistent way to represent this information. It preserves where the evidence came from, when it was valid or observed, how it was derived and how it relates to the claim or conclusion being presented.

This allows an application to distinguish between a directly verified fact, a derived result, a supported interpretation, a probable explanation, a leading hypothesis and an unsupported claim.

The purpose is not to prevent AI from reasoning with incomplete information.

Interpretation and hypothesis generation are often valuable, especially during investigations. The purpose is to prevent an interpretation from being presented as though it had been directly verified.

The final application can therefore adjust its response to the strength of the available evidence.

It may return a complete answer when the relevant facts have been verified. It may identify a probable cause when the evidence is strong but a final verification step is unavailable. It may present a leading hypothesis when important information remains missing. It may also conclude that the available evidence is incomplete or conflicting.

That decision should not depend solely on how confidently a language model phrases its response.

Adaptive AI still needs bounded execution

Even when an application has access to the right semantics and evidence, its execution still needs to remain bounded.

An AI system can almost always propose another search, another query or another possible explanation. Without explicit constraints, an investigation may continue consuming resources without materially improving the result.

This creates a difficult balance. If every execution path is completely predefined, much of the flexibility of AI is lost. But if execution is entirely open-ended, the system becomes difficult to reproduce, control and operate safely.

AI-Foundry addresses this through Shared Runtime Services. These services provide common support for planning, execution context, dependencies between steps, time and resource budgets, deadlines, retries, stopping conditions, diagnostics and response policy.

The purpose is not to prescribe every workflow in advance. It is to define the conditions within which dynamic execution can take place.

For example, an investigation may stop because the required evidence has been obtained, a deterministic check has confirmed the cause, the remaining evidence is unavailable or the execution budget has been exhausted. It may also stop because continuing would be unlikely to improve the conclusion, the next step requires human judgement or further execution would cross an established operational boundary.

The application can then decide whether to return a complete answer, present a partial result, request additional information or escalate the case for review.

This reflects an important principle behind AI-Foundry:

AI execution can remain adaptive without becoming unbounded.

Planning and reasoning do not need to be fully predetermined, but their execution should still operate within explicit contracts, budgets and stopping conditions.

Connecting meaning to the real financial world

Semantic definitions describe the financial world, but applications must also interact with the institution’s actual operating environment.

Financial data and operational state remain distributed across trading and booking platforms, warehouses and lakehouses, market-data systems, risk engines, workflow platforms, control systems, document repositories and internal APIs.

AI-Foundry does not attempt to replace these systems. Instead, capabilities access them through explicit ports, adapters and trusted handlers. Information retrieved from those environments can then be associated with semantic meaning and represented as evidence.

This makes it useful to distinguish between several related forms of context.

Semantic context explains what a financial object means, how it is characterised, how it relates to other artefacts and which rules apply to it.

Data-discovery context helps identify where relevant information can be found, including the datasets, tables, fields, reports, APIs, owners and platforms through which it is available.

Operational context describes what is, or was, true in the real environment. It may include a booked trade, a configuration version, a workflow state, a calculated value or an observation made by a system at a particular time.

Knowledge context retrieves relevant information from specifications, procedures, regulatory materials, design documents, implementation notes and previous investigations.

Suitability context helps determine whether the available information is appropriate for the intended use.

These forms of context are related, but they are not interchangeable.

Finding a table is not the same as understanding what its fields represent. Understanding a field is not the same as knowing whether its current value is valid. Retrieving a value is not the same as demonstrating that it is suitable for regulatory reporting or an external action.

AI-Foundry brings these perspectives together without collapsing them into one generic retrieval process.

Platform capabilities as a reusable vocabulary

The runtime components provide the underlying technical foundation. Platform capabilities expose reusable operations that applications can compose.

A runtime and a capability are therefore not the same thing. A runtime provides execution infrastructure. A capability provides a specific operation that a consumer can invoke.

This distinction allows AI-Foundry to support different applications without hard-coding those applications into the product core.

A Financial Data Assistant may need semantic resolution, data discovery, operational retrieval and knowledge search.

An Exception Investigation solution may need mapping lineage, historical observations, previous cases and deterministic verification.

A Data Feed Onboarding solution may need source inspection, semantic mapping, quality assessment and data-suitability analysis.

These applications have different objectives, but many of their underlying operations can be reused.

The value of platform capabilities is therefore not simply convenience. They create a consistent and governable vocabulary of financial behaviour across different solutions.

Extensibility without weakening the product core

No shared financial platform can contain every institution’s products, systems, terminology and operating processes. AI-Foundry must therefore support extension.

But extensibility creates its own architectural risk. If every client requirement is added directly to the product core, the platform gradually becomes a collection of institution-specific implementations. If clients must fork the product, they lose the ability to adopt shared improvements cleanly.

AI-Foundry addresses this through two primary extension mechanisms: semantic overlays and custom capability handlers.

Shared semantic packages contain reusable financial meaning. A client overlay can extend those packages with institution-specific applications, schemas, physical fields, mappings, ownership information, local terminology and rules.

The overlay contributes to the resolved semantic state without requiring the shared package to be copied and modified. For example, a reusable canonical representation of an interest-rate payout can remain unchanged while different institutions map it to Murex, Calypso, in-house trading systems or their own data platforms.

This allows shared financial semantics and client-specific representations to evolve independently.

Clients can also introduce new behaviour through stable capability contracts.

The capability remains typed, discoverable, versioned, governed and evidence-aware. A custom handler provides the client-owned implementation behind it.

That handler might use a proprietary API, an internal calculation service, a graph database, a specialist library or institution-specific infrastructure.

Custom handlers are intentionally treated as trusted client-owned extensions. AI-Foundry provides the registration and execution boundary, but the institution remains responsible for the correctness, security, performance, compatibility, testing, deployment and lifecycle of the implementation.

The objective is not to remove responsibility from the client. It is to allow institution-specific behaviour to participate in the same architecture without absorbing every implementation into the shared product core.

Public interfaces should remain lightweight

Client applications and reference solutions can access AI-Foundry through the Python SDK, REST API, MCP or CLI.

These interfaces serve different consumers, but they should not implement different versions of the product.

Their responsibilities should remain limited to transport, authentication context, serialisation, invocation of public services and protocol-specific result handling.

Semantic resolution, evidence construction, capability execution and planning remain inside AI-Foundry.

An AI assistant may invoke capabilities through MCP. A data-engineering workflow may use Python. A client application may use REST. An operator may use the CLI.

The delivery mechanism changes, but the underlying semantic state, evidence model and capability behaviour remain consistent.

Keeping these bindings lightweight prevents business logic from becoming fragmented across multiple integration layers.

A governed foundation for financial AI

The central challenge of financial AI is not simply giving a model access to more tools. It is establishing a reliable relationship between financial meaning, operational reality, supporting evidence, reusable behaviour and bounded execution.

Finsight AI-Foundry establishes that relationship through its Semantic Foundation, Semantic Runtime, Evidence Runtime, Capability Kernel, Shared Runtime Services, extension points and public interfaces.

This does not eliminate the need for models, applications, workflows or existing financial systems. It gives them a governed financial foundation on which to operate. AI assistants, investigation workflows and data-onboarding solutions can then be built without reconstructing financial meaning, evidence handling and execution controls separately for every use case.

That is the role of Finsight AI-Foundry.

• *AI-Native Financial Data Foundation