finance.credit.loss_distribution_surface.v1
Overview
finance.credit.loss_distribution_surface.v1 is a versioned Primitive Profile implemented by the Forge Monte Carlo kernel.
It models portfolio credit loss behaviour under uncertainty by repeatedly simulating default and recovery outcomes across a portfolio of credit exposures.
The profile is designed to support analytical workflows such as expected loss estimation, loss-rate analysis, tail-event detection, and unexpected loss assessment.
Primitive Profile
| Property | Value |
|---|---|
| Primitive | mc@1 |
| Profile | finance.credit.loss_distribution_surface.v1 |
| Handler | forge_execute |
| Stability | Stable |
| Replay Capable | Yes |
| Artifact Capable | Yes |
| AI Ready | Yes |
| Describe Before Execute | Required |
Execution Purpose
This profile estimates portfolio-level credit loss distributions from a collection of credit exposures.
Depending on the selected output mode, execution may produce:
- portfolio loss rate
- absolute portfolio loss
- unexpected loss
- tail-loss event indicators
The computational objective remains identical regardless of execution surface.
Canonical Contract
Execution is performed through the canonical Forge execution contract.
Primitive : mc
Version : 1
Profile : finance.credit.loss_distribution_surface.v1Requests are validated by the canonical execution validator before entering the runtime.
Required Inputs
The canonical contract requires:
- iterations
- exposures
- exposures[].ead
- exposures[].pd
- exposures[].lgd
Execution cannot begin unless these fields satisfy canonical validation.
Optional Inputs
Supported optional inputs include:
- horizon_months
- tail_threshold
- output_mode
- macro_scenario
- exposure identifiers
- maturity information
- IFRS9 stage
- discount rate
- macro sensitivity
- PD volatility
- LGD volatility
- EAD volatility
Optional parameters refine the execution without changing the contract itself.
Output Modes
The profile currently supports four execution modes.
| Output Mode | Description |
|---|---|
loss_rate | Portfolio loss normalized by exposure |
absolute_loss | Aggregate simulated portfolio loss |
unexpected_loss | Unexpected loss estimate |
tail_loss_event | Tail-event indicator using the configured threshold |
The execution contract determines which computational surface is returned.
Validation
Every request is validated before execution.
Validation confirms:
- payload structure
- primitive identity
- profile identity
- required arguments
- argument ranges
- supported output modes
Requests failing validation never enter the execution runtime.
Runtime Characteristics
| Characteristic | Value |
|---|---|
| Deterministic execution | Supported (with explicit seed) |
| Side effects | None |
| Replay | Supported |
| Artifact generation | Supported |
| CPU execution | Supported |
| GPU execution | Supported |
Execution behaviour is defined by the runtime rather than the client.
Execution Protocol
A typical verification workflow is:
- Discover the profile.
- Inspect the canonical contract.
- Build a minimum valid payload.
- Execute with an explicit seed.
- Inspect the result and generated artifacts.
- Replay the execution using the same execution identity.
- Compare runtime evidence.
This sequence mirrors the Forge Verification Methodology.
Runtime Evidence
Successful execution produces observable runtime evidence including:
- execution identity
- canonical profile
- execution metadata
- computational result
- replay metadata
- execution artifacts (when available)
The exact evidence surface depends on execution policy.
Replay Characteristics
This profile supports deterministic replay.
Replay allows evaluators to confirm that the execution contract, runtime metadata, and computational outcome remain consistent under the documented replay guarantees.
Replay verification should be performed after successful execution.
AI Guidance
This profile is AI-agent ready.
Agent implementations should:
- inspect the canonical contract before execution
- generate a minimum valid payload for initial verification
- expand to expressive payloads for analytical workloads
- preserve replay metadata
- avoid introducing undocumented arguments
Common Mistakes
Common evaluation mistakes include:
- treating successful validation as proof of analytical correctness
- interpreting a single metric without examining execution context
- ignoring output mode semantics
- omitting replay verification
- inventing unsupported request fields
Independent verification should always include contract inspection, execution, runtime evidence, and replay.
Applied Domains
This Primitive Profile is reused by multiple Intelligence Modules, including:
- Banking Intelligence
- Credit Intelligence
- Capital Intelligence
- Portfolio Intelligence
- Financial Risk Intelligence
The execution contract remains identical regardless of consuming domain.
Related Documentation
Capability Assessment
| Verification Surface | Status |
|---|---|
| Primitive Identity | ✓ |
| Canonical Contract | ✓ |
| Validation | ✓ |
| Runtime Evidence | ✓ |
| Replay | ✓ |
| Artifact Support | ✓ |
| AI Ready | ✓ |
Final Principle
finance.credit.loss_distribution_surface.v1 is a versioned computational contract implemented by the Forge Monte Carlo kernel.
Its observable behaviour is verified through canonical validation, deterministic execution, runtime evidence, replay, and artifact inspection rather than through implementation details.
Continue in Forge Studio
This document describes the canonical execution contract for this capability.
The Forge documentation explains how this capability works.
Forge Studio allows you to inspect, execute, and verify the live implementation.
Capability Explorer
Browse the live capability catalog, supported execution surfaces, available Primitive Profiles, and execution metadata.
→ https://studio.forgepool.io/capability-explorer
Block Registry
Inspect the registered Primitive Profile, execution contract, block metadata, adapters, versions, and runtime characteristics.
→ https://studio.forgepool.io/studio/blocks-registry
Execute
Execute this capability using Forge Studio, the Execution API, or an MCP-compatible client.
Verify
Before interpreting the result, inspect:
- runtime evidence
- generated artifacts
- deterministic replay
- execution metadata
Trust should be established through independent verification rather than documentation alone.