KV
Forge Pool KV provides deterministic execution-adjacent state for the Forge Pool execution platform.
KV is designed to persist small, structured state closely associated with execution while remaining independent of the execution contract itself.
Rather than acting as a general-purpose database, KV provides lightweight execution state that supports orchestration, coordination, replay, verification, and artifact discovery.
Purpose
Execution requires more than computation.
Distributed workloads also require lightweight state that remains available throughout planning, execution, verification, replay, and operational inspection.
KV provides that execution-adjacent state.
Representative uses include:
- execution metadata
- workflow coordination
- replay references
- artifact indexes
- execution checkpoints
- adapter state
- identifier mapping
Execution State
Execution contracts are immutable.
Execution state is not.
KV stores mutable operational state surrounding execution without changing computational meaning.
Execution truth remains defined by the execution contract.
KV supports that truth.
Position in the Execution Platform
Forge Pool separates execution from execution state.
Execution Contract
↓
Planetary Kernel
↓
Distributed Execution
↓
Execution State (KV)
↓
Replay & VerificationKV participates in execution without becoming part of execution semantics.
Runtime Characteristics
KV is characterized by:
- lightweight structured storage
- execution-scoped data
- deterministic identifiers
- TTL-aware lifecycle
- replay references
- artifact references
- execution metadata
Conceptual Operations
KV supports five conceptual operations.
- Store
- Retrieve
- Batch Store
- Batch Retrieve
- Delete
Representative API endpoints include:
PUT /v1/kv/key/{key}
GET /v1/kv/key/{key}
DELETE /v1/kv/key/{key}
POST /v1/kv/mget
POST /v1/kv/msetThe execution semantics remain independent of the transport interface.
Execution-Aware Lifetime
KV entries may be temporary.
Execution state commonly follows a managed lifecycle through TTL policies.
This allows execution coordination state to expire naturally after workloads complete while preserving long-term execution evidence elsewhere.
Runtime Guarantees
KV inherits the execution philosophy of the platform.
Execution state remains:
- execution-scoped
- replay-compatible
- version-aware
- TTL-aware
- deterministic in addressing
- suitable for operational inspection
Relationship to Replay
Replay uses KV to locate execution-adjacent references without redefining execution truth.
Representative uses include:
- replay identifiers
- artifact indexes
- execution manifests
- coordination references
Replay semantics remain defined by the execution contract.
Relationship to Verification
Verification consumes execution state produced during execution.
KV therefore supports verification without defining verification outcomes.
Verification validates execution.
KV provides operational context.
Relationship to VMem
KV stores persistent execution state.
VMem provides transient working memory for active execution.
Together they provide complementary execution surfaces within the Forge Pool platform.
What KV Is Not
KV is intentionally not:
- a relational database
- an object store
- a feature store
- an analytical warehouse
- a replacement for execution artifacts
Its purpose is execution-adjacent operational state.
Continue in Forge Studio
Explore execution state by:
- inspecting execution metadata
- reviewing replay references
- examining artifact indexes
- observing execution state throughout workload lifecycles
Trust should be established through independent verification rather than documentation alone.
Final Note
KV is not merely key-value storage.
It is the execution state surface of the Forge Pool execution platform.
By separating mutable execution state from immutable execution contracts, Forge Pool preserves deterministic execution while providing the operational flexibility required for replay, verification, orchestration, and distributed execution at scale.