Research Journal Entry 15

As BTLB-SIM began moving from a general architecture toward actual module interfaces, another problem became apparent.

A modular simulator gives us tremendous flexibility.

Sources can be exchanged. Detectors can be changed. Different environments can be selected. Numerical methods can be replaced. New Wormhole Communication, Warp Drive, accelerator, and future research models can be added without rebuilding the entire platform.

But that flexibility creates its own scientific risk.

Just because two software modules can connect does not mean their physics is compatible.

That realization changed the way we began thinking about the application programming interfaces—or APIs—inside BTLB-SIM.

An API is normally thought of as a technical contract describing how one piece of software communicates with another.

For BTLB-SIM, that is not enough.

The interface also needs to help preserve the scientific meaning of whatever passes through it.

Software Compatibility Is Not Scientific Compatibility

Imagine that one module calculates a physical source and another calculates the response of a detector.

From a software perspective, connecting them might be straightforward.

But scientifically, many more questions have to be answered.

Are they using compatible units?

Are their coordinate systems and reference frames compatible?

Is the output of the source model actually the physical quantity expected by the detector model?

Are both models being used within the domains for which their equations are valid?

Do they assume the same environmental conditions?

Has an approximation made by one module invalidated an assumption made by another?

Is the numerical method appropriate for the problem being handed to it?

And if the calculation succeeds numerically, what does that success actually allow us to conclude?

These questions cannot safely be left to the fact that two pieces of software happen to exchange compatible data structures.

Software compatibility is not scientific compatibility.

Turning an API into a Scientific Contract

That led us to begin treating BTLB-SIM interfaces as more than software connections.

A scientific module should be able to communicate not only its numerical outputs, but also information necessary to interpret those outputs correctly.

Depending on the module and calculation, that may include:

• physical quantities and units,
• coordinate systems and reference frames,
• model assumptions,
• validity domains and boundary conditions,
• approximations,
• uncertainty information,
• numerical-method requirements,
• provenance—the traceable record of the scientific model and model version, assumptions, input data, parameters and configuration, implementation version or source-code commit, numerical method and relevant settings, software dependencies, and other information needed to determine how a result was produced,
• verification status,
• warnings and limitations, and
• failure or HOLD conditions.

The objective is not to force every scientific model into an identical form. Different physics requires different models.

Instead, the shared interface should preserve enough information for the platform—and ultimately the researcher—to understand what is being calculated and under what conditions the result remains meaningful.

A Module Must Be Allowed to Say No

One consequence of this approach is especially important.

A scientific module must be allowed to refuse to produce a result.

Scientific software should not assume that every requested calculation deserves a number.

A model may be asked to operate outside its validity domain.

Required input may be missing.

A numerical method may fail to converge.

A conservation or consistency check may fail.

Two modules may make incompatible assumptions.

A parameter combination may be mathematically defined but physically inappropriate for the model being used.

In those situations, returning a plausible-looking number can be worse than returning nothing.

The scientifically responsible answer may instead be:

This calculation cannot presently support a trustworthy conclusion.

Errors Need Scientific Meaning

This raised another architectural question:

Who decides that something has gone wrong?

In many cases, the individual scientific module is in the best position to recognize its own failure conditions.

A numerical solver can determine whether its specified convergence criteria were satisfied.

That does not by itself establish that the calculation converged to the correct mathematical or physical solution. Convergence criteria, numerical stability, resolution, limiting behavior, and comparison against appropriate analytic or independently verified benchmarks may all be required before a numerical result can be treated as scientifically trustworthy.

A physical model knows whether requested parameters lie outside its stated domain.

A detector model may know that required environmental or apparatus information is missing.

The platform, however, needs a consistent way to receive and preserve those reports.

That led to the design principle that modules should detect their own model-specific problems while reporting them through a standardized diagnostic interface.

Conceptually, the chain becomes:

module detects condition → standardized diagnostic report → execution framework records it → provenance preserves it → experiment determines whether execution may continue

This is more than ordinary software exception handling.

A useful scientific diagnostic should preserve enough context to determine what happened.

What failed?

Under what parameters?

Was the failure numerical, physical, environmental, or software-related?

Is partial output still meaningful?

Were assumptions violated?

Can another part of the calculation continue?

Should the result be marked with a warning, placed on HOLD, or rejected?

Those questions become part of the research record rather than disappearing inside a generic error message.

Preserving Failure Instead of Hiding It

This approach follows an important rule already established in the Beyond the Light Barrier Research Method:

Negative and failed results must be preserved.

The same principle applies to computation.

A failed convergence test is information.

An unstable numerical region is information.

A model-domain violation is information.

An incompatible assumption is information.

A parameter range in which the solver cannot produce a trustworthy result is information.

Those failures may constrain the research just as meaningfully as a successful calculation.

BTLB-SIM therefore should not quietly discard them merely because they make the output less tidy.

VAPE Will Put the Rules to Work

The Virtual Accelerator Precursor Experiment provides a useful first test of this architecture.

A future VAPE computational experiment may involve a chain such as:

accelerator source → stress-energy model → general-relativistic response → environment → detector transfer → conventional-background model → numerical solver → verification → result

The purpose of BTLB-SIM is not merely to execute that sequence.

Each handoff must remain scientifically meaningful.

For example, a detector result should remain traceable back through the detector model, environmental assumptions, predicted spacetime response, physical source, numerical method, and parameters that produced it.

If a verification check fails somewhere in that chain, the final result should not quietly emerge looking indistinguishable from one that passed.

That makes VAPE useful for more than studying accelerator-source concepts.

It also makes VAPE an early test of whether the BTLB-SIM architecture can preserve scientific meaning across a multi-stage computational experiment.

From Research Method to Executable Architecture

The broader Beyond the Light Barrier research program already uses a forward chain for developing testable ideas:

physical source → predicted spacetime perturbation → detector transfer → measurable observable → conventional-background controls → uncertainty → independent reproduction → physical experiment

Until now, that has primarily been a research-method principle.

BTLB-SIM creates the possibility of encoding portions of that discipline directly into the computational infrastructure.

The software cannot decide whether a scientific hypothesis is true.

It cannot replace independent reasoning.

It cannot turn a simulation into an experiment.

And it cannot guarantee that an equation or model supplied by a researcher is correct.

But it can make certain kinds of mistakes harder to hide.

It can preserve assumptions.

It can enforce interface requirements.

It can record provenance.

It can expose failed verification checks.

It can distinguish warnings from successful validation.

And it can preserve enough information for another researcher to understand how a result was produced.

A Successful Run Is Not a Scientific Verdict

This distinction is particularly important as BTLB-SIM becomes capable of running increasingly complicated models.

A successful software execution means that software executed successfully.

A converged numerical calculation means that the chosen numerical method converged under the conditions tested.

A verification test means that a specified check was passed.

None of those statements, by themselves, demonstrate that nature realizes the model.

The evidence classification must therefore remain attached to the result rather than being inferred from how sophisticated the computation appears.

A computational result remains a computational result until additional evidence justifies a different classification.

Where the Project Stands

BTLB-SIM remains under active development.

The current work is focused on defining modular interfaces and execution rules that preserve scientific assumptions, diagnostics, provenance, verification, and failure conditions across the platform.

VAPE is expected to become one of the first substantial computational experiments to exercise those interfaces across multiple scientific modules.

Wormhole Communication and Warp Drive research continue to provide additional requirements and challenges for the shared architecture.

No new physical experimental result is being reported in this entry.

No BTLB-SIM calculation described here constitutes evidence for a wormhole, warp drive, anomalous gravitational effect, or faster-than-light communication or propulsion.

This is a research-infrastructure milestone: an attempt to translate portions of the project's scientific method into the rules governing its computational tools.

More Than an API

We originally thought an API was simply how one software module would talk to another.

In BTLB-SIM, it is becoming something more.

It is a contract describing what one scientific model is permitted to claim to another.

A module should not merely say:

Here is my answer.

It should also be able to say:

Here is what I calculated.

Here are the assumptions under which I calculated it.

Here is where the model is valid.

Here is how uncertain the result is.

Here are the checks that passed.

Here are the checks that failed.

And here is what this result does—and does not—allow you to conclude.

If BTLB-SIM can enforce that discipline consistently, then the simulator will be doing something more valuable than producing numbers.

It will help preserve the chain of reasoning behind them.

Sources & Further Reading

Beyond the Light Barrier — Research Method v1.0.
Project methodology governing evidence classification, assumptions, uncertainty, falsification, reproducibility, negative and failed results, corrections, and scientific claims.

Beyond the Light Barrier — BTLB-SIM Software Development Standards v1.0.
Project standards governing development, verification, traceability, provenance, testing, and scientific-software integrity within BTLB-SIM.

Beyond the Light Barrier — BTLB-SIM Framework Implementation State v0.9-dev.
Current development-state record for the BTLB-SIM framework, including implemented capabilities, verification status, and remaining development work.

Research Status

BTLB-SIM: Active development. This entry documents a scientific-interface and research-infrastructure milestone rather than a new physical result.

Scientific API contracts: Under active development. Interfaces are being designed to preserve model identity, assumptions, validity domains, units, frames, provenance, uncertainty, diagnostics, verification state, and failure or HOLD conditions across computational workflows.

VAPE: Developing computational experiment intended to exercise these interfaces across multiple scientific modules.

Computational results: No new numerical or simulation result is being established by this entry.

Independent reproduction: No new Category 8 result is established by this entry.

Physical experiment: No new Category 9 result is established by this entry.

Evidence status: Nothing reported here constitutes physical evidence for a wormhole, warp drive, anomalous gravitational effect, faster-than-light communication, or faster-than-light propulsion.