Latency and Failure as Semantic Signals: Structured Inputs From Adverse Conditions

Mechanism

The failure-signal mechanism operates as a structurally enforced channel through which the substrate publishes adverse conditions affecting persistent semantic objects. A failure signal is generated whenever a cycle, a delegation, a dormancy commitment, a substrate operation, or a counterparty interaction associated with a particular object cannot be completed under the bounds declared by the object's policy. The signal is structured: it consists of an event type drawn from a closed enumeration, the lineage reference of the affected object, the cycle identifier or operation identifier whose failure produced the signal, the bound that was violated, and the substrate-observable evidence that supports the signal.

Generation of a failure signal is the substrate's responsibility, not the workload's. When an evaluator's cycle exceeds its duration bound, when a delegation request fails to reach its target within the declared dispatch interval, when a dormancy commitment cannot be honored within the maximum interval, or when a substrate-internal invariant is violated, the substrate itself constructs the failure record and appends it to the affected object's lineage. The workload does not need to detect or report the failure for the signal to exist; substrate-detected failure is what makes the signal authoritative.

Consumers detect failure signals through the substrate-event interface. They subscribe to the lineage of an object of interest, or to a substrate-wide failure feed, and receive failure records as they are appended. Detection through the substrate, rather than through liveness probes or RPC timeouts, is structural: a consumer that polls an evaluator directly may receive misleading information if the evaluator itself has failed; a consumer that subscribes to the substrate sees authoritative records constructed by the substrate's own failure-detection logic.

Tamper-evidence is achieved by the same chained lineage commitment that secures success records. Each failure signal is hashed against the prior lineage tail, signed by the substrate under its policy-declared signing key, and persisted to the substrate's commitment store. A subsequent attempt to alter or remove a failure record breaks the cryptographic chain and is detectable by any verifier with the lineage tail. The substrate cannot silently retract a failure signal, and a malicious or compromised evaluator cannot suppress one.

Failure signals participate in the closed event vocabulary of the architecture. The principal event types are: cycle-duration-exceeded, observe-quota-exceeded, plan-failure, act-bound-exceeded, log-commitment-failure, delegation-dispatch-failure, delegation-target-failure, dormancy-interval-exceeded, dormancy-marker-loss, binding-failure, and substrate-disruption. Each event type carries a defined set of fields. Consumers may dispatch on event type with the assurance that the type set is closed and that the field set for each type is stable.

Operating Parameters

Several parameters govern the failure-signal mechanism. The first is the detection-latency bound: the maximum interval, declared by substrate policy, between the substrate's observation of a failing condition and the appending of the corresponding failure signal to the lineage. Bounded detection latency permits consumers to reason about the freshness of the failure feed; an absent failure signal beyond the detection-latency bound is structurally equivalent to confirmation that no detected failure has occurred up to the corresponding instant.

The second parameter is the signal-redundancy mode. Failures detectable by multiple substrate components, for example a delegation failure observable both at the dispatcher and at the target side, may be signaled once with consolidated evidence or independently by each detecting component. The mode is recorded in the signal so that consumers correlating multiple signals know whether they describe the same underlying failure or distinct failures of the same operation.

The third parameter is the failure-classification policy. Each failure signal carries a classification: transient, durable, or terminal. Transient failures are conditions that are expected to clear without operator intervention, such as a transient delegation dispatch failure. Durable failures persist until external action is taken. Terminal failures finalize the affected object's lineage in the same manner as the termination action, after which no further records are valid for that object. Classification is determined by the substrate from the event type and bound-violation context.

The fourth parameter is the recovery-eligibility flag. Some failure types permit re-binding and cycle retry; others do not. The flag is set on the failure signal at generation and is the structural input to any subsequent retry decision. A consumer or counterparty that observes a failure with the flag clear knows that no retry is possible and may proceed accordingly.

The fifth parameter is the evidence-payload size bound. Failure signals must carry sufficient evidence for downstream consumers and auditors to verify the substrate's failure-detection conclusion, but unbounded evidence would compromise the lineage's storage profile. The substrate trims evidence to a policy-declared maximum, and where evidence exceeds the bound, the signal carries a digest reference to an external evidence record retrievable through a substrate-mediated interface.

The sixth parameter is the cross-object propagation mode. A failure of one object that has direct lineage dependents, for example through outstanding delegations, may propagate as a structured input to the dependents' next cycle. Propagation is not automatic re-failure; the dependent's policy decides how to act on the input, but the propagation itself is a substrate operation that places the failure signal into the dependents' observe inputs through the same channel as any other event.

Alternative Embodiments

In a first embodiment, failure signals are generated by a single substrate-internal failure-detection module that observes binding, cycle, delegation, and dormancy operations through a unified instrumentation surface. This embodiment is simple and well-suited to single-substrate deployments; the failure-detection module is the sole source of truth for failure signals, and its detection logic is itself recorded in substrate policy for auditability.

In a second embodiment, failure signals are generated by phase-specific detection components, each responsible for a subset of event types: a binding monitor emits binding-failure signals, a cycle-bounds monitor emits cycle-duration-exceeded and act-bound-exceeded signals, a delegation monitor emits delegation-dispatch-failure and delegation-target-failure signals, and a dormancy monitor emits dormancy-interval-exceeded and dormancy-marker-loss signals. Each component is independently scalable and independently auditable, and a substrate-internal coordinator ensures that signals from distinct components are ordered consistently in the affected object's lineage.

In a third embodiment, failure signals are quorum-replicated across substrate participants in a federated deployment. A failure observed by any single substrate participant is proposed to the quorum; only on quorum agreement is the signal appended to the lineage. This embodiment defends against malicious or faulty substrate participants attempting to forge or suppress failure signals, and is appropriate for multi-party deployments where no single substrate is fully trusted.

In a fourth embodiment, the failure-signal mechanism is composed with a substrate-side aggregation index that summarizes failure rates per object class, per substrate region, and per event type. The index is itself a derived semantic object whose lineage records the aggregation logic; consumers may subscribe to the aggregated index for fleet-level observability without losing access to the per-object failure stream.

In a fifth embodiment, the failure-signal mechanism is extended with a structured-input feedback loop in which selected failure signals automatically become observe-phase inputs to a subsequent cycle of the affected object, subject to the recovery-eligibility flag. The loop is policy-governed: the object's policy declares which event types are eligible for self-feedback, with what delay, and under what cycle-priority class. This permits objects to react to their own failures within the standard cycle discipline rather than through an out-of-band exception path.

In a sixth embodiment, failure signals carry cryptographic attestations from the substrate components that detected them, in addition to the substrate-level signing key. Attestations permit auditors to attribute the detection to a specific substrate component, supporting forensic analysis in deployments with diverse substrate operators.

Composition

The failure-signal mechanism composes with the execution cycle, the lineage, the dormancy mechanism, and the substrate-event interface. With respect to the cycle, failure signals correspond to cycle phases and bounds: each phase has at least one associated failure event type, and each policy-declared bound has a corresponding failure event. A consumer who understands the cycle structure understands the failure vocabulary as a direct consequence.

With respect to the lineage, failure signals are first-class lineage records. They are not stored in a side channel or a separate failure log; they appear inline in the affected object's lineage in the order they were committed. This means that a single read of an object's lineage exposes its complete history of successful cycles and substrate-detected failures together, with the ordering relation between the two preserved.

With respect to dormancy, failure signals associated with a dormant object, for example dormancy-interval-exceeded or dormancy-marker-loss, are appended to the dormant object's lineage and emitted as substrate events without requiring the object to wake. This is what permits the dormant lineage to remain recoverable even when the substrate fails to honor a dormancy commitment: the failure is recorded against the lineage rather than lost with the substrate that failed.

With respect to the substrate-event interface, failure signals share the same delivery, ordering, and subscription semantics as success events. There is no second-class status for failure: a consumer subscribing to the lineage of an object receives the full event stream, and may filter on event type if it wishes to process only successes or only failures. The unified interface means that adding failure-aware behavior to a consumer requires no new transport or protocol; it requires only handling additional event types that share the existing record structure.

Prior-Art Distinction

The failure-signal mechanism described here differs from prior-art exception propagation, RPC error returns, and out-of-band monitoring streams in three structural respects. First, failure detection is the substrate's responsibility and is not delegated to consumer-side liveness probes. Prior-art monitoring systems typically rely on consumers polling for health, with the result that a silent evaluator failure is invisible to consumers until their own polling timeout elapses; here, the substrate observes the failure and emits the signal, with bounded detection latency declared in policy.

Second, failure signals are inline lineage records under the same cryptographic commitment as success records, rather than entries in a separate log subject to independent retention and access policies. This means that the failure history of an object is part of the object's audit-complete history, and that retroactive alteration of failure records is structurally prevented. Prior-art logging systems offer at best advisory tamper-evidence and typically permit log rotation, retention, and access controls that make historical failure analysis dependent on infrastructure outside the workload's structural guarantees.

Third, the failure-event vocabulary is closed and aligned with the structural primitives of the architecture rather than open-ended and string-typed. Prior-art exception types are extensible by application code, with the result that two consumers may classify the same failing condition differently. Here, the event type set is fixed at the level of the architecture, and each type carries a stable field set, so that classification is determined structurally and consistently.

Disclosure Scope

The disclosure of the failure-signal mechanism is intended to support claim coverage of: any execution architecture in which adverse conditions affecting persistent semantic objects are emitted by the substrate as first-class events drawn from a closed event vocabulary; any architecture in which failure events are appended to the affected object's lineage under the same cryptographic commitment that secures success records, providing tamper-evident failure history; any architecture in which consumers detect failures through a substrate-event interface rather than through consumer-side liveness probes or RPC error returns; and any architecture in which failure signals are bounded by a substrate-declared detection latency that permits absence of a signal to be treated as an authoritative indication of no detected failure up to a corresponding instant.

The disclosure further extends to all alternative embodiments described above, including phase-specific detection components, quorum replication, aggregation indices, structured-input feedback loops, and component-level attestations. The disclosed scope encompasses any equivalent embodiment that preserves the structural properties of substrate-emitted failure detection, lineage-inline tamper-evident commitment, closed event vocabulary, and unified substrate-event delivery. This article forms part of the technical disclosure supporting US 19/538,221.