OpenIBank Course

Finance model boundaries

What Hermon Finance may do, what it must not do, and how to encode that boundary.

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

Operations, not control

02

Applied Lab

Applied lab: Finance model boundaries

03

Output Contract

data_access, risk_controls, audit_receipts, approval_gates

04

Eval Gate

Does the answer separate model proposal from deterministic execution?

05

Demo Route

OpenIBank training and public model checks

01

Operations, not control

Hermon Finance can prepare an operational proposal. It must not move money, execute settlement, auto-clear AML cases, or choose trades for a person.

  • Summarize allowed.
  • Recommend review allowed.
  • Execute denied.

02

Read-only data

Finance data access should default to read-only connectors with source IDs, timestamps, hashes, and scope limits.

  • Data source IDs.
  • No credential echo.
  • No write scope.

03

Human gates

Any regulated consequence should route through approval gates. The model can prepare packets; the kernel and humans decide.

  • Approval queue.
  • Policy kernel.
  • Receipt trail.

Lab

Applied lab: Finance model boundaries

Create a proposal for an OpenIBank reserve analyst that can read attestations and ledger summaries but cannot move funds.

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

data_access, risk_controls, audit_receipts, approval_gates, denied_actions

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.