Forge HQ

Forge HQ is the execution control plane of the Forge runtime.

It provides the trusted operational surface through which organizations manage execution, providers, policies, observability, replay, and governance.

HQ does not execute computation.

It governs the environment in which computation occurs.

---

What You Will Learn

After reading this guide you will understand:

• the role of HQ within the Forge runtime
• how organizations manage execution
• how projects isolate workloads
• how providers are administered
• how replay and observability integrate into operations
• how HQ differs from the execution runtime itself

---

The Control Plane Mental Model

Forge intentionally separates runtime execution from operational governance.

Users
      │
      ▼
Forge HQ
      │
      ▼
Organizations
      │
      ▼
Projects
      │
      ▼
Execution Policies
      │
      ▼
Forge Runtime
      │
      ▼
Execution Evidence

HQ governs execution.

The runtime performs execution.

---

Why HQ Exists

Distributed execution requires more than computational infrastructure.

Organizations also require the ability to:

• manage execution authority
• organize projects
• inspect execution
• monitor providers
• understand costs
• preserve governance
• administer runtime resources

HQ centralizes these operational responsibilities without altering execution semantics.

---

Operational Responsibilities

HQ manages the trusted operational layer surrounding execution.

Typical responsibilities include:

• organization management
• project lifecycle
• authentication
• provider administration
• execution inspection
• replay access
• billing
• observability
• governance

Execution itself remains entirely within the Forge runtime.

---

Organizations

Organizations define administrative boundaries.

Typical organization responsibilities include:

• members
• roles
• permissions
• projects
• provider ownership
• billing relationships
• deployment policies

Organizations establish operational ownership.

They do not alter execution behavior.

---

Projects

Projects isolate execution.

Each project maintains independent:

• API Keys
• execution history
• replay references
• execution policies
• billing records
• artifacts

Projects represent operational boundaries rather than computational boundaries.

---

Execution Management

HQ provides operational visibility into execution.

Typical execution information includes:

• execution contracts
• execution status
• execution duration
• participating providers
• verification policy
• replay references
• execution artifacts
• billing information

HQ allows execution to remain understandable long after computation completes.

---

Provider Operations

Execution providers are administered through HQ.

Typical provider workflows include:

• Node Token generation
• node registration
• node health
• provider statistics
• verification participation
• execution contribution
• operational history
• provider accounting

HQ manages provider participation.

Scheduling remains a runtime responsibility.

---

Identity and Access

HQ manages runtime authority.

Typical identity operations include:

• user management
• project membership
• API Key administration
• Node Token administration
• credential rotation
• access review

Identity determines authority.

It does not determine execution integrity.

---

Billing and Economic Operations

HQ also provides operational insight into runtime economics.

Typical information includes:

• credit consumption
• execution costs
• provider earnings
• billing history
• settlement records
• resource utilization

Economic accounting derives from verified execution evidence.

---

Replay Operations

Replay is accessible through HQ.

Operators may inspect:

• execution contracts
• replay metadata
• execution artifacts
• verification outcomes
• execution history

Replay allows execution to remain operationally understandable after completion.

---

Observability

HQ integrates runtime observability.

Typical inspection surfaces include:

• execution metrics
• provider health
• scheduler activity
• verification status
• execution artifacts
• replay references

HQ exposes execution transparency.

It does not generate execution telemetry.

---

Governance

Organizations may define operational governance through HQ.

Typical governance responsibilities include:

• project isolation
• credential management
• deployment policy
• execution authority
• provider approval
• organizational administration

Governance defines operational behavior.

Execution semantics remain unchanged.

---

Runtime Relationship

HQ deliberately occupies a different responsibility than the execution runtime.

HQ
        │
Operational Governance
        │
        ▼
Web Core
        │
        ▼
Kernel
        │
        ▼
Hub
        │
        ▼
Execution Agents
        │
        ▼
Execution Evidence

HQ never bypasses execution semantics.

It governs the environment around them.

---

Hosted and Private Deployments

Forge HQ may be deployed in different operational models.

Hosted deployments provide:

• managed identity
• hosted governance
• shared operational services
• managed updates

Private deployments may additionally provide:

• isolated organizations
• dedicated control planes
• private runtime connectivity
• restricted provider pools
• regulated operational environments

Operational deployment does not affect execution semantics.

---

Production Operations

Production teams should use HQ to:

• manage execution authority
• review provider health
• inspect replay evidence
• monitor execution history
• review execution costs
• audit operational activity
• administer projects
• govern provider participation

HQ is intended to become the primary operational interface for the runtime.

---

Relationship to Other Guides

HQ complements the remaining operational guides.

• Forge Studio composes execution systems.
• Observability explains execution behavior.
• Security governs execution authority.
• Trust Layer validates execution integrity.

Together these documents describe how execution systems are composed, governed, observed, protected, and trusted.

---

Practical Mental Model

A useful way to understand HQ is:

Organizations
        │
        ▼
Projects
        │
        ▼
Execution Governance
        │
        ▼
Forge Runtime
        │
        ▼
Execution Evidence
        │
        ▼
Operational Understanding

HQ is not the runtime.

HQ is the trusted operational window into the runtime.

---

Final Thought

Forge HQ is not a dashboard.

It is the execution control plane.

Its purpose is not to perform computation.

Its purpose is to make distributed execution governable, observable, secure, and operationally understandable while preserving the deterministic execution semantics of the Forge runtime.