Orchestration Component Model and Runtime Contracts

4. Runtime contract envelope

{
  "contractVersion": "1.0",
  "correlationId": "mission-184",
  "commandId": "cmd-991",
  "idempotencyKey": "attempt-7:tool-4",
  "actor": {"identity": "workload://worker/42", "grant": "grant-83"},
  "subject": {"type": "attempt", "id": "attempt-7", "version": 12},
  "tenant": "tenant-a",
  "classification": "confidential",
  "deadline": "2026-08-30T18:30:00Z",
  "budget": {"toolCalls": 20, "tokens": 90000, "costUsd": 8.0},
  "payload": {},
  "policyDecision": "decision-51",
  "traceContext": "00-...",
  "replyContract": "tool-result@2"
}

Consumers authenticate the sender, validate scope and schema, compare the expected state version, reserve capacity, persist acceptance, and dispatch. They return a durable acknowledgement distinct from completion. Results bind the exact input digest, environment, dependency versions, outputs, costs, errors, side-effect receipt, and unresolved uncertainty.

5. Workflow and attempt state

Only the state owner performs transitions. Events may request or inform a transition but do not mutate the projection directly. Resume revalidates manifest, source versions, policy, grants, leases, capability qualification, budgets, and environment. If any governing input changes materially, create a new attempt or explicit replan rather than pretending continuity.

12. Tradeoffs, nonclaims, and maturity

A general workflow engine supplies durable execution but not factory-specific authority, evidence, or capability semantics. A custom loop is simple but quickly accumulates hidden state and recovery debt. Start with deterministic graphs and isolated probabilistic steps. This review-ready specification does not prove throughput, failover, state correctness, or cost behavior in an implementation.