Lesson 1: System Boundaries and Functions

Systems thinking starts with a boundary. Without drawing the boundary, evaluating the system becomes impossible. This step leads to the analysis of a dynamic system. In biology, that mistake constantly happens. A claim looks strong because hidden inputs, lab conditions, or outside support quietly do the real work. Design Biology prevents that by forcing you to define what is inside the system and what is outside it.

A system boundary answers three questions. What components count as part of the system? What inputs are allowed to enter the system? What outputs must the system produce to count as working? When you can state those three items, you can test a claim with much less confusion.

Start with the claim you are evaluating. If the claim is about a cellular process, the boundary might be a cell, an organelle, or a specific molecular machine. If the claim is about a pathway, the boundary might be the pathway plus the supporting control network that makes it run. If the claim is about origin-of-life chemistry, the boundary must be stated with special care, because it is easy to include modern laboratory support without admitting it.

One of the best ways to set a boundary is to list what the system requires to function. For a living system, requirements often include energy sources, raw materials, stable conditions, and coordinated control. If your explanation depends on a stable temperature range, repeatable cycles, purified reagents, or a carefully tuned environment, those are not minor details. Those are part of the system requirements. If you do not list them, you will overestimate what the system can do on its own.

Once the boundary is set, define a function. In Design Biology, function is not a label. Function is a measurable capacity that produces an outcome under specified conditions. A function must include three parts. The first part of a function is what the system performs. Second, what conditions does it need? Third, what measurement shows it is working?

For example, saying “this sequence has a function” is not enough. What does it do? Does it regulate expression? Does it bind a target with specificity? Does it catalyze a reaction at a meaningful rate? Under what conditions does it do that? And what measurement would show that the function is present?

The function also has a minimum performance requirement. A system that works once under ideal conditions is not the same as a system that works reliably. Living systems require stability. They require repeatable performance and resistance to noise. Design Biology keeps that in view by asking whether the function can persist across time, across cycles, and across realistic variation.

Boundaries also help you detect “outsourcing.” Outsourcing happens when an explanation claims the system is self-organizing, but the control is actually supplied from outside. In laboratory settings, outside control can originate from human intervention, engineered reagents, programmed cycles, or selective reporting. Those are not insults. They are facts about the setup. The audit question is simple: does the system perform the claimed function without those supports? If not, then the claim is not what it appears to be.

Another key idea is the difference between a subsystem and a whole system. A subsystem can be impressive in its complexity, yet it may still fail to explain the entirety of life. A pathway can produce building blocks but still fail to produce a stable, self-maintaining network. Systems thinking helps you keep the levels separate. What is being explained, exactly? A component? A module? A fully operational system? Do not let a success at one level get smuggled into a claim about a higher level.

Here is the practical takeaway. Every time you evaluate a biological claim, write a short boundary statement. Then write a function statement. If you cannot write those statements clearly, the claim is not ready for serious testing. If you can write them, you have the foundation for the rest of the Design Biology method.

In the next lesson, we will expand this idea into inputs and outputs. That is where you see what a system consumes, what it produces, and what dependencies the explanation quietly assumes.