Most scientific questions probably don't begin as perfectly formed equations.
Sometimes they begin much more simply:
“What if we looked at this?”
A researcher may have an idea about something they want to understand without yet knowing exactly what should be measured, which equations are needed, what controls are necessary, or how a computer simulation should be constructed.
That creates an interesting problem for scientific software.
Computers generally want precise instructions.
Research often begins with an imprecise question.
What if we treated the gap between those two things as part of the research process rather than merely an inconvenience?
The Question Before the Experiment
Suppose someone says:
“I want to know whether this changes how fast the signal travels.”
That sounds like a reasonable research question.
But it isn't yet an experiment.
What does “how fast” mean?
Are we measuring the arrival time of a pulse?
The motion of a peak?
A phase shift?
A change in a calculated propagation path?
Relative to what reference?
At what distance?
Under what conditions?
What uncertainty would matter?
What conventional explanation could produce a similar result?
A scientist may eventually need answers to all of those questions.
But requiring someone to know all of them before they are even allowed to begin exploring an idea creates another problem.
It assumes that experiment specification happens before scientific reasoning.
Often, the process works the other way around.
The questions become more precise through the reasoning.
We Already Work This Way
This has happened repeatedly within Beyond the Light Barrier.
An investigation may begin with an informal question:
“What if we tried this?”
Then the conversation begins.
What exactly are we trying to learn?
What quantity would represent it?
Are there several possible meanings?
Which assumptions are hidden inside the question?
What physics would be required?
What controls would distinguish the effect from something conventional?
What would we actually calculate or measure?
What result would support the idea?
What result would constrain or reject it?
Sometimes answering those questions changes the original experiment substantially.
Sometimes it reveals that we were asking the wrong question.
And sometimes it reveals that we don't yet have the tools necessary to answer it.
That process suggested an interesting possibility for the future of BTLB-SIM.
What If the Simulator Could Help Ask the Next Question?
BTLB-SIM is being developed as scientific simulation infrastructure for Beyond the Light Barrier.
Today, constructing a computational experiment ultimately requires sufficiently precise models, parameters, interfaces, observables, verification requirements, and software components.
But imagine a future researcher beginning somewhere much earlier.
They might simply say:
“I want to see whether X changes when Y increases.”
Instead of responding:
Invalid specification.
An interactive research system might respond:
“There are several measurable quantities that could represent what you mean by ‘changes.’ Let me explain the differences.”
The researcher chooses one.
The system might then say:
“To calculate that quantity, the experiment also needs an initial condition that hasn't been specified.”
Another answer.
Another question.
Eventually the system could say:
“Here is the experiment I believe we have jointly specified. Before generating an execution plan, please verify that this represents what you intended.”
That last step would be important.
The system should help the researcher make the question precise.
It should not quietly decide what the researcher meant.
From Conversation to a Scientific Specification
If this idea proved workable, the process might eventually look something like this:
Informal research question
↓
Interactive scientific clarification
↓
Canonical experiment specification
↓
BTLB-SIM capability resolution
↓
Supported → Execution plan → Computational experiment → Verification and evidence record
Missing capability → Development request → Review → Development and verification → Re-evaluate original specification
The first part is deliberately human.
The researcher can begin with curiosity.
The system helps expose the scientific requirements hidden inside that curiosity.
But at some point, conversation has to become specification.
A reproducible computational experiment cannot ultimately depend on somebody remembering what they meant during a conversation six months earlier.
The result of the interactive process would therefore need to become an explicit, reviewable experiment specification.
That specification might eventually contain things such as:
- the scientific question;
- physical models;
- assumptions;
- initial and boundary conditions;
- sources;
- propagation models;
- detectors;
- observables;
- controls;
- comparison criteria;
- uncertainty requirements;
- verification requirements; and
- provenance requirements.
The exact contents are not yet established.
Neither is the format.
It could eventually involve structured data, a formal description language, generated configuration, or something we haven't considered yet.
The important idea comes before the syntax:
Can we describe what scientific experiment we intend independently of the particular software implementation used to perform it?
Then BTLB-SIM Gets to Answer a Different Question
Once the intended experiment is sufficiently precise, BTLB-SIM could potentially compare the specification with what the simulator actually knows how to do.
Already supported
The required particle model exists. The required field model exists. The requested observable can be calculated. The necessary provenance information can be recorded.
Supported with limitations
Part of the requested model exists, but only under explicitly stated assumptions or approximations.
Development required
The scientific requirement is understood, but BTLB-SIM does not currently contain a component satisfying it.
Insufficiently specified
We still don't know enough about what the researcher intends to determine what should be calculated.
Those are very different outcomes.
And preserving those distinctions could be scientifically important.
“We Can't Run This Yet” Can Be a Good Result
Scientific software has a dangerous temptation.
When asked to do something it cannot quite do, it can be tempting to substitute something it can do.
Maybe the requested model isn't available, but a simpler one is.
Maybe the requested observable isn't implemented, but another related quantity is.
Maybe an assumption hasn't been specified, but the software has a convenient default.
That may produce a result.
It may also produce a result for an experiment nobody actually requested.
For Beyond the Light Barrier, that would be unacceptable.
A future capability-resolution system should be allowed to say:
Experiment architecture incomplete.
The requested observable requires a propagation capability that BTLB-SIM does
not currently implement under the specified conditions.
Existing components satisfy part of the requested experiment.
Additional development is required.
No simulation result has been produced.
That isn't necessarily a software failure.
It may be valuable information about the state of the research infrastructure.
It tells us what capability would have to exist before the proposed computational experiment could be performed faithfully.
Missing Capability Could Become Part of the Research Record
This changes the meaning of a missing software component.
Instead of discovering halfway through implementation that something doesn't exist, the missing capability could potentially be identified during experiment design.
That could produce a traceable chain:
Research question
↓
Required observable
↓
Required analysis
↓
Required detector
↓
Required propagation
↓
Required physical model
↓
Required source
Then the direction reverses when the experiment executes:
Source
↓
Model
↓
Propagation
↓
Detector
↓
Observable
↓
Analysis
↓
Result and evidence classification
↓
Supported claim boundary
That raises a powerful question:
Could BTLB-SIM eventually determine, before running anything, whether the proposed experiment architecture can actually support the claim the researcher wants to investigate?
Not whether the claim is true.
Not whether nature will agree.
Only whether the proposed computational experiment is logically capable of addressing the stated question.
Those are very different things.
A Missing Capability Could Become a Development Request
Identifying a missing capability does not necessarily have to be the end of the process.
If the experiment has been specified clearly enough for the system to identify a required capability that is not currently supported, that finding could potentially become a structured development request.
This would be different from an ordinary software feature request.
The request could preserve why the capability is scientifically needed.
For example, it might record:
- the experiment specification that exposed the gap;
- the scientific question being investigated;
- the observable or analysis requiring the capability;
- the missing model, propagation method, detector, or analysis capability;
- which existing capabilities already satisfy other parts of the experiment;
- whether any scientifically valid substitute exists;
- why a seemingly similar existing capability would not satisfy the request; and
- the reason the experiment cannot currently proceed as specified.
That could create a traceable relationship between scientific need and software development.
Research question → experiment requirement → missing capability → development request
Importantly, discovering a missing capability would not automatically authorize its implementation.
The development request would still need scientific and architectural review. It might be approved, deferred, rejected, or revised.
Those decisions should remain part of the research and development record rather than disappearing simply because a capability was not built.
If development were approved, the new capability would still have to satisfy the applicable BTLB-SIM architecture, software, numerical, verification, provenance, and scientific-integrity requirements before becoming available for research use.
And even then, the original experiment should not simply resume automatically.
The original canonical experiment specification should be evaluated again against the updated BTLB-SIM capability inventory.
The new capability may satisfy the original gap.
Or the next missing requirement may become visible.
Either outcome would tell us something useful.
Over time, this could create traceability in both directions:
Why does this module exist?
Because this capability was required.
Why was the capability required?
Because this experiment needed it.
Why did the experiment need it?
Because it was necessary to investigate this scientific question.
That could help BTLB-SIM grow in response to documented scientific requirements rather than simply accumulating features because they seem potentially useful.
The Scientist Shouldn't Have to Speak Python
There may ultimately be several distinct descriptive layers involved.
At the top is the researcher's scientific intent:
“Here is the physical system I want to investigate, what I want to know, and what I think might happen.”
Below that is an experiment specification:
“Here are the models, conditions, observables, controls, and verification requirements necessary to investigate that question.”
Below that is BTLB-SIM's scientific and software architecture:
“Here are the components and contracts capable of implementing that specification.”
And below that is the actual implementation and execution machinery.
Python and Rust may exist down there.
The researcher shouldn't necessarily need to speak those languages.
More importantly, the software shouldn't have to reverse-engineer the researcher's scientific intent from the Python code.
Separating those layers could make both sides more explicit.
It Could Teach While It Helps Design
There is another possibility I find particularly interesting.
The system shouldn't necessarily just say:
“Control C is required.”
It could explain why:
“Without this control, the effect you are trying to detect would be observationally difficult to distinguish from this conventional alternative.”
Or:
“You requested displacement as the observable. Under these conditions the predicted displacement is substantially below the assumed measurement resolution. Would you like to examine another observable, change the proposed apparatus, or preserve this as a feasibility constraint?”
That would make the interaction educational as well as computational.
The researcher would not simply receive a completed experiment design.
They could learn why the design has the structure it does.
And importantly, they could disagree.
The human researcher remains responsible for deciding what scientific question is actually being asked.
There May Be a Reproducibility Benefit Too
This idea also connects with another problem Beyond the Light Barrier has been thinking about: independent reproduction.
Giving another researcher our source code and asking them to run it again can establish useful repeatability and verification.
But it can also cause them to inherit our implementation choices.
A sufficiently complete scientific experiment specification could potentially provide something different.
Instead of saying:
“Here is our code. See if you get the same answer.”
we might eventually be able to say:
“Here is the scientific computation we intended to perform. Implement it independently and tell us what answer you obtain.”
The specification would describe the question without necessarily dictating the implementation.
That could create another useful separation between what was supposed to be calculated and how we chose to calculate it.
It would not automatically guarantee independent reproduction.
But it might help make genuine independence easier to define and preserve.
We Shouldn't Design the Language Yet
There is an obvious temptation at this point.
Start inventing syntax.
Give the idea a name.
Define keywords.
Design a parser.
Create architecture diagrams.
Start coding.
We're deliberately not doing that.
We don't yet know whether a special language is necessary.
We don't know exactly what information such a specification would need.
We don't know whether structured data, conversational interaction, existing scientific formats, generated configuration, or some combination would work best.
And we certainly haven't demonstrated that the idea is useful.
So for now, Beyond the Light Barrier is preserving this as a future BTLB-SIM architecture-path idea, not an approved architecture component or implementation requirement.
It should not alter the current AR-1.7 architecture stress audit.
The lower-level architecture needs to be understood on its own terms before we build a new layer on top of it.
How Could We Test the Idea?
Fortunately, we don't have to design an entire system to begin investigating whether the concept has merit.
We already have computational experiments whose intended behavior is reasonably well understood.
VAPE-1, the Virtual Accelerator Precursor Experiment, provides one possible test case.
Rather than modifying VAPE-1, we could ask a different question:
Can we describe the scientific intent of VAPE-1 completely without referring to its implementation?
Then we could deliberately make the description incomplete.
Remove an initial condition.
Remove an observable.
Make a phrase ambiguous.
Omit a verification requirement.
Ask for something BTLB-SIM doesn't support.
An experimental prototype of the interactive process could then be evaluated on whether it:
- recognizes missing information;
- identifies ambiguity;
- asks scientifically relevant clarification questions;
- distinguishes unsupported capability from incomplete specification;
- avoids inventing unstated assumptions;
- identifies applicable existing capabilities;
- explains why requested controls or verification steps matter;
- identifies missing capabilities precisely enough to support a reviewable development request where appropriate; and
- produces a final specification that accurately represents the researcher's confirmed intent.
Failure would be informative too.
Perhaps natural-language interaction proves too ambiguous.
Perhaps the required specification becomes so complicated that researchers would rather write code.
Perhaps important scientific assumptions cannot reliably be surfaced.
Perhaps the system asks so many questions that it becomes unusable.
Those would be legitimate results.
The point would be to investigate the idea, not assume that it works.
Curiosity Should Be Allowed to Come First
Beyond the Light Barrier began with questions, not finished experiment specifications.
Many of those questions turned out to need substantial refinement.
Some led to calculations.
Some led to simulations.
Some exposed missing capabilities.
Some produced negative results.
Some were retired.
And some simply led to better questions.
That suggests a broader principle worth exploring:
A research system should not require the scientist to know how to program the experiment before the scientist is allowed to ask the scientific question.
Perhaps future scientific software can meet the researcher earlier in that process.
Not by guessing what the researcher means.
Not by hiding assumptions.
Not by turning every idea into a simulation.
But by helping transform:
“I wonder what would happen if…”
into:
“Here is the experiment we actually mean.”
And sometimes, perhaps the scientifically correct answer will be:
“Now we know exactly what you want to test. We just aren't able to test it yet.”
And if the missing capability is understood clearly enough:
“Now we also know exactly what capability would have to be developed before we could.”
That could be progress too.
Research Status
This article describes a future BTLB-SIM architecture-path concept for interactive experiment design, capability resolution, and possible traceable development requests arising from scientifically specified missing capabilities.
It does not describe an implemented BTLB-SIM feature, approved architecture requirement, formal experiment-description language, or completed software design.
No syntax, interface, architecture identifier, development-request mechanism, or implementation plan has been established.
The concept is being preserved for possible investigation after the current AR-1.7 architecture work. Any future implementation would need to be developed and evaluated under the Beyond the Light Barrier Research Method and Software Development Standards.
This article reports no new physical experiment, simulation result, independently reproduced result, or evidence for faster-than-light communication or propulsion.
Sources & Further Reading
Beyond the Light Barrier Research Method, Version 1.2.
Defines the project's evidence categories, scientific-integrity requirements,
reproducibility standards, treatment of assumptions, and distinction between
computational and physical evidence.
Beyond the Light Barrier Software Development Standards, Version
1.1.
Defines requirements for scientific software contracts, testing, AI-assisted
development and review, provenance, reproducibility, and preservation of
scientific meaning through implementation.
Beyond the Light Barrier Research State, Version 1.11.
Records the current state of BTLB research and BTLB-SIM development. The
interactive experiment-design and capability-resolution concept described here
is a future architecture-path idea and should not be interpreted as an
implemented capability of the current simulator.
Beyond the Light Barrier Verification Roadmap, Version 1.1.
Defines the project's progression from internal verification toward
independent reproduction and provides context for the possible use of
implementation-independent scientific specifications.
