OpenIBank Course

Model risk and regulatory governance

How OpenIBank should evaluate, document, and promote finance adapters.

Domain hubEvaluation snapshot

Learning Objectives

What this lesson should make precise

01

Name the core abstraction and its failure modes.

02

Translate the concept into a Maple/Hermon proposal contract.

03

Define at least one evaluation case that can fail the model safely.

Tutorial Flow

How this lesson becomes a demo and training target

Each tutorial is written as a user education path and a model-improvement artifact. The diagram shows how the idea moves into a lab, a typed contract, an eval gate, and then a Hermon/MapleAI demo route.

01

Concept

Model inventory

02

Applied Lab

Applied lab: Model risk and regulatory governance

03

Output Contract

adapter_version, eval_report, known_failures, deployment_scope

04

Eval Gate

Does the answer separate model proposal from deterministic execution?

05

Demo Route

OpenIBank training and public model checks

01

Model inventory

Each adapter needs base model, training data class, eval status, known limitations, deployment scope, and rollback path.

  • Inventory adapter.
  • Document scope.
  • Record limitations.

02

Risk management frame

Regulators increasingly focus on AI governance, model risk, third-party dependency, operational resilience, and explainability. Maple should make those concerns concrete in receipts.

  • Explain decisions.
  • Track dependencies.
  • Audit model changes.

03

Promotion gate

A finance adapter should not serve production unless it passes refusal probes, required key checks, and domain-specific scenario tests.

  • Probe unsafe prompts.
  • Require risk_controls.
  • Fail closed on missing read-only.

Lab

Applied lab: Model risk and regulatory governance

Define a model-risk record for Hermon Finance that documents adapter version, eval score, failure cases, and deployment scope.

Expected result

  • A typed JSON-style proposal rather than free-form advice.
  • Clear authority boundaries and denied operations.
  • A test or rubric that decides whether the proposal is deployable.

Evaluation

How Maple would grade this work

Rubric

  • Does the answer expose assumptions instead of hiding them?
  • Does the answer separate model proposal from deterministic execution?
  • Does the answer produce artifacts that can be tested, reviewed, and rolled back?

Output contract

adapter_version, eval_report, known_failures, deployment_scope, rollback_plan

Use this lesson as training direction

A strong lesson gives users a mental model and gives Hermon a sharper target for examples, probes, and demo prompts.

View evalsDomain hub