Six-Action Execution Evaluation Cycle: Parse, Evaluate, Select at Every Node

Mechanism

The execution cycle is the unit of forward progress in a memory-resident execution architecture. A cycle begins when an evaluator binds a persistent semantic object to an execution slot in the substrate. Binding requires three preconditions: the substrate has located the object's lineage tail, the lineage tail's cryptographic chain verifies, and the policy fields recovered from the lineage permit the evaluator to act on the object's behalf. If any of these fail, the cycle does not begin; the substrate emits a binding-failure event and the lineage remains unchanged.

Once bound, the cycle proceeds through four phases. The observe phase reads the inputs available at the cycle boundary: the wake event that triggered the cycle, the policy fields, any substrate-visible counterparty state declared as a dependency by the policy, and the lineage tail that anchors the cycle. Observation is bounded: the evaluator may not introduce additional inputs after the observe phase closes, because doing so would prevent later replay from reconstructing the cycle deterministically. Inputs not consumed during observe are deferred to a subsequent cycle.

The plan phase parses observed intent against local policy and selects exactly one action from a closed action set. The action set comprises six members: execution, in which the object performs work and produces a substrate-visible output; mutation, in which the object changes its own policy fields under the constraints declared by its lineage; delegation, in which the object dispatches a request to another object identified by lineage reference; dormancy, in which the object commits a closed predicate set and releases its evaluator binding; reentry, in which the object re-evaluates an earlier lineage point under the current policy; and termination, in which the object finalizes its lineage and yields its identity. The action set is closed and exhaustive; no seventh action exists. The plan phase always selects exactly one of these six.

The act phase executes the selected action. Each action has a precisely-specified effect on the lineage tail: execution appends an output record, mutation appends a policy-change record, delegation appends a delegation record naming the target lineage, dormancy appends a dormancy commitment record, reentry appends a reentry record naming the prior lineage point, and termination appends a finalization record after which no further records are valid. The act phase is the only phase in which substrate-visible side effects are produced.

The log phase commits the appended record. Commitment is cryptographic: the record is chained to the prior lineage tail by hash, signed by the evaluator under a policy-specified key, and submitted to the substrate. Only on substrate acknowledgment does the cycle close. Until commitment, the act phase's effects are tentative; if commitment fails, the cycle is rolled back to the observe boundary, the act-phase side effects are voided, and the substrate emits a cycle-failure event.

Operating Parameters

Each cycle is bounded by a set of policy-declared parameters. The first parameter is the cycle duration bound: the maximum wall-clock interval from binding to commitment, after which the substrate revokes the evaluator's binding and emits a duration-exceeded failure. Typical bounds range from milliseconds for high-throughput objects to minutes for objects that perform extended observation; the bound is a property of the object's policy, not of the substrate.

The second parameter is the input quota. The observe phase may read at most a policy-declared number of input records and at most a policy-declared total input size. Quotas prevent a single cycle from absorbing an unbounded number of accumulated wake events; surplus inputs are deferred to subsequent cycles in policy-defined order.

The third parameter is the action-selection bound, which constrains the plan phase. The plan phase may consult only the inputs gathered during observe and the policy fields recovered at binding; it may not perform additional substrate reads. This is what makes the cycle deterministically replayable: any party with the lineage tail and the observed inputs can reconstruct the action selection that produced the appended record.

The fourth parameter is the act-phase effect bound. Each action declares a maximum substrate-visible effect: an execution action declares a maximum output size, a mutation declares the policy fields it may change, a delegation declares the target lineage and the maximum dispatch payload, a dormancy commitment declares the predicate-set size, and a termination declares the finalization-record contents. Effects exceeding the declared bound cause the cycle to fail in the act phase, before commitment.

The fifth parameter is the audit obligation. Every cycle is audit-required: the lineage record produced at the log phase must contain enough information that any auditor with read access to the lineage and the observed inputs can verify that the action selected by the plan phase was a valid selection from the closed action set under the recovered policy. This obligation is structural; a cycle that produces a record insufficient for audit is treated as a failed cycle and rolled back.

The sixth parameter is the cycle-priority class. When multiple eligible cycles compete for a finite evaluator pool, the substrate selects cycles in priority order declared by the object's policy. Priority does not affect cycle correctness; it affects only scheduling latency and is itself recorded in the lineage so that priority-driven scheduling decisions are auditable.

Alternative Embodiments

In a first embodiment, the cycle is realized as a single-threaded function call within an evaluator process: observe gathers inputs into a local structure, plan selects an action by direct evaluation, act performs the action by direct call into substrate APIs, and log writes a chained record to local storage that is replicated by a substrate background process. This embodiment is simple and well-suited to single-host deployments.

In a second embodiment, the cycle is realized across multiple processes with explicit phase boundaries: observe is performed by a substrate-side input-gathering service, plan is performed by an isolated evaluator sandbox, act is performed by a substrate-mediated effect dispatcher, and log is committed via a quorum-replicated ledger service. The phase decomposition permits each phase to be independently scaled and independently audited.

In a third embodiment, the cycle is realized with deterministic replay support: the observe phase records its inputs verbatim into a replay buffer chained into the lineage, so that any subsequent verifier can re-execute plan and act and confirm that the appended record is the result. This embodiment trades a small increase in lineage size for cryptographic-strength auditability, suitable for regulated deployments.

In a fourth embodiment, the cycle's plan phase is implemented by a learned policy module, with the constraint that the module's output remains within the closed six-action set. The module receives observed inputs and policy fields and emits an action selection plus a justification record; the justification is appended alongside the action record so that the audit obligation is preserved even when the selection mechanism is non-deterministic in detail.

In a fifth embodiment, multiple evaluators participate in a single cycle through a quorum-evaluator protocol. Each participating evaluator performs observe and plan independently; the cycle's action is the action selected by quorum agreement. Disagreement among evaluators is itself a substrate-visible signal recorded in the lineage. This embodiment is appropriate where no single evaluator is fully trusted.

In a sixth embodiment, the cycle structure is preserved while the action set is parameterized by policy: a deployment may declare which subset of the six actions is available to a given object class. Such restriction is recorded in the policy fields and is verified at binding; an attempt to select a disallowed action causes plan-phase failure.

Composition

The execution cycle is the surface across which all other mechanisms of the architecture compose. Dormancy and reentry are members of the action set, so the dormancy mechanism described in the companion article occurs as the act phase of a cycle whose plan phase selected dormancy. Failure signals, described in the companion article, are emitted by the substrate when a cycle's binding, observe, plan, act, or log phase fails; the cycle is the unit at which failure becomes substrate-visible.

Lineage composition flows naturally from the cycle: every cycle appends exactly one record, so the lineage of an object is precisely the sequence of cycle outcomes that has been committed for it. There is no record in the lineage that is not the product of some cycle, and no cycle that completes without producing a record. This bijection is the structural reason the lineage is audit-complete.

Substrate-event composition also flows from the cycle: the substrate's event interface emits events at the four phase boundaries (binding, plan, act, commitment) and at cycle failure, which is sufficient for any external observer to construct a picture of an object's current execution state without access to the evaluator. Composition with delegation is symmetric: a delegation action in one object's act phase generates a wake event that becomes an observe-phase input in another object's subsequent cycle, with both records chained into their respective lineages.

Prior-Art Distinction

The execution cycle described here differs from prior-art event loops, actor message-handler invocations, and step-function executions in three structural respects. First, the action set is closed and exhaustive at six members, with each action having a precisely-specified lineage effect; conventional event loops and actor handlers permit arbitrary side effects with no structural constraint, and step-function executions fix a specific workflow rather than a per-cycle action selection.

Second, every cycle is audit-required by structural mandate, and the record produced at the log phase is sufficient for an external auditor to verify the action selection. Prior-art mechanisms typically record outcomes (for example, completion or failure) but do not require that the recorded outcome contain enough information to verify the selection logic; auditing such systems requires access to evaluator-internal logs that are outside the structural guarantee.

Third, the cycle is bounded in duration, input, effect, and priority by parameters carried in the object's policy fields rather than configured at the runtime. Prior-art systems typically bind such limits to the runtime configuration, so the same workload exhibits different bounds on different deployments; here the bounds travel with the object, so cycle behavior is portable across substrates without policy reconfiguration.

Disclosure Scope

The disclosure of the execution cycle is intended to support claim coverage of: any execution architecture in which forward progress proceeds as a sequence of bounded cycles, each comprising an observe phase, a plan phase that selects exactly one action from a closed action set, an act phase, and a log phase that cryptographically commits a single lineage record; any such architecture in which the closed action set comprises execution, mutation, delegation, dormancy, reentry, and termination, individually or in combination; any such architecture in which cycle bounding parameters travel with the persistent semantic object as policy fields rather than as runtime configuration; and any such architecture in which the lineage record produced at the log phase is structurally sufficient to verify the action selection without access to the evaluator.

The disclosure extends to all alternative embodiments described above and to any equivalent embodiment that preserves the structural properties of phase decomposition, closed action set, audit obligation, and policy-borne bounding. This article forms part of the technical disclosure supporting US 19/538,221.