Dormancy as First-Class Execution State: Valid Suspension Without Failure

Mechanism

The dormancy mechanism operates as a deterministic transition between two well-defined execution states maintained by the substrate on behalf of a persistent semantic object. In the active state, the object is bound to an evaluator, occupies execution memory sufficient for its current cycle, and is eligible to consume input events. In the dormant state, the object releases its evaluator binding, releases all transient working memory associated with the prior cycle, but retains its identity, its policy fields, its accumulated lineage, and a substrate-recorded marker that designates it as dormant rather than terminated.

Entry into dormancy is initiated when an in-progress execution cycle reaches a checkpoint at which the object's local evaluation determines that no further immediate work is required. The evaluator constructs a dormancy commitment record consisting of the object identifier, the lineage hash at the point of suspension, the substrate-observable predicate or predicates whose satisfaction will return the object to active evaluation, and the policy fields that govern the dormancy interval itself. The commitment record is appended to the object's lineage, cryptographically chained to the prior record, and submitted to the substrate. Only upon acknowledgment by the substrate is the evaluator binding released.

Resumption from dormancy is initiated by the substrate, never by the object. The substrate continuously evaluates the predicates submitted by dormant objects against incoming events, time markers, and substrate-internal state changes. When a predicate is satisfied, the substrate issues a wake event that selects an eligible evaluator, rebinds the dormant object's lineage, restores its policy fields into the evaluator's working memory, and dispatches the wake event as the first input of a new execution cycle. The object resumes from a clean cycle boundary; it does not resume mid-cycle, because the dormancy commitment was always taken at a cycle boundary.

Throughout this process, the dormant lineage is preserved. The lineage chain is not broken across dormancy, and the dormancy commitment itself becomes a permanent ledger entry that anyone auditing the object can inspect. Dormancy is therefore visible: the system never silently drops or hides a workload, and a downstream consumer querying the substrate can distinguish a dormant object from a failed object from a terminated object by inspecting the most recent ledger record without needing access to the evaluator.

Operating Parameters

Several parameters bound the dormancy mechanism and are recorded in the policy fields that travel with the semantic object. The first is the dormancy footprint: the maximum size of the lineage and policy state retained while dormant, expressed as a substrate-allocation quota. In typical embodiments this footprint is one to three orders of magnitude smaller than the active execution footprint, because all transient working memory is released. The footprint floor is set by the size of the lineage tail required to verify the cryptographic chain on resumption.

The second parameter is the dormancy interval bound. Each dormancy commitment carries either a maximum interval, after which the substrate must issue a wake event regardless of predicate satisfaction, or an explicit unbounded marker indicating that the object is willing to remain dormant indefinitely. Bounded dormancy is appropriate for workloads with downstream timing obligations; unbounded dormancy is appropriate for objects whose only meaningful trigger is an external event of unknown arrival.

The third parameter is the predicate set. A dormancy commitment may name one or more predicates, evaluated by the substrate on a logical-or basis: the satisfaction of any single predicate is sufficient to wake the object. Predicates may include arrival of a named event class, presence of a specified counterparty in the substrate, expiration of a named timer, or transition of a named substrate-observable variable across a threshold. The predicate set is closed at the time of commitment; the dormant object cannot add predicates while dormant, because the dormant object is not executing.

The fourth parameter is the resumption policy: a specification of how the object should behave when more than one wake-eligible event accumulates during the dormancy interval. The two principal modes are coalesced resumption, in which the substrate delivers a single wake event annotated with the count and types of accumulated triggers, and sequenced resumption, in which the substrate delivers each accumulated trigger as a distinct cycle input.

The fifth parameter is the dormancy-failure mode. Although dormancy is by definition not failure, the substrate may itself fail to honor a dormancy commitment, for example by losing the marker, exceeding the maximum interval without dispatching a wake event, or being unable to locate an evaluator on resumption. These conditions are signaled to consumers as substrate failure events distinct from object failure, with the dormant object's lineage remaining intact and recoverable on a different substrate.

Alternative Embodiments

Several alternative embodiments fall within the disclosed scope. In a first embodiment, dormancy is implemented within a single-substrate deployment, where the substrate is a long-lived process on a single host and dormant lineage is held in process memory backed by local persistence. This embodiment is suitable for edge installations and emphasizes the minimal-footprint property: dormancy in such a deployment may persist across host restarts because the lineage is journaled to local storage on commitment.

In a second embodiment, dormancy is implemented across a federated multi-substrate deployment, where a dormant object's lineage is replicated to a quorum of substrate participants. Resumption may then occur on any substrate that observes the wake predicate first, and a substrate-level coordination protocol ensures that exactly one evaluator rebinds the object. This embodiment trades a small increase in dormancy footprint for resilience to single-substrate failure.

In a third embodiment, dormancy is implemented as a tiered structure. Recently-active objects use a hot dormancy tier with low resumption latency and slightly higher footprint, while objects that have been dormant for longer than a tier-transition threshold are migrated to a cold tier with higher resumption latency and a smaller footprint. The tier transition is itself a substrate-driven operation, recorded in the lineage, and does not require participation from the dormant object.

In a fourth embodiment, the wake predicate is itself a derived semantic object, evaluated by the substrate against compound conditions that may include the dormancy state of other objects. This permits coordinated wake patterns: a population of dormant objects may all wake on the satisfaction of a single shared condition, or they may wake in a defined sequence governed by their respective predicates. In all such cases, each dormancy commitment remains an independent lineage entry, and no object's resumption is contingent on participation from any other object's evaluator.

In a fifth embodiment, dormancy commitments include a substrate-mobility flag, permitting the dormant lineage to be migrated between substrates during the dormancy interval without resumption. Such migration is recorded in the lineage as a migration event distinct from a wake event, and the resulting substrate inherits the original wake predicate set unchanged.

Composition

Dormancy composes with the surrounding execution-cycle, lineage, and substrate-event mechanisms of the memory-resident execution architecture. With respect to the execution cycle, dormancy is taken only at cycle boundaries, ensuring that an object never enters dormancy with partial results in transient memory. With respect to lineage, the dormancy commitment and any subsequent wake event are append-only entries chained into the same lineage that records active execution, so the lineage of a dormant object is a single coherent history of states rather than two disjoint histories.

With respect to substrate events, dormancy is the principal source of substrate-driven wake events, and consumers of those events use the same substrate-event interface they use to detect failure signals or composition changes. This means that an external observer of the system does not need a distinct dormancy-aware client; any client capable of subscribing to substrate events for a given object will observe its dormancy and resumption transitions in band with all other state transitions of interest.

Dormancy also composes cleanly with delegation and reentry. A dormant object may be the target of a delegation request issued by another object, in which case the substrate's predicate engine will treat the delegation arrival as a wake predicate; the delegated request becomes the first input of the resumed cycle. Reentry, in which a workload re-evaluates an earlier lineage point, is permitted from dormancy because the dormant lineage tail remains available; reentry from dormancy first wakes the object and then performs the reentry within the resumed active cycle.

Prior-Art Distinction

Dormancy as defined here is distinct from several superficially similar prior-art mechanisms. Process suspension on conventional operating systems suspends execution but does not preserve a verifiable lineage and offers no structural distinction between intentional dormancy and stalled or failed processes; an external monitor must infer the difference from heuristic signals. Workflow-engine sleep states preserve a lineage of sorts but rely on a centralized scheduler whose failure causes loss of dormant work, and whose schedule is opaque to the workload itself.

Serverless cold-start mechanisms release execution memory between invocations but discard semantic identity at the same time; each warm-start is a fresh object whose connection to prior invocations is reconstructed only through external state held in a separate database. Actor-model passivation, the closest prior-art analog, releases an actor's memory and is governed by an actor system, but conventional actor-system passivation does not maintain a tamper-evident lineage chain across the passivation boundary, does not expose the passivation state as a substrate-observable first-class event, and requires the same actor system to perform reactivation, which couples passivation to a specific runtime.

The dormancy mechanism described here differs in three structural respects: (a) the dormant object's lineage is cryptographically chained across the dormancy boundary so that resumption can be audited end-to-end, (b) the dormancy state is exposed as a first-class substrate event observable by any consumer without privileged access to the evaluator, and (c) resumption is substrate-triggered on a closed predicate set rather than runtime-coupled, so the evaluator that resumes the object need not be the evaluator that suspended it.

Disclosure Scope

The disclosure of dormancy as a first-class execution state is intended to support claim coverage of: any execution architecture in which a persistent semantic object's intentional suspension is recorded as a chained lineage entry distinct from failure and termination; any architecture in which dormant objects retain a minimal substrate footprint and are resumed exclusively by substrate-evaluated predicate satisfaction; any architecture in which the dormancy state is exposed to external consumers through a substrate-event interface common to other state transitions; and any combination of these in which the dormancy commitment names a closed predicate set evaluated by the substrate on the dormant object's behalf.

The disclosure further extends to multi-substrate, tiered, mobile, and predicate-derived embodiments described above, and to any equivalent embodiment in which the substantive structural properties of dormancy as a first-class state, lineage continuity across the dormancy boundary, substrate-driven resumption, and minimal preserved footprint are present. This article forms part of the technical disclosure supporting US 19/538,221.