Forge Studio
Forge Studio is the visual execution composition surface of the Forge runtime.
Rather than executing computation directly, Studio allows engineers to design, version, execute, inspect, and replay distributed execution systems while preserving the same deterministic execution semantics as the public runtime.
Studio does not replace the runtime.
It expresses computational intent in a form the runtime can execute.
Why Studio Exists
Distributed execution should not require engineers to manually orchestrate:
- execution contracts
- dependency graphs
- execution ordering
- runtime coordination
- replay metadata
- execution artifacts
Forge Studio exists to compose these concerns into reproducible execution systems.
Applications describe business intent.
Studio composes execution.
The runtime preserves computational truth.
What You Will Learn
After reading this guide you will understand:
- how Studio composes execution systems
- how execution graphs become execution contracts
- how adapters and kernel primitives cooperate
- how execution flows remain reproducible
- how replay is preserved
- how Studio fits into the Forge runtime
The Studio Mental Model
Studio is easier to understand as an execution composition environment than as a workflow editor.
Every Studio Flow follows the same conceptual lifecycle.
Domain Logic
│
▼
Execution Graph
│
▼
Execution Contracts
│
▼
Forge Runtime
│
▼
Execution Evidence
│
▼
ReplayStudio defines execution.
The runtime performs execution.
Studio Within the Runtime
Studio occupies one layer of the complete Forge execution architecture.
Applications
│
▼
Forge Studio
│
Execution Composition
│
▼
Execution Contracts
│
▼
Kernel
│
▼
Hub
│
▼
Execution Agents
│
▼
Execution Evidence
│
▼
ReplayStudio never bypasses the Kernel.
Every execution ultimately follows the same runtime execution model regardless of whether it originates from Studio, an SDK, or the public API.
Studio Philosophy
Studio is designed to:
- compose deterministic execution systems
- expose kernel primitives through visual composition
- connect external systems through adapters
- preserve orchestration reproducibility
- generate replayable execution
- make distributed computation inspectable
Studio intentionally separates orchestration from execution.
Execution belongs to the runtime.
Runtime Components
Studio itself consists of several cooperating components.
- Dashboard
- Flow Registry
- Workboard
- Block Registry
- Run Engine
- Version Manager
- Artifact History
Studio communicates with:
- Web Core
- Kernel
- Hub
- Memory Fabric
Each component contributes to orchestration.
None performs distributed computation directly.
Execution Graphs
The primary object inside Studio is the Execution Graph.
An execution graph describes computational intent rather than execution order.
Execution order is derived automatically by the runtime.
Execution graphs remain deterministic because they preserve:
- graph topology
- version bindings
- execution mappings
- adapter bindings
- primitive bindings
Execution graphs therefore become reproducible execution definitions.
Blocks
Blocks are the building blocks of execution systems.
Each block describes:
- input schema
- output schema
- execution mapping
- version binding
Blocks describe execution intent.
They do not execute computation.
Core Blocks
Core blocks shape execution systems.
Typical examples include:
- JSON Input
- Transform
- Merge
- State
- Debug
Core blocks organize data.
They do not invoke distributed computation.
Adapter Blocks
Adapter blocks connect Forge to external systems.
Typical responsibilities include:
- ingesting external data
- validating payloads
- transforming domain models
- constructing execution contracts
- normalizing outputs
Adapters translate domain-specific language into canonical runtime language.
Primitive Blocks
Primitive blocks expose direct access to Kernel primitives.
Examples include:
mc@1tensor@1graph@1search@1ensemble@1
Primitive blocks expose execution capabilities.
The runtime determines how those capabilities execute.
Control Blocks
Control blocks describe execution structure.
Examples include:
- conditional routing
- iteration
- branching
- thresholds
- execution routing
Control blocks influence orchestration.
They never execute distributed workloads.
Action Blocks
Action blocks produce observable effects.
Examples include:
- Webhooks
- Notifications
- Exports
- Artifact persistence
Action blocks terminate execution stages rather than extending computation.
From Graph to Runtime
Executing a Studio Flow initiates the following runtime lifecycle.
Execution Graph
│
▼
Compilation
│
▼
Execution Contracts
│
▼
Kernel Validation
│
▼
Distributed Execution
│
▼
Verification
│
▼
Execution Evidence
│
▼
Replay
│
▼
Studio ResultsStudio submits execution.
The runtime performs execution.
Versioning
Every saved flow creates a new immutable execution definition.
Version identity includes:
- graph topology
- block versions
- adapter versions
- primitive versions
- execution mappings
Version immutability enables reproducible orchestration.
Production execution should always reference explicit flow versions.
Determinism
Studio contributes to deterministic execution by preserving:
- graph topology
- execution mappings
- adapter bindings
- primitive bindings
- version identity
Runtime determinism is preserved by:
- execution contracts
- deterministic planning
- verification
- deterministic reduction
- replay
Studio therefore preserves orchestration determinism.
The runtime preserves execution determinism.
Replay
Every Studio execution produces replay-compatible metadata.
Replay preserves:
- execution graphs
- execution contracts
- flow versions
- execution artifacts
- replay references
Replay reconstructs execution semantics.
It does not reproduce user interface state.
Studio and the Hub
Studio and the Hub perform complementary responsibilities.
| Component | Responsibility |
|---|---|
| Studio | Composes execution systems |
| Kernel | Defines execution semantics |
| Hub | Plans and orchestrates execution |
| Agents | Execute computational shards |
| Verification | Preserves execution integrity |
| Replay | Preserves execution evidence |
Execution flows through all of these components.
No single component independently defines computational truth.
Hosted and Self-Managed Studio
Studio may be deployed in different operational models.
Hosted Studio provides:
- managed identity
- managed updates
- shared adapter registry
- hosted runtime integration
Self-managed Studio provides:
- private deployment
- isolated infrastructure
- custom adapter registries
- private Hub connectivity
- regulated execution environments
Execution semantics remain identical across deployment models.
Production Practices
Production execution systems should:
- version every flow
- preserve replay references
- use explicit seeds where reproducibility matters
- separate experimental and production flows
- validate adapter versions
- review execution evidence
- monitor verification outcomes
Execution systems should be treated as versioned infrastructure.
Practical Mental Model
A useful way to understand Studio is:
Business Logic
│
▼
Execution Graph
│
▼
Execution Contracts
│
▼
Forge Runtime
│
▼
Execution Evidence
│
▼
ReplayStudio composes execution systems.
The runtime preserves computational truth.
Where to Go Next
Continue with:
HQ — understand the execution control plane.
Observability — inspect execution evidence, replay, and runtime behavior.
Security — understand execution authority and trust boundaries.
Trust Layer — learn how verification and replay establish computational trust.
Architecture — understand how the runtime implements deterministic distributed execution.
Final Thought
Forge Studio is not a workflow builder.
It is an execution composition surface.
Its purpose is not to simplify distributed computing.
Its purpose is to make distributed execution reproducible, versioned, replayable, and structurally correct while preserving the deterministic execution semantics of the Forge runtime.