Skip to content
Arbitex Docs

Model Risk Management

The Arbitex Model Registry is the central inventory for all AI models your organization uses through the platform. It provides risk tier classification aligned to OCC SR 11-7, a structured validation status lifecycle with immutable audit history, automatic discovery from the audit log, and first-class integration with the Policy Engine’s model_risk_tier condition. This feature ships in platform-0056.

Core concepts

Section titled “Core concepts”

Model registry

Section titled “Model registry”

The model registry stores metadata for every AI model in use — whether accessed through the cloud gateway, an on-premises Outpost, or discovered automatically from audit events. Each registry entry captures:

  • Model identifier (model_id) — provider-assigned ID (e.g., gpt-4o, claude-3-5-sonnet-20241022, llama-3.1-8b-instruct)
  • Provider — the AI vendor or hosting infrastructure
  • Display name — human-readable label for the model
  • Risk tier — classification per OCC SR 11-7 guidance (critical, high, medium, low, or unclassified)
  • Validation status — lifecycle state of formal model validation
  • Owner — team or individual accountable for this model entry
  • Description — free-text documentation of the model’s purpose and scope
  • Approved use cases (approved_use_cases) — JSONB list of sanctioned application contexts
  • Restrictions (restrictions) — JSONB dict of constraints that apply when validation status is conditional
  • Timestamps — created_at and updated_at

Registry entries have a unique constraint on (model_id, provider). Attempting to register the same model ID under the same provider twice returns an error.

Registry entries are used by the Policy Engine to enforce model_risk_tier conditions at request time, giving you governance over which users and groups may access models at each risk level.

OCC SR 11-7 risk tier alignment

Section titled “OCC SR 11-7 risk tier alignment”

OCC SR 11-7 (“Supervisory Guidance on Model Risk Management”) requires financial institutions to classify models by the materiality of their use. Arbitex maps directly to SR 11-7 risk categories using the following RiskTier enum values:

Enum value Tier OCC SR 11-7 alignment Typical use cases
unclassified Default Not yet risk-assessed Models discovered from audit log before triage
critical Tier 1 High-risk, strictest controls Credit scoring, fraud detection, algorithmic trading, regulatory capital models
high Tier 2 Enhanced controls, full validation lifecycle Customer segmentation, AML screening, risk appetite models
medium Tier 3 Standard controls and validation requirements Internal analytics, process automation, summarization in regulated workflows
low Tier 4 Lightest review cadence Internal productivity tooling, sandboxed R&D, non-consequential summarization

Tier assignment is the first step in model governance. Once assigned, a model’s tier determines which validation steps are required before the model may be used in production, and which policy rules apply to it at request time.

Validation status workflow

Section titled “Validation status workflow”

Every model in the registry carries a validation_status field that tracks the lifecycle of formal model validation. Admins update this status using the Status Transition API as validation progresses.

stateDiagram-v2
    [*] --> unclassified : registered / discovered
    unclassified --> under_review : submit for review
    under_review --> approved : validation passed
    under_review --> conditional : approved with constraints
    under_review --> unclassified : returned (insufficient info)
    approved --> conditional : constraints applied
    approved --> deprecated : model sunset
    conditional --> approved : constraints lifted
    conditional --> deprecated : model sunset
    deprecated --> under_review : reactivation
Status Meaning
unclassified Created but not yet submitted for validation review. Default for newly registered and auto-discovered models. Not approved for production use.
under_review Active validation in progress. Model is under assessment by the model risk team.
approved Validation complete. Model approved for production use at its assigned risk tier.
conditional Approved with constraints. Permitted use is limited to the contexts defined in the restrictions field.
deprecated Model retired. Policy Engine routing should be blocked for deprecated models. Can be reactivated to under_review if needed.

Allowed state transitions

Section titled “Allowed state transitions”

The platform enforces a strict state machine. Invalid transitions return HTTP 422. Attempting to transition to the current status returns HTTP 409.

From Allowed transitions
unclassified under_review
under_review approved, conditional, unclassified
approved deprecated, conditional
conditional approved, deprecated
deprecated under_review

Status transitions API

Section titled “Status transitions API”

Transition a model’s status

Section titled “Transition a model’s status”
POST /api/v1/admin/models/{entry_id}/status

Request body:

{
  "status": "approved",
  "reason": "Passed full validation review per SR 11-7 checklist"
}
Field Type Description
status string Target status. Must be an allowed transition from the current status.
reason string Required narrative explaining the transition. Written to the immutable approval log.

Response 200 OK — returns a StatusTransitionResponse containing:

  • The updated ModelRegistryResponse entry
  • An immutable ApprovalLog record written at transition time

Invalid transition: HTTP 422. Same-state transition: HTTP 409.

View status history

Section titled “View status history”
GET /api/v1/admin/models/{entry_id}/status/history

Returns a paginated ApprovalLogListResponse ordered by changed_at DESC. Each log entry contains:

Field Type Description
id UUID Unique log record ID
registry_entry_id UUID FK to the model registry entry
user_id UUID Admin who performed the transition
old_status string Status before the transition
new_status string Status after the transition
reason string Narrative provided at transition time
changed_at ISO 8601 Timestamp of the transition

Approval log records are immutable — they cannot be edited or deleted, providing a tamper-evident audit trail for SR 11-7 examination.

Auto-discovery from audit log

Section titled “Auto-discovery from audit log”

The platform automatically populates the model registry by scanning the audit log for AI request events. Discovery reads model_id and provider fields from audit events and creates new registry entries for any (model_id, provider) pair not already present.

Newly discovered models are assigned:

  • risk_tier: unclassified
  • validation_status: unclassified

On-demand discovery

Section titled “On-demand discovery”
POST /api/v1/admin/models/discover

No request body is required. The endpoint scans the audit log for distinct (model_id, provider) pairs not present in the registry.

Response 200 OK:

{
  "discovered": 7,
  "already_registered": 12,
  "entries": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "model_id": "gpt-4o-mini",
      "provider": "openai",
      "display_name": "gpt-4o-mini",
      "risk_tier": "unclassified",
      "validation_status": "unclassified",
      "owner": null,
      "created_at": "2026-03-14T10:00:00Z",
      "updated_at": "2026-03-14T10:00:00Z"
    }
  ]
}
Field Description
discovered Number of new registry entries created in this run
already_registered Number of (model_id, provider) pairs found in the audit log that were already in the registry
entries Array of newly created ModelRegistryResponse objects

Scheduled discovery

Section titled “Scheduled discovery”

In addition to on-demand discovery, the platform runs an automatic background discovery job on a 24-hour loop, with the first run occurring 24 hours after application start. This ensures that new models appearing in the audit log are surfaced in the registry within one business day without requiring manual intervention.

After any discovery run — on-demand or scheduled — review newly created entries in the Admin portal and assign appropriate risk tiers before use in production.

Managing the model registry

Section titled “Managing the model registry”

Viewing the inventory

Section titled “Viewing the inventory”

Navigate to Admin > Model Registry in the Cloud Portal to view all registered models. The inventory page shows:

  • Model name and provider
  • Risk tier badge
  • Validation status badge
  • Owner assignment
  • Last used date (from audit log)
  • Quick-action links to edit or initiate a status transition

Use the filter controls to narrow by tier, validation status, or provider.

Registering a model manually

Section titled “Registering a model manually”
POST /api/v1/admin/models

Request body:

{
  "model_id": "claude-3-5-sonnet-20241022",
  "provider": "anthropic",
  "display_name": "Claude 3.5 Sonnet (Oct 2024)",
  "risk_tier": "high",
  "validation_status": "unclassified",
  "owner": "[email protected]",
  "description": "Primary conversational model for customer-facing workflows",
  "approved_use_cases": ["customer_service", "internal_qa"],
  "restrictions": {}
}

The (model_id, provider) pair must be unique. Duplicate registrations return an error.

Updating a model entry

Section titled “Updating a model entry”
PUT /api/v1/admin/models/{id}

Use this endpoint to update owner, description, display name, approved use cases, or restrictions. To advance the validation_status, use the Status Transition API instead — direct status updates via PUT do not write approval log records.

Exporting the inventory

Section titled “Exporting the inventory”
GET /api/v1/admin/model-inventory-export

Query parameters:

Parameter Values Default Description
format json, csv json Output format

The export includes the following fields for every registry entry:

Field Type Description
model_id string Provider-assigned model identifier
provider string AI vendor or hosting infrastructure
display_name string Human-readable model label
risk_tier string critical, high, medium, low, or unclassified
validation_status string Current lifecycle status
owner string Assigned owner (email or team identifier)
description string Free-text documentation
approved_use_cases JSONB list Sanctioned application contexts
restrictions JSONB dict Constraints for conditional approvals
created_at ISO 8601 Registry entry creation timestamp
updated_at ISO 8601 Last modification timestamp
usage_30d integer Number of audit log events in the last 30 days
usage_90d integer Number of audit log events in the last 90 days
last_used_at ISO 8601 or null Timestamp of most recent audit log event for this model

The CSV and JSON exports contain identical fields. Use format=csv for import into GRC platforms or SR 11-7 examination submissions.

Policy Engine integration

Section titled “Policy Engine integration”

The model registry integrates directly with the Policy Engine through the model_risk_tier condition type. This lets you write rules that govern access based on a model’s registered risk tier at request evaluation time.

model_risk_tier condition

Section titled “model_risk_tier condition”

The model_risk_tier condition uses list membership — you provide a list of tier values, and the condition matches if the requested model’s tier is in that list.

{
  "conditions": {
    "model_risk_tier": ["critical", "high"]
  }
}

This condition matches any request where the model’s registered risk_tier is either critical or high.

Available actions

Section titled “Available actions”

Policy rules matching a model_risk_tier condition can trigger the following actions:

Action Description
CANCEL Terminate the request immediately
ROUTE_TO Redirect the request to a different model or endpoint
PROMPT Present a confirmation or disclosure prompt to the user
ALLOW_WITH_OVERRIDE Permit the request but require an override acknowledgment

Example — cancel requests to critical and high-risk models for non-authorized users:

{
  "name": "Block critical and high-risk models",
  "conditions": {
    "model_risk_tier": ["critical", "high"]
  },
  "action": "CANCEL"
}

Example — prompt users before accessing medium-risk models:

{
  "name": "Disclosure prompt for medium-risk models",
  "conditions": {
    "model_risk_tier": ["medium"]
  },
  "action": "PROMPT"
}

Combine model_risk_tier conditions with group membership conditions to grant authorized teams access while restricting others. See Policy Engine Deep Dive for combining algorithm details.

Admin workflow: reviewing pending models

Section titled “Admin workflow: reviewing pending models”

When auto-discovery or manual registration adds new models at unclassified status, the following review workflow applies:

  1. Triage — Navigate to Admin > Model Registry and filter by risk_tier = unclassified. Review each entry and determine the appropriate risk tier based on the model’s intended use.

  2. Classify — Use PUT /api/v1/admin/models/{id} to assign a risk_tier (critical, high, medium, or low), set the owner, add a description, and populate approved_use_cases.

  3. Submit for review — Transition the model to under_review using the status transition endpoint:

    POST /api/v1/admin/models/{entry_id}/status
    {
      "status": "under_review",
      "reason": "Triage complete. Assigned risk tier high. Submitting for validation review."
    }

  4. Validate — The model risk team conducts validation per SR 11-7 requirements. When validation is complete:

    • Transition to approved if the model passes without conditions.
    • Transition to conditional and populate restrictions if approval is subject to constraints.
    • Transition back to unclassified if the submission is insufficient and must be re-triaged.

  5. Apply policy rules — Once approved, configure Policy Engine rules targeting model_risk_tier to govern production access.

  6. Deprecate — When a model is retired, transition to deprecated. The Policy Engine will enforce CANCEL rules for deprecated models if configured. Reactivation is possible by transitioning back to under_review.

All transitions are recorded in the immutable approval log accessible via GET /api/v1/admin/models/{entry_id}/status/history.

SR 11-7 compliance checklist

Section titled “SR 11-7 compliance checklist”
Requirement Arbitex capability
Model inventory Model Registry with full CRUD API; unique constraint on (model_id, provider)
Risk classification Five-value RiskTier enum (critical, high, medium, low, unclassified) aligned to SR 11-7 materiality
Validation lifecycle ValidationStatus state machine with enforced allowed transitions
Immutable audit trail Approval log written at every status transition; accessible via history API
Ongoing monitoring Audit log integration; usage_30d, usage_90d, last_used_at in inventory export
Model access governance model_risk_tier list-membership policy condition for request-time enforcement
Inventory export CSV and JSON export at /api/v1/admin/model-inventory-export with usage statistics
Ownership assignment owner field per model entry
Auto-discovery On-demand and 24-hour scheduled discovery from audit log
Conditional approvals conditional status with restrictions JSONB dict for constrained approvals
Section titled “Related pages”