Imagine you're building a bridge.
During a design review, someone notices that a support beam is missing from the plans.
That sounds serious.
But before adding another beam, an engineer needs to answer a fundamental question:
Does the bridge actually require that beam?
Perhaps the beam is essential to carry the expected loads.
Perhaps the design already distributes those loads safely through other structural elements.
Or perhaps the available analysis is insufficient to determine whether the beam is necessary.
Those are three very different situations.
And recognizing the difference is important not only in engineering, but also in scientific research.
What Does It Mean When Something Is Missing?
When scientists develop a mathematical model, a computer simulation, or an experimental design, they begin with a collection of assumptions, relationships, and requirements.
Some of those elements are essential.
Others may be useful but optional.
Still others may be proposed because someone believes they should be present, even though their necessity has not been established.
This creates an important distinction.
Something can be absent from a model without being a missing requirement.
For example, a model designed to calculate the motion of a satellite might initially ignore atmospheric drag.
For a sufficiently high orbit and a suitably limited calculation, that approximation may be acceptable.
For a satellite operating in low Earth orbit over longer periods, atmospheric drag may become important enough that the model must account for it.
The physical phenomenon exists in both situations.
What changes is whether the model needs to represent it to meet its stated objectives and accuracy requirements.
The same reasoning applies to other scientific models.
Three Different Kinds of Missing Pieces
When we discover something that is not represented in a model, we should not immediately assume that the model is defective.
Instead, we can distinguish three possibilities.
1. A Required Piece Is Missing
Suppose a bridge design cannot safely carry its specified loads without an additional support.
Engineering analysis establishes that the support is necessary.
In that case, the missing support is a genuine design problem.
The design must be corrected, or the requirements must be reconsidered.
In scientific software, an equivalent problem occurs when a calculation requires a mathematical relationship that has not been defined or justified.
We cannot simply assume that relationship exists.
The missing requirement must be addressed before the dependent conclusion can be trusted.
2. The Piece Is Not Required
Now imagine that the bridge's existing structural elements already satisfy the specified requirements.
An additional support might be possible.
But it is not required to satisfy those requirements.
Adding it could increase cost, complexity, maintenance needs, or introduce additional design considerations.
In a mathematical or computational model, unnecessary additions can create similar problems.
Each new rule introduces relationships that must be defined, checked, and maintained.
It may also create new assumptions that were not present in the original model.
That does not mean additional complexity is always undesirable.
Sometimes greater complexity is necessary to represent important physical behavior.
But complexity should serve an established purpose.
3. We Do Not Yet Know Whether the Piece Is Required
The third possibility is equally important.
Perhaps the engineer has not yet established whether the existing bridge structure can carry the required loads.
In that situation, it would be premature to declare the additional support either necessary or unnecessary.
The correct answer is:
NOT YET DETERMINED
This is not a design failure by itself.
It identifies a question that still requires investigation.
Scientific research frequently encounters this situation.
And preserving uncertainty is often more useful than forcing an answer that the available evidence does not support.
Why Adding More Rules Is Not Always Better
It may seem that a model becomes more complete every time we add another rule.
But that is not necessarily true.
A scientific model should contain the relationships needed to represent the problem it is intended to investigate.
Adding an unsupported relationship can make the model appear more complete without making it more accurate.
Consider a computer simulation.
If the simulation produces an unexpected result, a researcher might be tempted to add another adjustment until the output looks more reasonable.
But unless that adjustment has a defensible physical or mathematical basis, the resulting agreement may be misleading.
The simulation might now produce the expected answer for the wrong reason.
A better approach is to determine what the model actually requires, what the existing equations establish, and which assumptions remain unsupported.
Sometimes that investigation leads to a new equation.
Sometimes it leads to a correction.
Sometimes it reveals that an additional relationship was never required.
All three outcomes can improve the research.
What Happened in Beyond the Light Barrier?
We recently encountered this distinction during the Beyond the Light Barrier project's AR-1.7 Architecture Stress Audit.
AR-1.7 is an investigation of the software architecture used to represent, verify, and eventually execute computational experiments within BTLB-SIM.
It is not an experiment demonstrating new physics.
Its purpose is to help establish whether the software can correctly represent and check the computational experiments we may want to perform.
During this audit, we established several narrowly defined relationships governing how certain evaluation and reconciliation records could be related to one another.
These relationships were separately reviewed, prospectively adopted, and subsequently applied within their explicitly limited scope.
But another question emerged.
Did the architecture also need a new rule describing how observations belonged to those reconciliation records?
At Checkpoint 86, we determined that the existing architecture did not provide sufficient authority to establish such a new observation-membership relationship.
That was a genuine gap in the proposed claim.
But it did not yet establish that the architecture needed the claim.
So the next checkpoint asked a more fundamental question:
Do the requirements we have already established actually depend on this new observation-membership rule?
At Checkpoint 87, the reviewed answer was no, within the specific reconciliation obligations being investigated.
The existing relationships already preserved the information and connections required for their intended purpose.
A new observation-membership domain was not necessary to satisfy those obligations.
So we did not add one.
What That Result Does Not Mean
There is an important qualification.
We did not prove that such a relationship could never exist.
We did not prove that it would never be useful in a different part of the architecture.
And we did not establish that every possible future version of BTLB-SIM could operate without it.
Our conclusion was narrower:
For the specific requirements currently under investigation, the additional relationship was not required.
That distinction matters.
A result that is valid under one set of assumptions does not automatically become a universal rule.
If a future requirement independently establishes the need for observation membership, that question can be reopened.
Until then, adding the rule would introduce complexity without an established need.
How Does This Apply to Wormholes and Advanced Propulsion?
The same reasoning applies to the more speculative questions that motivated Beyond the Light Barrier.
Consider a hypothetical traversable wormhole.
General relativity permits researchers to investigate mathematical spacetime geometries that resemble traversable wormholes.
But writing down a mathematical geometry is not the same as demonstrating that nature can create or sustain it.
Some proposed geometries require unusual stress-energy properties, and their physical realizability remains unresolved.
Suppose we are developing a theoretical model and discover that an additional assumption appears necessary.
Before adopting it, we should ask:
What result are we trying to establish?
Which equations or physical constraints apply?
Is the additional assumption actually required?
Can the existing model satisfy the stated conditions without it?
What evidence would distinguish the alternatives?
The same questions apply to hypothetical warp propulsion.
For example, a human-carrying spacecraft has requirements that an uncrewed robotic probe may not share.
Life support, human acceleration tolerance, and crew survivability are essential considerations for human transport.
But those particular requirements do not automatically apply to every possible uncrewed propulsion experiment.
Removing human-rating requirements does not demonstrate that faster-than-light propulsion is physically possible.
It simply prevents us from treating requirements for one mission as though they were requirements for every mission.
That distinction can help us investigate different possibilities without confusing their objectives.
What Happens When We Ask the Right Question?
After Checkpoint 87, we paused the unnecessary observation-membership investigation.
We then reassessed the broader architecture problems that were still preventing AR-1.7 from reaching readiness.
That reassessment led us toward something much more fundamental:
How should the architecture represent the successful evaluation of a simple literal constant in a basic assignment?
Even this apparently ordinary operation exposed a missing semantic relationship.
At Checkpoint 89, the audit identified the need to clarify the accepted authority for producing the constant's abstract result, including its value, result tag, and lineage.
That question remains OPEN.
The important point is that the research did not simply continue adding rules to the previous branch.
It returned to the requirements, identified a more relevant unresolved problem, and changed direction.
What Should We Remember?
Scientific progress does not always mean adding more equations, more assumptions, or more complexity.
Sometimes progress means identifying a missing relationship and establishing it.
Sometimes it means recognizing that the relationship is not required.
And sometimes it means preserving the question because the available information does not yet justify either conclusion.
These are not interchangeable results.
Each tells us something different about what we know and what we still need to investigate.
Continuing the Investigation
The investigation continued beyond the checkpoints discussed in this article.
In Research Explained #10 — Where Does a Model's Input Come From? , we examine a related question: when a mathematical model requires an input, how do we establish that an actual input satisfies those requirements?
Drawing on the later AR-1.7 Checkpoint 113 investigation, the article explains why specifying a requirement is not the same as demonstrating that the requirement has been satisfied.
Research Status
This article explains a research-method lesson illustrated by the BTLB-SIM AR-1.7 Architecture Stress Audit through Checkpoint 89.
The Checkpoint 87 finding concerns only the currently adopted, narrowly bounded reconciliation obligations.
It does not establish a universal prohibition on successor observation membership or eliminate possible future requirements.
AR-1.7 remains NOT READY.
The work discussed here introduces no new mathematical physics result, analytic calculation, physics simulation result, independently reproduced scientific result, or physical experiment.
It provides no experimental evidence for faster-than-light communication, warp propulsion, traversable wormholes, or anomalous gravitational effects.
The distinction between required, unnecessary, and unresolved relationships is a matter of research methodology and model integrity.
And it leaves us with a principle worth remembering:
Finding a gap tells us where to ask a question. Establishing a requirement tells us whether that gap needs to be filled.
No comments:
Post a Comment