Appearance
Execution Accounting
Forge Pool uses a deterministic execution accounting model designed for distributed, replayable, and auditable computation.
The purpose of execution accounting is to ensure that:
- customers are billed for verified work
- providers are compensated for attributable contribution
- workloads remain replayable and auditable
- execution economics remain stable across heterogeneous infrastructure
Execution accounting is not a secondary operational layer.
It is part of the execution model itself.
1. Core Principle
Forge Pool accounts for:
verified execution
—not theoretical capacity, idle infrastructure, or nominal hardware ownership.
Execution becomes economically meaningful only after it passes through the canonical execution lifecycle:
text
request
→ planning
→ shard assignment
→ execution
→ verification
→ aggregation
→ settlement
→ replayable ledger recordThis ensures that billing, payouts, and attribution are tied to measurable computational work.
2. Accounting Objectives
The accounting system exists to provide:
- deterministic attribution
- replay-compatible accounting
- enterprise-grade auditability
- provider settlement integrity
- workload transparency
- normalized usage visibility
The accounting layer must remain:
- stable
- versionable
- reproducible
- infrastructure-neutral
3. Canonical Execution Lifecycle
3.1 Request Creation
Execution begins when a workload is submitted through:
- Web Core APIs
- Forge Studio
- adapters
- internal orchestration surfaces
The request defines:
- primitive family
- profile
- execution policy
- arguments
- replay context
- execution metadata
At this stage, the workload is not yet billable.
3.2 Planning
The Hub analyzes the workload and determines:
- shard strategy
- execution topology
- verification policy
- resource weighting
- aggregation requirements
Planner outputs may contribute to projected usage estimates, but estimates are not final settlement values.
3.3 Shard Assignment
The workload is decomposed into deterministic execution units ("shards") and distributed across eligible Agents.
Shard assignment may consider:
- hardware capabilities
- locality constraints
- reliability history
- execution policy
- queue state
- provider weighting
Assignment alone does not generate billable execution.
3.4 Execution
Agents execute assigned shards using deterministic runtime semantics.
Execution may include:
- probabilistic simulation
- graph propagation
- media transformation
- search and ranking
- aggregation
- memory operations
Partial execution artifacts may be generated during this phase.
3.5 Verification
Forge Pool may apply one or more verification modes depending on workload policy.
Illustrative verification modes include:
- no verification
- spot verification
- deterministic replay sampling
- multi-node comparison
- aggregation consistency checks
Verification exists to preserve:
- execution integrity
- payout integrity
- replay correctness
- billing trust
Unverified or invalid execution may be excluded from settlement.
3.6 Aggregation
After verification, shard results are reduced into canonical execution outputs.
Aggregation may generate:
- distributions
- metrics
- traces
- confidence surfaces
- replay artifacts
- evidence bundles
At this point, the workload becomes eligible for finalized accounting.
3.7 Settlement
Settlement produces the canonical economic record associated with the workload.
Settlement may include:
- Credit consumption
- provider attribution
- adapter attribution
- replay metadata
- billing scope assignment
- payout contribution
Settlement records become part of the execution ledger.
4. What Becomes Billable
Forge Pool bills for verified execution contribution.
Typical billable components may include:
- executed workload volume
- verified iteration count
- aggregation complexity
- artifact generation
- replay retention
- specialized execution classes
- reserved execution guarantees where applicable
Billing is tied to finalized execution accounting records.
5. What Does Not Become Billable
By default, Forge Pool does not bill customers for:
- idle infrastructure
- failed shard retries
- internal orchestration overhead
- discarded invalid execution
- platform-side fault recovery
- unattributed system activity
This preserves alignment between cost and useful execution.
6. Execution States
Workloads may pass through multiple accounting states.
Illustrative states include:
| State | Meaning |
|---|---|
| Pending | Request accepted but not finalized |
| Planned | Execution topology generated |
| Running | Active distributed execution |
| Verifying | Integrity validation in progress |
| Aggregating | Reduction and artifact assembly |
| Finalized | Eligible for billing and settlement |
| Failed | Execution invalid or incomplete |
| Disputed | Under operational or commercial review |
Only finalized execution contributes to canonical settlement.
7. Deterministic Attribution
Every finalized workload may include attribution dimensions such as:
- organization
- project
- workspace
- adapter
- primitive family
- profile
- execution class
- provider participation
- replay token
- billing cycle
This enables:
- enterprise cost allocation
- provider payouts
- internal chargeback
- audit workflows
- replay-based reconciliation
8. Replay and Accounting
Replayability is a core accounting property.
Replay support may include:
- deterministic seed references
- planner state references
- primitive and profile versioning
- artifact integrity references
- execution traces
Replay allows organizations to:
- validate execution history
- investigate anomalies
- reproduce settlement conditions
- audit computational evidence
Replay does not necessarily imply free re-execution.
Commercial treatment of replay workloads may depend on policy and agreement.
9. Credits and Accounting
Credits are the normalized accounting unit across workload classes.
Execution accounting determines:
- how Credits are attributed
- when Credits are finalized
- which execution records contribute to Credit usage
Credits are therefore downstream of verified execution accounting.
See Credits.
10. Provider Settlement
Provider payouts depend on finalized execution attribution.
Settlement may consider:
- verified execution volume
- workload weighting
- reliability factors
- policy-adjusted contribution
- execution quality
Providers are compensated for attributable contribution, not mere network presence.
See Node Payouts.
11. Enterprise Accounting Controls
Forge Pool may support enterprise accounting controls such as:
- budget caps
- quota enforcement
- billing scopes
- organizational segmentation
- workload tagging
- exportable usage records
- internal reconciliation workflows
These controls help organizations integrate Forge into procurement and governance processes.
12. Accounting Integrity
Execution accounting is designed to remain:
- deterministic
- auditable
- replay-compatible
- fraud-resistant
- infrastructure-neutral
The accounting system is intentionally coupled to execution semantics rather than detached billing estimates.
This ensures that commercial attribution remains structurally tied to actual computation.
13. Relationship to the Ledger
The execution ledger is the canonical historical record of finalized workloads.
Ledger records may include:
- workload identity
- settlement state
- Credit attribution
- provider attribution
- replay references
- execution artifacts
- accounting metadata
The ledger exists to preserve:
- accountability
- auditability
- reproducibility
- economic trust
14. Future Evolution
The accounting model may expand to support:
- additional execution classes
- advanced replay semantics
- marketplace-level attribution
- adapter-native commercial policies
- hybrid enterprise accounting
- delegated settlement domains
Future expansion will preserve compatibility with deterministic accounting principles.
Final Statement
Forge Pool does not treat accounting as an external business layer.
Execution itself is the source of economic truth.
Billing, attribution, replay, and settlement are all derived from verified computation across the planetary runtime.