t81-foundation

RFC-0053: Distributed Deterministic Execution Protocol

• RFC-ID: RFC-0053
• Title: Distributed Deterministic Execution Protocol
• Status: accepted
• Type: standards-track
• Applies-To: distributed runtime, cross-node ordering, state synchronization, consensus of canonical results, future service/runtime distribution
• Created: 2026-03-19
• Updated: 2026-03-22
• Supersedes: None
• Superseded-By: None
• Discussion: Builds on RFC-0002, RFC-DPE-0001 through RFC-DPE-0009, RFC-0043, RFC-0045, RFC-0046, RFC-0048, and RFC-0052

---

Summary

This RFC defines the protocol constraints for distributed deterministic execution in T81. It specifies how nodes participate in a shared canonical execution model, how state and commit order are synchronized, how conflicts are resolved, and how distributed execution remains subordinate to the same deterministic contract as local execution.

Motivation

Distributed execution is the long-horizon version of the same problem already solved locally by deterministic execution, DPE, and governance surfaces. Without a protocol-level RFC, future distributed work would almost certainly drift into:

• host-clock-driven coordination
• race-resolved state updates
• best-effort consensus on approximate results
• node-local interpretation of graph readiness
• replay-impossible side effects

T81 needs a constitutional distributed model before it can safely claim that a computation remains the same across nodes.

Proposal

1. Distributed Execution Is a Single Canonical Computation

A distributed execution must be interpreted as one canonical computation with multiple execution participants, not as loosely coordinated local computations.

Therefore:

• state identity is global to the computation
• commit order is globally meaningful
• node-local scheduling may not redefine semantic order

2. Canonical Node Roles

The protocol may define roles such as:

• coordinator or ordering authority
• execution worker
• state witness or replica
• policy/audit participant

Role names are flexible, but role semantics must be deterministic and explicit.

3. Global State Identity

Distributed execution requires:

• canonical state identifiers
• canonical epoch or commit identifiers
• canonical input artifact identifiers
• explicit versioning or generation semantics

No node may interpret state identity using local path names, local clocks, or ephemeral runtime addresses.

4. Global Ordering Rule

Distributed execution must define a canonical commit order that all nodes can derive or verify.

Requirements:

• input order must be canonical
• dependency order must be canonical
• conflict resolution order must be canonical
• network arrival order must not define semantics

5. Conflict Resolution

Conflicts between distributed updates must be resolved by explicit deterministic rules.

Allowed examples:

• canonical commit order
• explicit tie-break keys
• deterministic winner selection from canonical metadata
• fail-closed conflict rejection

Forbidden:

• “first packet wins”
• host clock or wall-clock precedence
• scheduler timing as a semantic tiebreak

6. Replay and Evidence

Every distributed execution claiming deterministic status must support replay and verification.

Required artifacts:

• canonical input set
• canonical graph/state metadata
• canonical commit ledger
• node participation records
• deterministic result hash or equivalent replay summary

These artifacts must fit within RFC-0043’s conformance model.

7. Fault and Partition Behavior

Distributed execution must define deterministic behavior for:

• node failure
• message delay
• message duplication
• partition or quorum loss
• retry/rejoin

Allowed responses:

• deterministic abort
• deterministic rollback to last canonical commit
• deterministic suspension until conditions are met

Forbidden:

• speculative continuation with ambiguous semantics
• silent local completion with later reconciliation changing results

8. Relation to Dataflow and DPE

• RFC-0052 defines the canonical dataflow/state model.
• RFC-DPE defines deterministic local parallel execution mechanisms.
• RFC-0053 defines how that same model extends across node boundaries.

Distributed execution must not introduce a second, incompatible ordering or state model.

9. Policy and Audit Participation

Distributed execution must preserve policy mediation and auditability.

Requirements:

• policy-visible operations remain policy-visible when distributed
• node-local shortcuts cannot bypass Axion or other governed checks
• audit records must preserve semantic, not transport-only, meaning

10. DCP Boundary Rule

Distributed execution is experimental / non-DCP by default.

Promotion requirements are stricter than local execution because:

• state synchronization adds new divergence risk
• network transport adds new timing and fault surfaces
• replay and commit-ledger proof obligations are larger

No distributed surface may be treated as DCP merely because its local executor is DCP-verified.

Determinism / Safety Considerations

Determinism considerations:

• network timing must never define semantic order
• conflict resolution and commit order must be canonical
• replay artifacts are mandatory, not optional

Safety considerations:

• partitions and node failures must fail closed or suspend deterministically
• policy enforcement must remain globally meaningful
• silent reconciliation after divergent local execution is forbidden

Compatibility

This RFC is future-facing and additive.

Compatibility rules:

• current local execution surfaces remain unchanged
• no existing DCP claim is extended to distributed execution by implication
• distributed prototypes remain experimental until explicitly promoted

Implementation Plan

1. Define canonical distributed state/commit identifiers.
2. Define a minimal coordinator/worker protocol with deterministic ordering.
3. Add replayable distributed execution ledgers and verification tooling.
4. Add deterministic fault/partition handling rules for the first prototype.
5. Keep the first distributed surface experimental until RFC-0043 evidence exists.

Open Questions

• Should the first prototype use a single coordinator or a consensus-like ordering group?
• What is the smallest useful distributed surface: replicated task execution, distributed dataflow nodes, or distributed artifact/materialization?
• What minimum evidence package is required before any distributed surface can move beyond experimental?

Acceptance Criteria

• Global state identity, commit identity, and conflict-resolution rules are explicitly defined.
• Network arrival order is explicitly excluded as a semantic ordering source.
• Replay/evidence artifacts are defined for distributed execution.
• Fault/partition behavior is deterministic and fail-closed or deterministically suspended.
• Distributed execution is explicitly classified as experimental / non-DCP until separately promoted.

Implementation Record (2026-03-22)

All acceptance criteria are satisfied as of this date.

AC1 — Global state identity, commit identity, and conflict-resolution rules explicitly defined: spec/tisc-spec.md §5.2.7 (“Distributed Deterministic Execution Protocol (RFC-0053)”) defines three subsections covering these requirements: “Global State and Commit Identity” mandates canonical state identifiers, canonical epoch/commit identifiers, canonical input artifact identifiers, and explicit versioning semantics; “Global Ordering Rule” requires canonical input, dependency, and conflict-resolution order; “Conflict Resolution” enumerates the four allowed deterministic resolution strategies (canonical commit order, explicit tie-break keys, canonical metadata winner selection, fail-closed rejection).

AC2 — Network arrival order explicitly excluded as a semantic ordering source: spec/tisc-spec.md §5.2.7 “Global Ordering Rule” table explicitly lists “Network arrival order” with the requirement “MUST NOT define semantics.” The “Conflict Resolution” subsection lists “first packet wins” and “host clock or wall-clock precedence” as forbidden tiebreak strategies. This exclusion is unconditional and normative.

AC3 — Replay/evidence artifacts defined for distributed execution: spec/tisc-spec.md §5.2.7 “Replay and Evidence Requirements” enumerates five required artifacts: canonical input set, canonical graph/state metadata, canonical commit ledger, node participation records, and deterministic result hash or equivalent replay summary. The section states these artifacts “MUST fit within the RFC-0043 conformance model,” binding distributed execution to the same evidence standard as local verified surfaces.

AC4 — Fault/partition behavior deterministic and fail-closed or deterministically suspended: spec/tisc-spec.md §5.2.7 “Fault and Partition Behavior” requires deterministic behavior for all five failure scenarios (node failure, message delay, duplication, partition/quorum loss, retry/rejoin), defines three allowed responses (deterministic abort, rollback to last canonical commit, deterministic suspension), and forbids speculative continuation with ambiguous semantics and silent local completion with later reconciliation.

AC5 — Distributed execution explicitly classified as experimental / non-DCP until separately promoted: spec/tisc-spec.md §5.2.7 “DCP Boundary Rule (RFC-0053)” states: “Distributed execution is experimental / non-DCP by default.” It enumerates three reasons promotion requirements are stricter (state synchronization, network fault surfaces, larger replay/ledger obligations) and explicitly forbids inheriting DCP status from a DCP-verified local executor. The docs/governance/DETERMINISM_SURFACE_REGISTRY.md §4 lists “Distributed Execution” under “Experimental / Planned” with the gate: “must satisfy RFC-0053 before deterministic claims are expanded.”

This site is open source. Improve this page.