finance.credit.cascading_failure_graph.v1
Overview
Verify that the Forge runtime executes the canonical Cascading Failure Graph Primitive Profile using the production Graph execution kernel.
After completing this example you should be able to:
- execute the canonical Graph profile
- inspect propagation behaviour
- verify runtime evidence
- inspect generated artifacts
- validate deterministic replay
This document verifies Graph execution.
It does not validate any particular financial institution or credit model.
Primitive Profile
| Property | Value |
|---|---|
| Primitive | graph@1 |
| Profile | finance.credit.cascading_failure_graph.v1 |
| Runtime | Compute |
| Replay | Supported |
| Artifacts | Supported |
| Deterministic | Supported |
| CPU | Supported |
| GPU | Not Required |
Capability
finance.credit.cascading_failure_graph.v1 evaluates how failures propagate across an interconnected credit dependency network.
Rather than evaluating isolated entities, the execution kernel treats the portfolio as a graph whose nodes represent financial entities and whose edges represent explicit dependency relationships.
Propagation continues according to the profile's deterministic execution rules until the graph reaches a stable state.
The objective is not to estimate loss.
The objective is to expose structural propagation behaviour.
Canonical Contract
Execution uses the canonical Forge Graph execution contract.
Primitive
graph
Version
1
Profile
finance.credit.cascading_failure_graph.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 graph definition together with profile-specific execution parameters.
Typical required execution surfaces include:
- graph topology
- nodes
- edges
- propagation configuration
- execution objective
Execution begins only after successful canonical validation.
Optional Inputs
Depending on execution policy, optional inputs may include:
- edge weights
- exposure strength
- confidence values
- propagation thresholds
- recovery behaviour
- ownership metadata
- replay configuration
- execution evidence
Only profile-supported 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 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
- propagation completes successfully
- affected nodes 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 graph state and the propagation process.
Runtime Evidence
Successful execution exposes runtime evidence including:
- execution identifier
- primitive profile
- graph metadata
- node count
- edge count
- propagation summary
- affected nodes
- propagation depth
- traversal statistics
- replay metadata
- artifact references
The exact evidence surface depends on execution policy.
Replay
Replay should reproduce the same propagation behaviour when executed using the identical graph topology, execution contract, runtime version, and deterministic seed where applicable.
Replay validates the determinism of the propagation engine rather than infrastructure identity.
Replay verification is described in:
→ /verification/replay-determinism
Artifacts
Typical execution artifacts include:
- propagation graph
- affected-node report
- dependency graph
- traversal summary
- propagation trace
- execution summary
- replay metadata
Artifacts explain how the runtime reached the observed graph state.
Applied Intelligence Modules
This Primitive Profile is reused across multiple Forge Intelligence Modules including:
- Credit Intelligence
- Banking Intelligence
- Portfolio Intelligence
- Financial Stability Intelligence
- Systemic Risk Intelligence
The execution primitive remains identical while only the domain-specific graph profile changes.
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 | ✓ |
| Propagation completed | ✓ |
| Runtime inspected | ✓ |
| Artifacts inspected | ✓ |
| Replay verified | ✓ |
| Negative validation tested | ✓ |
Final Principle
finance.credit.cascading_failure_graph.v1 verifies a versioned Graph Primitive Profile rather than a financial prediction.
Its correctness is demonstrated through deterministic graph execution, observable propagation behaviour, runtime evidence, replay, and artifact inspection, allowing independent evaluators to reproduce the same execution without relying on 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.