Appearance
Forge Studio
Programmable Orchestration Surface for Planetary Execution
Forge Studio is the programmable orchestration surface of the Forge planetary execution system.
It allows users to compose execution graphs, connect real-world systems, and trigger distributed probabilistic workloads across the Forge runtime.
Studio does not execute compute.
Studio defines execution. Web Core validates execution. Hub orchestrates execution. Agents perform execution.
Mental Model
Forge Studio is not a workflow builder.
It is a composition layer over deterministic kernel primitives and real-world system interfaces.
A Studio Flow is a directed execution graph where:
- nodes represent data transformation, adapter boundaries, or primitive execution
- edges represent deterministic data flow
- execution is compiled into distributed kernel workloads
Studio transforms domain logic into execution contracts.
How Studio Fits Into Forge
Forge Pool is a planetary execution system composed of:
- Web Core (access, billing, policy)
- Hub (control plane and orchestration)
- Agent Mesh (distributed execution)
- Kernel Primitives (compute families)
- Adapters (real-world interface layer)
- Studio (orchestration surface)
Studio sits on top of this stack.
It does not execute compute directly. It defines what should be executed and how.
System Layers
User → Studio → Web Core → Hub → Agents → Artifacts
- Studio composes execution graphs
- Web Core validates and submits jobs
- Hub shards and orchestrates execution
- Agents execute workloads
- Artifacts are stored in Memory Fabric
Studio Philosophy
Studio exists to:
- abstract distributed execution complexity
- compose deterministic multi-step execution systems
- connect real-world systems through adapters
- expose kernel primitives as programmable building blocks
- preserve reproducibility of orchestration logic
- enable audit-ready execution
Studio transforms execution contracts into structured, reproducible systems.
1. Accessing Studio
Studio can be used in two modes.
Hosted
- Connected to Forge Pool infrastructure
- Shared adapter registry
- Centralized authentication
Local Deployment
Studio is fully self-deployable.
It can be:
- deployed via Docker
- run inside private infrastructure
- connected to public or private Hubs
- used in air-gapped environments
Studio is infrastructure-portable.
2. Authentication Model
Studio uses a Forge User Token.
On entry:
- Token is validated against Web Core
- Stored server-side in session
- Never persisted in browser storage
Generate token in:
HQ → API TokensStudio inherits project-level access boundaries.
3. Studio Architecture
Studio consists of:
- Dashboard
- Block Registry
- Workboard (Graph Editor)
- Run Engine
- Flow Versioning System
- Artifact Store (Run history)
Studio interacts with:
- Web Core (auth + policy)
- Hub (execution)
- Memory Fabric (artifacts)
4. Block Model
A block is a node in the execution graph.
Each block defines:
- input schema
- output schema
- execution mapping
- version binding
Data Flow
Data between blocks is passed as structured payloads.
Each edge represents:
- dependency
- transformation
- deterministic transfer of state
Block Types
Studio exposes three categories of blocks.
Core Blocks
Core blocks define orchestration and data transformation logic.
Examples:
- JSON Input
- Map / Transform
- Merge
- KV / State
- Debug
Core blocks do not execute compute. They shape execution graphs.
Adapter Blocks (Reality Interface)
Adapter blocks connect Studio to real-world systems.
They:
- ingest external data
- normalize payloads
- map domain inputs to execution contracts
- route workloads into Forge execution
Examples:
- Portfolio Ingest
- Scenario Explore
- Risk Execute
- Risk Aggregate
- Risk Output / Export
Adapters are boundary translators between real systems and Forge execution.
Primitive Blocks (Kernel Access)
Primitive blocks expose direct access to Forge kernel primitives.
Examples:
- Monte Carlo (
mc@1) - Graph propagation (
graph@1) - Search and discovery (
search@1) - Ensemble aggregation (
ensemble@1)
These blocks allow Studio to invoke distributed compute directly without adapters.
This makes Studio both:
- an integration layer
- a direct compute orchestration interface
Control Blocks
- Conditional branching
- Threshold rules
- Routing logic
- Iterative control
Control blocks do not execute compute. They define execution structure.
Action Blocks
- Webhook
- Export
- Notification
- Artifact storage
Action blocks emit external effects.
5. Execution Model
Execution is fully delegated to the Forge runtime.
When a flow runs:
- Studio evaluates the graph
- Blocks are resolved into execution mappings
- Adapter or primitive blocks trigger execution
- Requests are sent to Web Core
- Hub orchestrates execution across agents
- Agents execute workloads
- Results are aggregated
- Studio receives outputs, metrics, and artifacts
All compute is invoked through:
/api/v0/ops/executeStudio never bypasses the Kernel.
Forge does not compute a single result.
It computes a space of possible outcomes.
Example: Institutional Risk Pipeline
A canonical Studio pipeline:
Portfolio Ingest → Scenario Explore → Risk Execute → Risk Aggregate → Risk Output / Export
This pipeline:
- ingests real-world portfolio data
- constructs scenario space
- executes distributed Monte Carlo workloads
- aggregates risk surfaces
- produces analyst-ready outputs
Internally, all compute is executed across the Forge distributed runtime.
6. Dashboard
The Dashboard displays:
- existing Flows
- active versions
- last run timestamps
- run status indicators
Each Flow:
- contains versioned graph definitions
- is immutable per version
- can be duplicated
- can be activated explicitly
Flow immutability ensures orchestration reproducibility.
Studio Dashboard Overview
The Dashboard is the entry point into Studio.
7. Workboard (Graph Editor)
The Workboard is a deterministic graph composition surface.
Blocks define:
- input schema
- output schema
- execution mapping
- version binding
Edges define:
- data dependency
- execution order
- transformation flow
Execution order is derived from directed acyclic graph topology.
Workboard (Graph Editor)
This is where execution systems are composed.
8. Execution Graph
A Studio Flow is a directed acyclic graph (DAG).
Execution order is derived automatically.
No manual sequencing is required.
9. Flow Versioning & Determinism
Each save creates:
- flow version number
- graph hash
- serialized JSON definition
Version binding includes:
- block versions
- adapter versions
- graph topology
- execution mapping
Determinism
Determinism is enforced at:
- graph level (topology)
- adapter level (input mapping)
- kernel level (seeded execution)
Reproducibility
Runs are reproducible if:
- identical flow version
- identical adapter versions
- identical seeds
- identical execution policy
Artifacts & Replay
Every execution produces:
- structured outputs
- metrics
- artifacts
- replay tokens
Replay tokens allow:
- deterministic re-execution
- auditing
- scenario comparison
- debugging
Execution in Forge is not complete without replay.
10. Running a Flow
When you click Run:
- Studio validates graph integrity
- Compiles execution plan
- Submits Kernel jobs
- Receives outputs and artifacts
- Records metadata
- Stores run snapshot
Each Run records:
- flow version
- job IDs
- replay metadata
- execution timestamps
- output snapshot
- credit usage
Runs are immutable once completed.
11. Replay of Studio Runs
A Studio Run can be replayed if:
- flow version remains unchanged
- underlying adapters remain deterministic
- original seeds are preserved
Replay binds:
- orchestration logic
- execution contract
- deterministic output
Studio enables full reconstruction of execution.
12. Studio vs Hub
Forge operates with dual orchestration:
- Studio → flow orchestration
- Hub → compute orchestration
| Layer | Responsibility |
|---|---|
| Studio | Orchestrates Jobs |
| Hub | Orchestrates Shards |
| Agents | Execute compute |
Studio never executes compute.
13. Local vs Hosted Security Model
Hosted Studio:
- centralized identity
- shared adapter registry
- managed updates
Local Studio:
- isolated environment
- private Hub connectivity
- custom adapter registry
- internal-only execution graphs
Supports enterprise and regulated deployments.
14. Best Practices
- Keep flows modular
- Separate test and production flows
- Bind production to explicit versions
- Use explicit seeds for regulated workflows
- Monitor run artifacts
- Avoid mixing experimental blocks in active flows
- Export replay metadata when required
Why Studio Matters
Traditional systems:
- execute workflows
- produce results
- lose execution context
Forge Studio:
- composes execution systems
- produces reproducible artifacts
- preserves execution trace
- enables audit and replay
This enables:
- regulatory-grade computation
- institutional verification
- long-term reproducibility
Studio as Infrastructure
Forge Studio is not a visual tool.
It is a deterministic orchestration surface for planetary compute.
It converts:
- domain logic
- execution contracts
- versioned graphs
- audit metadata
into reproducible execution systems.
Studio does not simplify compute.
It makes compute structurally correct.
Final Note
Forge Studio is not the system.
It is the surface through which the system becomes usable.