The task shapes the work.

Five changes, five different mechanisms

Growth, morphogenesis, nested Work and composition describe related questions. They should lead to a concrete change in the work that runs. Changing a parameter, retaining a child result, obtaining a known capability and writing new implementation code are distinct operations. The following five routes show where each happens and what their evidence supports.

Changed wishes become changed computation

In Wedding W3, Gemini returns objectives and typed amendments that become compiler inputs. Protected conditions remain in force while the revised problem can produce a different arrangement. A later SR3 request asks for validation, so the programme validates and consumes the existing arrangement without another solve.

That is a change in the requested computation. It does not require inventing a new capability implementation. The model supplies bounded semantic material; runtime checks and materialises the supported Work. The Wedding Reader preserves the exact returned fields, their consumer and the distinction between W3 and the separate W4 hardware episode.

A lost resource changes the affected branch

In Workspace EWS3R2, an AudioSink process stops with return code −9. Continued media Work changes from four to sixteen frames while the existing PCM count stays 16,000. Photograph production remains at three, with the previous preview hash retained. The downstream consumer names both the recomputed and the preserved result.

This is selective continuation: recompute what depended on the changed resource and retain what is still useful. A fresh observation supplies the new basis. It does not renew the old action packet; saving still has its own current approval.

Keep one child result and recompute another

A parent Work item needs the child's actual output, including its type and identity. In the inspected current composition implementation, WorkOutputBindingV01 names predecessor_work_id, output_field and expected_type. WorkHistoricalOutputV01 additionally binds task, revision, invocation, result, admission and artifact identity to the retained value. A result cannot become a useful parent input merely by appearing in a summary.

The U4 checkpoint reports four retained combinations: native/legacy paths × selected child 0/child 1. The parent consumes the retained child's exact result together with the newly computed selected child's result in canonical slot order. The read-only test source supplies a compact view of the relation:

assert len(retained.retained_consumptions) == 1 and len(retained.cell_results) == 2
consumption = retained.retained_consumptions[0]
parent_result = next(r for r in retained.cell_results if r.parent_cell_id is None)
fresh_result = next(r for r in retained.cell_results if r.parent_cell_id is not None)

These exact lines are from tests/test_work_composition_v01.py lines 933–936, at ref 62716374021e273b46878a824af39c1a94593cd7. The following assertions (937–943) bind the fresh child, preserved original result, canonical parent order and absence of a new queue entry for the retained child. The two new results are the fresh child and parent; the retained child is consumed separately. The site has inspected this test source, not run it. Code attribution: Hedgehog OS, AGPL-3.0-only.

The historical implementation checkpoint supplies the recorded U4 execution scope. The accepted publication ledger S11 distinguishes implemented composition, source assertions and checkpoint-reported execution. No raw U4 archive is presented here as newly revalidated.

Missing a pure capability? Find, review and continue

Work can discover a missing implementation during its own continuation. observe_missing_pure_need_v01 requires an actual NEEDS_CAPABILITY result without an invocation or output. It resolves the item's real input and binds the need to the current task, revision, topology and source. The need is more specific than an initial free-text search.

The bounded memory path then:

1. Searches local DRS with current Host time and exact contract, owner, memory-scope and profile filters.
2. Requires a unique eligible candidate and checks temporal fitness and ranking.
3. Obtains Root-reviewed descent for one artifact with an explicit byte budget.
4. Reads the bounded payload, checks its hash and independently admits the pure implementation again.
5. Installs the admitted capability through the continuing Work path, executes it and binds its output to the next consumer.

The decisive source operation is visible in capability_memory_binding_v01.py, retrieve_pure_memory_v01, lines 338–341:

data,wasm=_source_payload(payload,need)
attempt,package=pure.admit_pure_candidate_v01(host,need=need,source=wasm,source_format='wasm',contract_version=data['contract_version'],
    expected_revision=host.state_revision)
_require(package is not None,'pure_memory_readmission:'+str(attempt.reason))

Finding the remembered source is followed by current admission. Code attribution: Hedgehog OS, AGPL-3.0-only. This excerpt is data for inspection.

The U3 checkpoint reports one cold generation and zero warm generations, with admission on both paths. The continuation test source, test_u3_cold_warm_actual_same_task_and_canonical_report, checks that each path resumes its own existing task from NEEDS_CAPABILITY to COMPLETED, and that the need output becomes the render invocation input. Cold and warm are distinct tasks; “same task” refers to continuity within each one. The current retrieval Root result is ACCEPT with permission_created=false.

This is a finite local pure-capability route. The inspected implementation and checkpoint do not demonstrate arbitrary child-local DRS search at every nesting depth, general autonomous programming or isolation of arbitrary native plugins. A conceptual relationship between mechanisms does not establish their unrestricted recursive combination.

No implementation exists: author it and admit it

Retrieval reuses an existing capability. Football authorship addresses a different task: an outside AI receives HOW (interfaces and method) and WHAT (the domain problem), creates candidate code and submits it to separate examination. Accepted G54D1 passed 16 native cases; examination and owner source admission remain separate from the author.

A new admitted implementation still needs current inputs and local decisions before a business effect. Workshop explains the practical human roles that organise this work: framing, architecture, execution, review and owner acceptance. The integrated automatic Factory remains future work; the existing authoring experiment and bounded pure generation are not that whole programme.

Use the current route, preserve the historical scope

The architecture lock directs readers to bounded common action, retained results and local reuse. Its historical “Contract Only” block refers to an earlier basis. The retired inventory explicitly classifies fractal_dag_executor.py and the old architect/executor/orchestrator modules as RETIRED_RUNTIME_REFERENCE. Their early placeholders cannot define the present composition implementation.

This page follows work_composition_v01.py, the current memory binding, the checkpoint and publication ledger. Those sources carry different evidence roles. Reading them creates no new acceptance result, and a historical pending caption does not silently become a statement about the entire later publication.

This is the same kernel

Experience changes where finite work is spent; External DRS turns released evidence into checked local input. Both depend on an actual consumer and current grounds for use. One kernel connects these relations, while GEO-1, GEO-3, GEO-4 and GEO-7 distinguish composition, continuation, qualification and creation.

Recorded fields and their scope

An actual retained child result reaches the parent

Current test-source assertions bind one retained consumption, a fresh child and the parent in canonical slot order; the historical U4 checkpoint reports the finite execution matrix.

Record: tests/test_work_composition_v01.py:933-943. Class: inspected implementation and test source with checkpoint report. Scope: Read-only source inspection, no new test run or raw U4 archive revalidation. Arbitrary child-local memory search is not established.

View source — tests/test_work_composition_v01.py:933-943

An observed missing capability becomes a continued task

The current need binds actual input; memory retrieval performs fresh readmission before continuation and typed output consumption.

Record: retrieve_pure_memory_v01; test_u3_cold_warm_actual_same_task_and_canonical_report. Class: inspected implementation and test source with checkpoint report. Scope: Finite pure capability; local DRS. Historical cold generation 1/warm 0 is checkpoint-reported, not newly executed.

View source — retrieve_pure_memory_v01; test_u3_cold_warm_actual_same_task_and_canonical_report

Sources and scope

This page is a website explanation, updated 2026-10-02. Its explanation does not create a new execution result or change the status of its sources.