insurance.counterparty.contagion.v1
Overview
Verify that the Forge runtime executes the canonical Counterparty Contagion Primitive Profile using the production Graph execution kernel.
After completing this example you should be able to:
- execute the canonical Graph profile
- inspect counterparty contagion propagation
- verify runtime evidence
- inspect generated artifacts
- validate deterministic replay
This document verifies Graph execution.
It does not validate any particular insurance portfolio or reinsurance programme.
Primitive Profile
| Property | Value |
|---|---|
| Primitive | graph@1 |
| Profile | insurance.counterparty.contagion.v1 |
| Runtime | Compute |
| Replay | Supported |
| Artifacts | Supported |
| Deterministic | Supported |
| CPU | Supported |
| GPU | Not Required |
Capability
insurance.counterparty.contagion.v1 evaluates how financial distress propagates through interconnected insurance counterparties.
The execution models insurers, reinsurers, brokers, clearing entities, and other counterparties as graph nodes connected through explicit financial relationships.
When one or more counterparties experience stress, the Graph kernel deterministically evaluates how that stress propagates across the network according to the registered Primitive Profile.
The objective is to expose structural contagion paths rather than estimate future losses.
Canonical Contract
Execution uses the canonical Forge Graph execution contract.
Primitive
graph
Version
1
Profile
insurance.counterparty.contagion.v1Requests are validated before entering the execution runtime.
The canonical payload contains:
op.name
op.version
op.profile
argsOptional execution metadata may include:
ctx
seed
policyRequired Inputs
The canonical execution contract requires a valid counterparty graph together with profile-specific execution parameters.
Typical required execution surfaces include:
- graph topology
- counterparties
- financial relationships
- propagation configuration
- execution objective
Execution begins only after successful canonical validation.
Optional Inputs
Depending on execution policy, optional inputs may include:
- exposure weights
- dependency strength
- confidence values
- recovery assumptions
- propagation thresholds
- ownership metadata
- replay configuration
- execution evidence
Only documented profile fields should be supplied.
Unsupported fields are rejected during validation.
Canonical Smoke
The maintained Graph smoke verifies:
- successful profile resolution
- canonical validation
- graph construction
- deterministic contagion propagation
- runtime evidence generation
- replay metadata generation
- artifact availability
The maintained Smoke Suite remains the canonical executable source.
Verification Expectations
A successful execution should demonstrate:
- canonical validation succeeds
- graph construction succeeds
- contagion propagation completes successfully
- affected counterparties are identified
- propagation trace is generated
- runtime evidence is available
- replay metadata is produced
- execution artifacts are generated
Verification includes inspection of both the resulting network state and the propagation process.
Runtime Evidence
Successful execution exposes runtime evidence including:
- execution identifier
- primitive profile
- graph metadata
- counterparty count
- relationship count
- propagation summary
- affected counterparties
- propagation depth
- traversal statistics
- replay metadata
- artifact references
The exact evidence surface depends on execution policy.
Replay
Replay should reproduce identical contagion propagation behaviour when executed using the same graph topology, execution contract, runtime version, and deterministic seed where applicable.
Replay validates the determinism of the Graph execution engine rather than infrastructure identity.
Replay verification is described in:
→ /verification/replay-determinism
Artifacts
Typical execution artifacts include:
- counterparty network
- contagion graph
- affected-counterparty report
- propagation trace
- dependency summary
- execution summary
- replay metadata
Artifacts provide observable evidence explaining how the Graph kernel propagated state through the network.
Applied Intelligence Modules
This Primitive Profile is reused across multiple Forge Intelligence Modules including:
- Insurance Intelligence
- Reinsurance Intelligence
- Counterparty Risk Intelligence
- Solvency Intelligence
- Systemic Risk Intelligence
The computational primitive remains identical while the Primitive Profile defines insurance-specific propagation semantics.
Related Documentation
- /examples/graph/
- /verification/
- /verification/capability-verification
- /verification/replay-determinism
- /verification/artifact-inspection
Verification Checklist
| Verification Surface | Status |
|---|---|
| Primitive resolved | ✓ |
| Contract validated | ✓ |
| Graph constructed | ✓ |
| Contagion propagated | ✓ |
| Runtime inspected | ✓ |
| Artifacts inspected | ✓ |
| Replay verified | ✓ |
| Negative validation tested | ✓ |
Final Principle
insurance.counterparty.contagion.v1 verifies a versioned Graph Primitive Profile rather than an insurance model.
Its correctness is demonstrated through deterministic graph execution, observable contagion propagation, runtime evidence, replay, and artifact inspection, allowing independent evaluators to reproduce the same execution using the canonical execution contract.
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.