Compositional Execution Through Recursive Delegation: Parent-Child Lineage Tracking

Mechanism

Recursive delegation proceeds through four stages: scope derivation, subordinate issuance, independent execution, and aggregation. In the scope derivation stage the parent object computes the scope to be granted to each subordinate as a strict subset of its own. Scope here includes the trust-zone tags, capability grants, jurisdictional markers, resource budgets, and policy bindings under which the subordinate will be permitted to execute. The derivation function is deterministic and produces scopes whose union is no greater than the parent's; the platform enforces this property structurally so that a parent cannot, by any sequence of delegations, grant a subordinate any capability it does not itself possess. The derivation function is recorded in the parent's policy field, so a verifier can reproduce the partition given the parent's scope alone and check it against the scopes actually issued.

In the subordinate issuance stage the parent constructs each subordinate object. Construction includes copying the derived scope into the subordinate's policy field, recording the parent's identity and lineage position in the subordinate's initial lineage entry, decrementing the depth counter inherited from the parent, and signing the subordinate's issuance with the parent's current execution credential. The subordinate, once issued, is a standalone semantic object that may be routed, scheduled, and executed independently of the parent. The parent retains a reference to each subordinate it issued so that aggregation can occur, but it does not retain control over the subordinate's runtime behavior beyond the scope encoded at issuance. This separation between issuance and runtime control is what makes the mechanism orchestrator-free: once a subordinate is issued, its execution is governed by data carried within the subordinate itself rather than by ongoing coordination with the parent.

In the independent execution stage each subordinate is dispatched through the memory-resident execution machinery. It may itself recursively delegate, subject to the depth counter and to its own scope. Subordinates may execute on different substrates, in different epochs, and across administrative boundaries. The execution proceeds asynchronously; the parent does not block on any single subordinate but instead awaits the aggregation barrier defined in its own policy. Because execution is independent, the failure of any individual subordinate does not propagate to its siblings or to the parent except through the aggregation rule, which may be configured to tolerate partial completion. A subordinate that fails to return within its budget produces a lineage entry recording the timeout, and the parent's aggregation rule treats the absence as a defined input rather than as an exceptional condition.

In the aggregation stage the parent collects results returned by its subordinates and folds them into its own memory field according to a parent-defined aggregation rule. The aggregation rule is recorded in the parent's policy field at issuance, so the function applied at aggregation is the same function that an auditor would expect from inspection of the parent. Each subordinate's contribution is recorded in the parent's lineage as an explicit entry naming the subordinate, its final lineage position, and the digest of the result it returned. The parent's post-aggregation memory state is therefore reconstructable from the lineage of the parent and the lineages of its subordinates considered together. The aggregation entry is the parent's commitment to a final reasoning state: once recorded, the parent's memory is the deterministic image of the recorded subordinate digests under the recorded aggregation rule, and any verifier can recompute that image without consulting any runtime state.

Cycle freedom is enforced by two mechanisms. First, the depth counter, decremented at each delegation, prevents unbounded recursion: when the counter reaches zero, no further delegation is permitted, and any attempt to issue a subordinate beyond the bound produces a structural error rather than an additional subordinate. Second, before issuing a subordinate, the parent records its own ancestry in the subordinate's lineage, and the platform checks that the prospective subordinate does not appear in that ancestry. The check is local because the ancestry travels with the parent. The combination produces a directed acyclic delegation graph rooted at the originating object. Acyclicity is therefore not an emergent property requiring global coordination; it is an invariant maintained by every issuance event using only object-local data.

Operating Parameters

Four parameters govern delegation behavior. The first is the depth bound. Bounds set close to zero limit recursion to a single level of decomposition, suitable for tasks with predictable structure; larger bounds support open-ended decomposition at the cost of larger lineage records. The platform enforces a global maximum depth above which no delegation is permitted regardless of object policy, preventing pathological objects from consuming unbounded substrate state. The depth bound is committed to at issuance by the originating object, so a subsequent runtime cannot lift the bound by reissuing the object under fresh policy.

The second parameter is the fanout bound at each delegation step. A parent may issue up to its fanout bound subordinates from a single delegation event. Larger fanouts permit broader parallel decomposition; smaller fanouts conserve substrate capacity. As with depth, the fanout bound is enforced at issuance and verified at execution by the substrate hosting the parent. The interaction of depth and fanout produces a structural ceiling on the total subordinate population descended from any originating object: the population is bounded above by the product of the per-step fanouts up to the depth bound, and substrates can refuse to host objects whose declared bounds would produce populations exceeding their capacity.

The third parameter is the scope-derivation policy. The policy specifies how the parent's scope is partitioned among subordinates. Common policies include uniform partition, capability-typed partition, and resource-weighted partition. The selected policy is recorded in the parent's policy field, so any auditor can reproduce the derivation given the parent's scope and the issued subordinates. Policies are drawn from a published catalog rather than configured ad hoc, ensuring that the partition function applied to the parent's scope is well-defined and reproducible from public information.

The fourth parameter is the aggregation rule. Aggregation rules range from simple concatenation through commutative reductions to ordered folds. Each subordinate's result is tagged with a sequence number assigned at issuance so that order-sensitive aggregation rules can apply correctly even when subordinates return out of order. Rules that are not commutative require the parent to wait for all outstanding subordinates before producing a final memory state; commutative rules permit partial aggregation as subordinates complete. The rule selection also determines the parent's tolerance for missing subordinates: rules that admit absorbing elements can complete with partial input, while strict rules require all subordinates to report.

Beyond these parameters, several invariants are non-negotiable. A subordinate's scope must be a subset of its parent's; the depth counter must strictly decrease at each delegation; the parent's lineage must record every subordinate it issues; and the subordinate's lineage must record its parent. These invariants are checked at issuance, at execution, and at aggregation, so a subordinate that violates any of them is structurally rejected rather than merely demoted in trust. The triple-checking is deliberate redundancy: the issuance-time check prevents malformed subordinates from ever existing, the execution-time check prevents corrupted subordinates from running, and the aggregation-time check prevents the parent from accepting results from a subordinate whose lineage was tampered with after issuance.

Alternative Embodiments

In a first embodiment subordinates execute on the same substrate as the parent. The lineage and scope mechanisms operate identically, but the additional substrate-migration logic is exercised only when the parent itself migrates. This embodiment is appropriate for compute-intensive decomposition that does not benefit from distribution, and it minimizes the inter-substrate traffic that would otherwise be consumed by issuance, dispatch, and result return.

In a second embodiment subordinates are dispatched to substrates selected by the dynamic routing protocol on the basis of the subordinate's scope and the substrates' attested trust state. This embodiment supports geographically or jurisdictionally constrained decomposition in which different subordinates must execute in different trust zones to satisfy regulatory or policy requirements. Routing decisions for each subordinate are independent: a parent may issue some subordinates that route to one jurisdiction and others that route to a different jurisdiction, and aggregation reconciles the results as the parent's policy specifies.

In a third embodiment the aggregation rule is itself executed by a designated aggregator subordinate rather than by the parent directly. The parent issues subordinates with an aggregator reference, and the aggregator collects results, applies the rule, and returns the folded value to the parent. This embodiment supports decomposition patterns in which aggregation is more resource-intensive than any individual subordinate's task, allowing the aggregation work to be placed on a substrate selected for that purpose rather than on the substrate hosting the parent.

In a fourth embodiment subordinates are issued speculatively, with cancellation tokens that allow the parent to retract a subordinate before its results are aggregated. The cancellation is recorded in the parent's lineage as an explicit retraction entry, preserving auditability while permitting opportunistic parallelism. Speculative issuance is particularly suited to decompositions where the parent does not know in advance which branches will be needed, and would prefer to issue all candidate branches and retract the unneeded ones than to wait for sequential evaluation to reveal which branches matter.

In a fifth embodiment delegation is performed under a threshold scheme in which a quorum of cooperating parents jointly issues a subordinate whose scope is the intersection of the parents' scopes. This embodiment supports federated decomposition in which no single parent has authority to issue the subordinate alone, and the subordinate's lineage records the threshold signature rather than a single parent's signature. Verifiers distinguish threshold-issued subordinates from singly-issued ones by inspection of the issuance signature.

In a sixth embodiment the depth counter is replaced by a credit system in which each delegation consumes credit drawn from a parent-owned budget. Credits permit non-uniform recursion in which a parent may delegate deeply along one branch while delegating shallowly along another, subject to the total budget. Credits are themselves a scope element that decreases monotonically along any descent in the delegation graph, so the budget cannot be replenished by descendants.

In a seventh embodiment subordinates may produce intermediate results that are streamed to the parent before final completion. The parent records each intermediate result as a partial-aggregation entry in its lineage, and the final aggregation includes the digest of the streaming sequence. This embodiment supports long-running subordinates whose progress should be observable without waiting for completion, while preserving the auditability of the final aggregated state.

Composition With Other Primitives

Recursive delegation composes with the substrate-identity layer through the execution credentials carried by parent and subordinate. Each issuance is signed under the parent substrate's current Dynamic Device Hash; the subordinate's lineage records that hash, allowing auditors to confirm that the parent was a trusted substrate at the moment of issuance even though the hash itself rotates. Because the DDH rotates synchronously across the fleet, a subordinate issued at one epoch carries an identity reference that can be verified against the published epoch schedule without revealing any persistent identifier of the parent's substrate.

Delegation composes with the dynamic routing protocol through the scope and policy fields carried by each subordinate. When a subordinate is dispatched to a remote substrate, the routing layer consults the subordinate's scope predicates and selects a path consistent with them. The routing layer treats subordinates as ordinary semantic objects and does not require special-case handling for delegation; the routing semantics are preserved by composition rather than by extension. The subordinate's lineage carries the parent's path so that routing decisions for the subordinate can reference the parent's history, which prevents subordinates from being routed through substrates that the parent's scope explicitly excluded.

Delegation composes with the lineage layer by writing into it at every stage. Issuance produces a parent-side lineage entry and a subordinate-side initial entry; execution produces additional entries within the subordinate's lineage; aggregation produces a parent-side entry recording the digest of the result. Auditors reconstructing the execution of a complex object traverse the parent's lineage to discover its subordinates, then recurse into each subordinate's lineage to discover the next level. The traversal terminates because the depth bound is finite. The lineage layer thus encodes the full execution tree of any complex object, retrievable from the originating object alone without any external orchestration record.

Delegation composes with the policy layer by binding the aggregation rule, the scope-derivation policy, and the depth and fanout bounds to the parent at issuance. Because the policy is bound rather than configured at runtime, the runtime cannot alter the delegation semantics of an issued object. This composition supports auditing without runtime cooperation: the parent's behavior is fully specified by its policy field together with the lineage of its subordinates, so an auditor can reconstruct the parent's reasoning trajectory from the parent's policy and the recorded subordinate results without any active interrogation of the runtime that hosted the execution.

Delegation composes with the substrate-trust layer by subjecting each subordinate's hosting substrate to the same trust evaluation that any other semantic object would face. A subordinate cannot be hosted on a substrate that the subordinate's scope rejects, regardless of the parent's trust posture. This composition prevents a parent from laundering trust by issuing subordinates that execute on substrates the parent itself would not be permitted to use, because the subordinate's scope is a subset of the parent's and inherits all of the parent's exclusions.

Prior-Art Distinctions

Conventional task-orchestration systems, including DAG-based workflow engines and actor frameworks, decompose work into subordinate units but rely on a centralized coordinator to track parent-child relationships and aggregate results. The coordinator is a single point of failure whose loss strands the in-flight decomposition, and the coordinator is also the trust boundary: a subordinate's authority derives from the coordinator's runtime, not from a portable credential carried by the subordinate. Recursive delegation, by contrast, records the parent-child relationship in the lineage of the objects themselves and binds the subordinate's authority through scope inheritance, so the relationship and the authority both survive the loss of any external coordinator.

Continuation-passing systems and futures-based concurrency models capture suspended computation in a closure that the runtime resumes when results are available. They do not propagate scope through the closure; the closure executes with the authority of the runtime that holds it. Recursive delegation propagates scope explicitly through the subordinate's policy field and bounds the subordinate's authority to a strict subset of the parent's at construction. The difference is structural: continuations defer computation, while delegation issues independent objects whose authority is intrinsic rather than ambient.

Capability-based systems support delegation by passing capabilities to subordinate processes, but the chain of delegation is typically not recorded in an auditable structure that survives outside the runtime. Recursive delegation records every delegation event in append-only lineage, so the chain is reconstructable after the fact without any runtime cooperation. Furthermore, capability systems generally do not enforce a strict subset relation across delegation; they permit attenuation but also permit certain forms of capability composition that produce new authorities not held by either delegator. The recursive-delegation mechanism prohibits such composition by structural construction.

Recursive query systems, such as those expressed in datalog with stratified negation or in SQL with recursive common table expressions, perform recursive evaluation but do so within a single query engine and do not produce per-step lineage records. Recursive delegation operates at the object granularity and across substrates, with a lineage record produced at each step. The recursion in datalog is a logical fixed-point computation; the recursion in delegation is a physical decomposition of work into subordinate objects, each of which is itself a first-class executable artifact.

Hierarchical microservice architectures decompose work across services that call one another, but the call graph is typically reconstructed post hoc from distributed tracing infrastructure rather than from intrinsic object lineage. Trace data lives outside the objects it describes and may be incomplete, lost, or tampered with. Recursive delegation makes the call graph intrinsic to the objects, so the trace is always complete and always tamper-evident: any modification to a lineage entry breaks its hash chain and is detectable on inspection.

Disclosure Scope

The disclosure of US 19/538,221 covers the recursive delegation mechanism described above, including the four-stage scope-derivation, issuance, execution, and aggregation process; the configurable depth bound, fanout bound, scope-derivation policy, and aggregation rule; the alternative embodiments enumerated for same-substrate execution, routed dispatch, designated aggregator, speculative issuance with cancellation, threshold issuance, credit-based recursion, and streaming intermediate results; and the composition interfaces to the substrate-identity layer, the dynamic routing protocol, the lineage layer, the policy layer, and the substrate-trust layer. The scope further covers any equivalent embodiment in which a parent semantic object decomposes its objective into subordinate objects whose scope is a subset of the parent's, whose delegation depth is bounded, whose ancestry is recorded in append-only lineage, and whose results are aggregated into the parent's memory field according to a parent-bound rule. Implementations that omit scope subset enforcement, that permit unbounded recursion, that fail to record parent-child relationships in object-resident lineage, or that rely on external orchestration to track delegation fall outside the claimed scope. Licensees obtain the right to operate the mechanism within the parameters described and to compose recursive delegation with adjacent memory-resident primitives that consume delegation lineage or contribute scope to delegation derivation.