Reference architecture

The workflow is the unit of governance: which activity is permitted, which data it may use, who decides, and what evidence survives. This addendum develops the four-tier framework in Governed Autonomy I into a proposed architecture for AI-assisted workflows in financial services. Periodic client review provides the running example.

The contribution is a design argument connecting policy, operational objects, action permissions and evidence. This working research specification does not report a deployed bank system, conformance testing or independent validation. The worked example uses fictional records throughout.

Controls described here are architectural proposals. An institution would establish their applicability, ownership and evaluation criteria in its own setting. External requirements, supervisory expectations and voluntary design choices retain their separate status.

Three execution tiers share governance configuration. The Control Plane manages workflow state and access decisions. The LLM Workflow Layer prepares material using a large language model. The Governed Semantic Layer defines the objects and actions available to bounded agents. A fourth tier, the governance wrapper, supplies the policies, schemas and approvals that constrain their operation.

Tiers describe components. Adding a component does not establish institutional readiness to use it. Progression depends on the proposed governance gate and evidence that the relevant controls work.

The LLM layer separates trusted workflow instructions from source material, restricts model routes and checks output structure and source references. These controls reduce particular failure paths; input sanitisation cannot eliminate prompt injection, and a valid output schema cannot establish factual accuracy. The person responsible for a consequential decision needs access to the underlying evidence and unresolved issues.

An ontology defines the entities, relationships and permitted actions in a domain. The proposal separates operational banking objects from governance definitions, then connects them through stable identifiers. Within that arrangement, three layers distinguish source requirements, institutional interpretation and the objects on which a workflow acts.

This is an author-developed research model. Its supervisory domain models concepts from Monetary Authority of Singapore (MAS) publications; it is neither a MAS-authored ontology nor an official interpretation. A populated regulatory knowledge base, verified provision mappings and an executable policy model are not supplied with this draft.

Three connections carry the design. The AI component identifier links a workflow to its inventory and risk assessment. The action type links a proposed operation to its permission and approval conditions. The declared purpose links a data request to the approved use and permitted subset. Source records retain their own provenance and access conditions.

Each source mapping records its citation, relevant scope, reviewer and interpretation. Binding rules, supervisory guidance, consultations, industry methodology and assurance standards remain distinguishable. An unresolved applicability question remains unresolved until reviewed; it does not silently become permission to act.

Version history separates when a source or policy takes effect from when the institution records its interpretation. Corrections preserve earlier versions so that a reviewer can recover the information available at a past decision. Proposed changes to schemas and mappings pass through named approval before they affect runtime permissions.

The design draws on established work. KAoS demonstrates ontology-based policy representation and enforcement. FIBO provides shared financial concepts. The research question here is how to connect such approaches to institution-specific approval boundaries and decision evidence.

The proposed runtime resolves identity, purpose and permission before each governed action. A decision may allow, restrict, deny or escalate a request. If the information needed to authorise an action is indeterminate, that action remains blocked while the uncertainty is resolved. This is a design choice informed by resource-specific authorisation in NIST SP 800-207.

A decision record identifies the actor, action, policy version, source versions, approval scope and outcome. Model-assisted steps also retain the prompt version, model identity, relevant invocation settings, output and validation result. Provenance links connect an output to the inputs and people involved in producing it, following the distinction between entities, activities and responsible agents in W3C PROV-DM.

Hashes and signatures can help detect alteration of retained records. They cannot recover missing content or establish that a source was true. Reconstructing a decision requires the underlying evidence, policy and schema versions, trustworthy access to those records, and defined retention and key-management arrangements. Re-running a model is not guaranteed to reproduce its original response.

A transactional outbox can commit local state and an intent to send in the same database transaction. That boundary does not make the external action and local audit record atomic. Delivery can fail, repeat or have an uncertain outcome. The proposed design therefore requires recorded attempts, idempotency controls where available, and reconciliation before uncertain actions are retried. These limits follow the transactional outbox pattern.

Workflow decisions, system changes and sensitive source content have different access and retention needs. The design keeps their records linked while permitting separate access controls. The evidence available to a particular reviewer depends on that reviewer’s authority and the relevant purpose; the architecture does not presume unrestricted supervisory access.

A human approval is useful only if the reviewer can inspect the decision, its sources and its unresolved conditions. The proposed workbenches bring that material together around compliance and relationship-management tasks. They share workflow, evidence and approval components, with views organised around each role’s responsibilities.

Approval attaches to the content and scope reviewed. A material change to the draft, recipient, purpose or applicable policy triggers a new check. A halt control stops further authorised activity; it cannot recall an external action already completed. Outstanding attempts still need resolution.

This periodic client review uses fictional records, roles and policy identifiers. It is an authored trace of the proposed decision logic, not an observed bank workflow or a software test result. No model is invoked and no client communication is sent by this example.

Stipulated institutional policy

POLICY-DEMO-01 v1 permits preparation from an authorised fact-find and portfolio snapshot, with a customer relationship management (CRM) record used to check consistency. It reserves the suitability determination to the relationship manager. Unresolved source discrepancies block client release. The current draft, recipient and purpose require explicit approval; a changed draft requires fresh approval. Compliance verification and a resolved delivery outcome precede finalisation.

These conditions are assumptions of the fictional institution, not claims about a particular MAS rule. For this example, the current fact-find records a moderate risk profile while the CRM record says high. The relationship manager is stipulated to establish that the CRM value is stale, document the reason and request correction before approving the revised communication.

Expected decisions under the example policy

Each case exposes a different boundary. Expand a case to inspect the request, expected decision and evidence the design would retain.

The trace illustrates where authority and evidence belong. It does not establish the accuracy of a suitability judgement, the completeness of regulatory coverage, resistance to adversarial inputs or reliability under concurrent changes and delivery failures. Those require separate evaluation.

The next evaluation step is to turn observable design properties into executable checks: unauthorised inputs remain inaccessible; unresolved cases remain blocked; approvals cannot be reused for changed content; retries do not create duplicate effects; and retained evidence supports an independent reconstruction of a decision. No results for those checks are claimed here.

Open questions include the accuracy of source mappings, ontology change control, reviewer workload, false escalation rates, the quality of model outputs and recovery from partial failure. Implementation choices and comparative measurements remain open.

A further research horizon considers agents acting within a delegated authority envelope with greater reliance on outcome accountability. Bonding, resolution and the allocation of legal responsibility remain research questions for subsequent work. This draft supplies no deployment claim or assurance that the H1–H3 design can support those extensions without substantial change.

The sources below inform specific design choices. They do not validate or endorse this architecture. External links were checked on 7 September 2026.

1. Pesa, A. (2026). Governed Autonomy: How Private Banks Can Industrialise AI Within Regulatory Boundaries. Governed Autonomy, 25 March. The parent paper supplies the framework, capability horizons and periodic client review exemplar.
2. Uszok, A., et al. (2008). New Developments in Ontology-Based Policy Management: Increasing the Practicality and Comprehensiveness of KAoS. IEEE Workshop on Policy. Sections 3–4 describe the policy architecture and ontology-based policy representation.
3. EDM Council. Financial Industry Business Ontology (FIBO). Reference vocabulary for financial concepts and relationships; cited as prior art, without claiming FIBO conformance or a completed integration.
4. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207, August. Informs explicit resource access decisions; it does not establish a Singapore regulatory obligation for this design.
5. Moreau, L., and Missier, P., eds. (2013). PROV-DM: The PROV Data Model. W3C Recommendation, 30 April. Supplies the provenance distinction between entities, activities and responsible agents.
6. Richardson, C. Pattern: Transactional outbox. Microservices.io. Explains the local transaction boundary, separate message relay and duplicate-delivery considerations.

Cite this addendum

Pesa, A. (2026). Reference architecture: Governed Autonomy I. Working draft v0.1, 7 September 2026. Governed Autonomy. https://governed-autonomy.com/papers/governed-autonomy-i/reference-architecture/

Version 0.1 is the first dated web draft of this addendum. Its version and research status are separate from the published parent paper.