Lesson 2: Inputs, Outputs, and Dependencies

Systems do not run on words. Systems run on inputs, they perform functions, and they produce outputs. If you want to evaluate a biological explanation, you must track those three things. This lesson teaches you how to do that in a clean, disciplined way so hidden assumptions cannot hide inside the claim.

Start with inputs. Inputs are anything the system must receive to operate. In biology, inputs often include energy, raw materials, environmental conditions, and timing signals. In lab studies, inputs can also include purified reagents, pre-built components, controlled cycles, and human selection of conditions. Those are not small details. If an explanation requires them, they belong in the audit.

A practical rule helps here. If the system stops working when you remove something, that something is an input or a dependency. It does not matter whether it looks “natural” or “artificial.” It matters because it is required for function.

Next, define outputs. Outputs are the measurable results the system produces. Outputs can be products, behaviors, signals, or system-level performance. A strong evaluation requires that outputs be stated in measurable terms. “It forms something like RNA” is not an output. “It produces RNA strands of length X with property Y under condition Z” is an output. Outputs must be clear enough that another person could verify them without guessing what you meant.

Now we come to dependencies. Dependencies are the conditions or supporting structures the system relies on, even if they are not named as inputs. Dependencies can be stability of temperature, repeated wet-dry cycles, a narrow pH range, an isolation mechanism that prevents interference, or an error-correction process that prevents decay. Many claims fail because they treat a dependency as if it were guaranteed. In real systems, dependencies cost something. They must be produced, maintained, or enforced. Design Biology highlights that cost.

Here is why this matters. If a claim says “the system self-organizes,” but the experiment requires tight temperature control, purified reagents, and repeated human intervention, then the system is not self-organizing in the way the words suggest. The system is being supported. That may still be valuable. It just changes what the claim can honestly say.

To make this evaluation sharp, use three questions.

First, what goes in? List every required input. Include energy, materials, and conditions.

Second, what comes out? State the output in measurable terms.

Third, what must be true for the system to continue producing that output? Those are dependencies. Please document them as requirements rather than as background.

Once you do this, you can compare explanations fairly. Two theories can be compared by asking which one requires fewer hidden dependencies, which one explains control more directly, and which one can operate under more realistic conditions. You are not arguing philosophy. You are tracking system requirements.

This lesson also helps you spot “outsourced functions.” Sometimes the real function is performed outside the system boundary. For example, selection can be imposed by the experimenter rather than emerging from the system. Cycles can be imposed by lab protocols rather than being produced by the environment. Information can be supplied by pre-designed sequences rather than being generated within the system. These are not accusations. They are boundary facts.

When you write your audits, this lesson becomes a checklist. Your audit should include a clear statement of inputs, outputs, and dependencies. If you cannot list them, you do not yet understand what the claim requires. If you can list them, you are ready for the next step.

In the next lesson, we will build on this understanding by mapping feedback and control loops. That is where you see whether the system can regulate itself or whether regulation is being assumed without a mechanism.

Lesson Summary

Systems operate by processing inputs to perform functions and produce outputs. Evaluating biological explanations effectively requires a clear identification and understanding of three key elements: inputs, outputs, and dependencies.

Inputs are essential substances or conditions needed for the system to function. In biology, these often include:

• Energy sources
• Raw materials
• Environmental factors (e.g., temperature, pH)
• Timing signals
• In laboratory contexts, also purified reagents, pre-built components, controlled cycles, and human-controlled condition selections

If removing any element causes the system to stop working, that element is an input or a dependency, regardless of whether it seems natural or artificial.

Outputs are the measurable results or products the system generates. These need to be clearly defined and quantifiable to allow independent verification. Examples include:

• Specific RNA strands of defined length and properties under certain conditions
• Behavioral responses
• System-level performance metrics

Vague statements such as “forms something like RNA” do not qualify as outputs.

Dependencies are conditions or supporting mechanisms the system needs to maintain function, even if not explicitly labeled as inputs. Examples include:

• Stable temperature
• Repeated wet-dry cycles
• Narrow pH range
• Isolation from interference
• Error-correction mechanisms

Such dependencies often carry costs in terms of maintenance and enforcement and must be documented as part of the system’s requirements.

Recognizing dependencies guards against overstated claims like “self-organization” when the system actually requires external support (e.g. tight temperature control, purified reagents, human intervention). This clarifies what claims realistically mean.

Three key questions for evaluation:

• What goes in? List all required inputs including energy, materials, and conditions.
• What comes out? Define the outputs in clear, measurable terms.
• What must be true for outputs to continue? Identify dependencies and frame them as explicit requirements.

This approach allows fair comparison of alternative theories by examining hidden dependencies, control explanations, and operational realism. It focuses on tracking system requirements rather than philosophical debate.

Additionally, be alert to “outsourced functions”, where key processes occur outside the system’s boundaries, such as:

• Selection imposed by experimenters rather than emerging internally
• Cycles enforced by laboratory protocols instead of natural environment
• Information supplied by designed sequences instead of system-generated

These are boundary realities, not accusations.

In practice, audits should always include a documented list of inputs, outputs, and dependencies. If these cannot be clearly stated, it indicates incomplete understanding of the claim.

The next lesson will build on this foundation by exploring feedback and control loops, revealing whether the system regulates itself or if regulation is assumed without mechanisms.