AI-Assisted Research #2 — When AI Research Meets Source Control

When the research assistant becomes part of the research problem

Artificial intelligence is changing how research can be conducted. An AI assistant can help examine complicated mathematical relationships, analyze software architecture, identify inconsistencies, prepare documentation, and suggest new questions worth investigating.

At Beyond the Light Barrier, we have been exploring how these capabilities can support an independent research program investigating advanced communication, propulsion, and spacetime concepts.

But our experience has revealed an important challenge.

How do we know that the research we are continuing is actually the research we previously established?

That question may sound like a software-development problem. In practice, it has become an important part of our scientific research method.

AI assistance is not scientific authority

An AI assistant can produce an explanation that sounds convincing while overlooking a critical assumption.

It can recommend a change without recognizing that the change conflicts with an earlier decision.

It can mistake a proposed mathematical relationship for one that has already been accepted.

It can also confuse a successful software operation with evidence that the underlying scientific model is correct.

None of these possibilities means AI assistance is inherently unsuitable for research.

They mean that assistance and authority must remain separate.

Within Beyond the Light Barrier, we distinguish among recommendations, proposed research decisions, accepted architectural relationships, computational results, and experimentally established findings.

An AI-generated recommendation does not become an accepted research result simply because it is persuasive.

Nor does an accepted software-design decision establish that a physical phenomenon exists.

Our research method requires us to preserve these distinctions, including when doing so slows our progress.

Why source control became a scientific concern

Beyond the Light Barrier is developing a simulation framework intended to support investigations of physical and mathematical models.

That framework includes software architecture, mathematical definitions, model specifications, test cases, and records of previous investigations.

As the project developed, maintaining continuity became increasingly important.

Suppose an architectural rule is accepted during one investigation. Several checkpoints later, another investigation depends on it.

Before proceeding, we need to know which version of the rule was accepted, what assumptions accompanied it, and whether subsequent work changed its meaning.

Simply remembering that the rule was discussed is insufficient.

We need evidence of what was actually preserved.

This is where source control becomes more than a convenience.

Git, the version-control system used in our software research, allows us to identify particular versions of files and maintain a history of changes.

A commit identifies a recorded repository state. An annotated tag can identify a particular research checkpoint.

These mechanisms help us establish which documents and software artifacts belong to a given research state.

However, source control alone does not guarantee that a research conclusion is correct.

It helps preserve what was recorded.

The scientific justification for that record remains a separate question.

When recovery becomes part of the evidence

During our AR-1.7 architecture investigation, we encountered situations that forced us to examine how research checkpoints could be preserved and recovered.

One historical checkpoint, CP107, remained unavailable in its original form.

A later investigation, CP107-R1, performed a distinct reconstruction or re-performance of the relevant work.

But the later work did not retroactively recover the original checkpoint.

We preserved that distinction rather than rewriting the historical record.

This is important because a reconstructed result and an original preserved result are not the same kind of evidence.

Even when they appear consistent, their provenance differs.

Other recovery investigations revealed more subtle problems.

In one case, an archive's size and cryptographic checksum matched the expected values.

Yet the initial restoration attempt failed verification because the extraction method did not preserve recorded Unix permission metadata.

The archive itself had not been shown to be defective.

The restoration procedure was the problem.

Instead of modifying the failed extraction to make the verification pass, we preserved the failure and performed a fresh restoration using an appropriate permission-preserving method.

This taught us an important lesson:

A valid backup does not automatically establish a valid recovery.

Recovery must be demonstrated through a process that preserves the evidence being recovered.

Why a successful checkpoint needs several kinds of verification

Our later checkpoint procedures became more rigorous.

We began distinguishing several different questions.

First: Was the intended research state recorded?

This involves identifying the exact repository state, checkpoint documents, and associated research records.

Second: Was that state published correctly?

A recorded local checkpoint is not necessarily identical to the version available in the authoritative remote repository.

We therefore distinguish the human-authorized publication operation from subsequent read-only verification.

Third: Was the complete state preserved?

Preserving the visible research documents is not enough when recovery also depends on repository history, metadata, file permissions, and earlier evidence.

Fourth: Can the preserved state actually be restored?

We require a fresh extraction into a separate location, followed by verification before ordinary inspection or modification of the recovered repository.

Fifth: Does the restored state match the intended state?

Independent recovery-integrity checks examine repository identity, recorded history, preservation inventories, and the relationship to previous checkpoints. These checks verify the preserved artifacts and recovery process, not the scientific conclusions contained within those artifacts.

These checks help establish the integrity of the preserved research record.

They do not establish that the scientific interpretation contained in that record is correct.

Two different meanings of success

Our recent checkpoints provide a useful example.

On October 14, 2026, Checkpoint 118 completed a bounded review of an existing architectural proposal.

The investigation found that the proposal contained relevant relationships but did not provide a complete, accepted justification for the particular operation being investigated.

The proposal remained unadopted.

Nevertheless, CP118 was successfully preserved, published, restored, and independently checked for recovery integrity.

The following checkpoint, CP119, investigated a narrower question concerning the relationship between two architectural entry requirements.

It did not establish the governing correspondence between them.

That unresolved conclusion was also durably preserved.

These outcomes illustrate two different meanings of success.

Operational success means that the intended research record was preserved and recoverable.

Scientific or mathematical success requires adequate justification for the conclusions being claimed.

A checkpoint can succeed operationally while documenting an unresolved scientific or architectural question.

In fact, preserving that unresolved result accurately is part of responsible research.

Figure 1 — From AI Assistance to Verifiable Research. AI can assist throughout the research process, but preserving a research record and validating its scientific conclusions are distinct responsibilities. A checkpoint may be successfully preserved and recovered while its scientific or architectural questions remain unresolved. Even well-supported scientific conclusions remain subject to further examination, testing, and revision.

Illustration: Beyond the Light Barrier, generated with OpenAI's image-generation technology, October 2026. Conceptual infographic; not a simulation, experimental result, or independently reproduced scientific finding.

Can AI independently check AI?

Another question emerged as our review procedures became more demanding.

If an AI assistant performs an investigation and then reviews its own work, how much confidence should that review provide?

Such reviews can be useful.

The assistant can examine assumptions, search for contradictions, challenge interpretations, and compare conclusions against retained evidence.

It can also construct counterexamples and identify unsupported reasoning.

But these activities do not automatically constitute independent reproduction.

The same assistant may carry forward the same misunderstanding into its review.

A second explanation of the same result is not necessarily an independent verification.

We therefore distinguish among internal review, independent checking of preserved artifacts, independent reproduction of calculations, and experimental validation.

Each can provide useful evidence, but each answers a different question.

In particular, successfully restoring a repository does not reproduce the scientific investigation recorded within it.

Human authorization remains essential

The growing capabilities of AI assistants create another important issue: authority.

An assistant may be capable of editing files, creating commits, executing tests, or interacting with remote repositories.

But capability does not automatically establish permission.

In our research workflow, certain operations require explicit authorization from the project owner.

Publishing an authoritative checkpoint is one example.

The assistant may prepare the work and help verify the resulting publication, while the authorized publication action remains under human control.

This separation reduces the risk of an automated process silently changing the authoritative research record.

It also helps us distinguish a proposed change from an accepted decision.

Human authorization is not, by itself, proof that a scientific decision is correct.

It establishes responsibility for the decision.

The decision must still withstand appropriate scientific and technical scrutiny.

Why we preserve failures

One of the most important principles in the Beyond the Light Barrier Research Method is that negative results must not disappear.

This applies to scientific investigations, software development, and research operations.

A failed restoration attempt may reveal a weakness in the recovery procedure.

A failed verification check may reveal a defect in the checking tool rather than the artifact being checked.

An architectural investigation may find that the available evidence does not justify an expected relationship.

These are different outcomes.

They should not be combined into a single category of failure.

Nor should they be erased simply because a later attempt succeeds.

Preserving them helps future investigators understand which problems were encountered, how they were classified, and what later work actually resolved.

This becomes especially important when research may continue for years or eventually involve other researchers.

Research in the middle of ordinary life

There is another aspect of AI-assisted research that is easy to overlook.

Research does not always take place in a laboratory, university, or dedicated research office.

Sometimes it takes place in the middle of ordinary family life.

On the evening before this article was written, our family was welcoming a new grandchild.

While helping care for his older siblings, I was also participating in an ongoing investigation involving software architecture, mathematical reasoning, and research preservation.

Between family responsibilities and updates about the approaching birth, I could continue examining questions with an AI research assistant.

I was not sitting in a research laboratory surrounded by a team of scientists.

I was a grandfather helping his family during an important moment in our lives.

Yet the research could continue.

That experience illustrates one of the possibilities AI assistance offers independent researchers.

It can make sophisticated investigations more accessible to people whose lives include families, careers, responsibilities, and other commitments.

But accessibility must not be confused with scientific reliability.

The fact that an AI assistant can help continue an investigation does not mean its conclusions are automatically correct.

The same requirements for evidence, verification, traceability, and honest reporting still apply.

Perhaps that is one of the most encouraging possibilities:

AI may help more people participate meaningfully in scientific exploration, without requiring them to abandon the other important parts of life.

Research that can outlive its original investigators

Beyond the Light Barrier is a long-term independent research effort.

We do not know whether its investigations will identify a viable approach to advanced communication or propulsion.

Some hypotheses may fail.

Some mathematical possibilities may prove physically unrealistic.

Some engineering concepts may encounter constraints that cannot be overcome.

Those outcomes are legitimate results of a scientific investigation.

But for future researchers to evaluate them, the reasoning and evidence must remain accessible and understandable.

A collection of conclusions without their assumptions and provenance is not enough.

Neither is a repository that cannot be reliably recovered.

Our goal is to preserve not only what we concluded, but also how we reached those conclusions, what remains uncertain, and what evidence would change them.

What we have learned

AI assistance has made it possible for our independent research program to investigate questions that would otherwise require substantially more time and effort.

It has also required us to think more carefully about the relationship between automation, authority, evidence, and scientific responsibility.

We are still developing these safeguards.

Our procedures are not perfect, and we do not claim that they eliminate the possibility of error.

But the experience has reinforced several principles.

• AI assistance does not replace scientific justification.
• Source control preserves recorded states, not scientific truth.
• A backup is not verified until its recovery has been tested.
• Independent artifact verification is not the same as independent scientific reproduction.
• Human authorization and scientific validation serve different purposes.
• Failed attempts and unresolved questions must remain part of the research record.

Perhaps the most important lesson is that research integrity cannot depend on the confidence of the assistant conducting the work.

It must depend on evidence, traceability, reproducibility, and a willingness to preserve results that do not support our expectations.

The purpose of AI-assisted research is not to make the assistant appear correct.

It is to help produce research that other investigators can examine, challenge, and, where possible, reproduce.

Sources & Further Reading

This article draws on retained Beyond the Light Barrier research and software-development records. The referenced checkpoint records are private project artifacts; their identification does not imply public access.

Checkpoint delivery receipts document reported preservation and recovery verification. Their existence does not constitute independent reproduction of the underlying scientific or architectural conclusions.

• Beyond the Light Barrier Research Method, version 1.2.
• Beyond the Light Barrier Software Development Standards, version 1.1.
• AR-1.7 historical CP107 recovery limitation and distinct CP107-R1 re-performance records.
• AR-1.7 Checkpoint 118 — V2 source-owner NORMAL-entry bounded applicability and integration review.
  Semantic commit: c2ef481c26ba386e8bcf1877d3737975a5a3626a
  Annotated tag: ar17-cp118
• AR-1.7 Checkpoint 119 — C01 eligible-parent and V2 R1 entry governing correspondence.
  Semantic commit: ff93a05d7f44d45804cf6cb1b50abf271e6588af
  Annotated tag: ar17-cp119

Related Research Explained: Research Explained #11 — When a Mathematical Rule Is Complete but Its Inputs Are Not

BTLB Perspective — What If “I Don't Know How to Specify the Experiment” Were a Valid Starting Point?

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.

Research Explained #5 - When Is a Computer Result Really Independent?

Suppose we run a scientific calculation on a computer and get an interesting result.

Then we run it again.

Same answer.

We run it on another computer.

Same answer again.

We rewrite part of the calculation using a different numerical method. Still the same answer.

At some point it is tempting to say:

“We reproduced the result.”

But in science, that phrase can mean something much stronger than simply getting the same answer twice.

This distinction has become increasingly important in the Beyond the Light Barrier project as we have developed simulations, verification procedures, cross-platform testing, and packages intended eventually for outside reproduction.

The central question is surprisingly simple:

How independent does another calculation need to be before it can genuinely increase our confidence in the result?

---

Running It Again Is Important — But It Is Repeatability

The simplest check is to run the same program again with the same inputs.

If it produces the same result, that is useful.

It tells us something about whether the calculation is repeatable under those conditions. It can also expose problems involving randomness, uninitialized state, unstable numerical behavior, or other execution issues.

But it does not provide much protection against a mistake already built into the program.

Imagine that a programmer accidentally enters:

2 + 2 = 5

Running that same incorrect calculation a thousand times will still produce the same incorrect answer.

Repeatability asks:

“Can we get the same result again?”

That is an important question.

It just isn't the only one.

---

What If We Run It on Another Computer?

Beyond the Light Barrier has been deliberately developing the ability to run research software in substantially different computing environments.

Our current environments include:

• Apple Silicon ARM64 running macOS;
• physical x86-64 hardware running Windows; and
• an IBM s390x big-endian Linux environment running through emulation.

Those differences can be extremely useful.

Software sometimes contains assumptions that remain invisible when it is used on only one platform. File paths, text encoding, line endings, processor architecture, byte order, filesystem behavior, dependencies, and numerical implementation details can all expose problems.

If a calculation survives those differences, our confidence in the software implementation may increase.

But there is an important limitation.

If every computer is still executing essentially the same algorithm derived from the same assumptions, they can all reproduce the same conceptual mistake.

Cross-platform verification therefore answers another question:

“Does the implementation behave correctly across the environments we claim to support?”

That is valuable verification.

It is not automatically independent scientific reproduction.

---

What If We Calculate It a Different Way?

Now the test becomes stronger.

Suppose one calculation uses one numerical method and another implementation uses a substantially different method.

If both methods converge on the same value, we have reduced the chance that the result exists only because of a particular algorithm.

We have used this kind of approach within Beyond the Light Barrier.

For example, some of our computational work has been checked using numerically distinct methods rather than relying on a single implementation.

That is stronger than merely pressing “run” twice.

We call this kind of work internal cross-validation.

But the word internal matters.

The implementations may still share:

• the same equations;
• the same interpretation of those equations;
• the same assumptions;
• the same specification;
• the same researcher;
• the same AI-assisted research process; or
• the same expected answer.

Agreement between the implementations is useful evidence that we may have implemented the mathematics correctly.

It still does not necessarily tell us whether both implementations inherited the same mistake from farther upstream.

---

What About Asking Another AI?

This question is especially relevant to Beyond the Light Barrier because artificial intelligence is used extensively as a research tool within the project.

We can ask another AI model, another reasoning process, another agent, or even another conversation to review a calculation.

That can be extremely useful.

A separate review may notice an assumption, algebraic mistake, software defect, missing boundary condition, or logical problem that the original analysis missed.

In fact, adversarial review is something we deliberately use.

But changing the AI does not automatically make the scientific work independent.

Two AI systems may receive the same specification, rely on similar assumptions, use similar training-derived mathematical knowledge, or be shown the same expected result.

Agreement between them can strengthen internal confidence.

Disagreement can be even more useful because it tells us where additional investigation is needed.

But neither agreement nor disagreement between AI systems determines which answer is physically correct.

The mathematics, evidence, assumptions, and eventually nature still have to decide.

---

So What Counts as Independent Reproduction?

For Beyond the Light Barrier, we deliberately set a stronger standard.

An independent reproducer should be able to begin from the equations, assumptions, parameters, and specification rather than simply receiving our source code and running it.

Where practical, the reproducer should also introduce meaningful independence by changing one or more aspects of the calculation, such as:

• the numerical method;
• the programming language;
• the mathematical reduction;
• the numerical library;
• the discretization;
• the implementation; or
• the researcher performing the work.

The purpose is not to make reproduction unnecessarily difficult.

It is to create opportunities for hidden assumptions and implementation mistakes to reveal themselves.

If two calculations share everything except the person pressing the button, they may not be as independent as they appear.

---

Why Blinding Can Matter

There is another subtle problem.

Suppose we tell an independent researcher:

“The answer should be 2.027901181.”

Now imagine their calculation produces 2.01.

They inspect their code, change something, and obtain 2.025.

Closer.

They make another adjustment and obtain 2.0279.

Eventually their calculation agrees beautifully with ours.

But what happened?

Perhaps they genuinely found several errors.

Or perhaps knowledge of the expected answer influenced decisions about algorithms, tolerances, assumptions, or corrections.

This is one reason a blind comparison can be valuable.

The independent reproducer can perform the calculation and commit the result — including numerical uncertainty and relevant verification checks — before seeing the project's reference answer.

Only then are the results compared.

Agreement becomes more informative because the reproducer was not steering toward a known target.

And disagreement is preserved rather than quietly tuned away.

---

What If the Independent Result Disagrees?

This may be the most important part.

A disagreement is not a failed reproduction exercise.

It is a scientific result that needs investigation.

Perhaps our calculation is wrong.

Perhaps theirs is wrong.

Perhaps the specification is ambiguous.

Perhaps two mathematically reasonable interpretations produce different answers.

Perhaps the result is sensitive to a numerical approximation that nobody previously recognized.

Whatever the cause, changing parameters after the fact merely to force agreement would destroy much of the value of independent reproduction.

The disagreement should instead be preserved and investigated.

For Beyond the Light Barrier, this is especially important because the purpose of reproduction is not to confirm what we hope is true.

It is to discover whether the result survives scrutiny outside the process that originally produced it.

---

Different Tests Answer Different Questions

It helps to think of these activities as answering different questions rather than simply forming a ladder where every step means “more correct.”

Repeatability:
Can the same computation produce the result again?

Cross-platform verification:
Does the implementation behave correctly across different supported computing environments?

Internal cross-validation:
Do different methods or implementations within the project reach compatible results?

Adversarial review:
Can another reviewer, AI system, or analysis process find weaknesses that the original process missed?

Independent reproduction:
Can a meaningfully independent implementation reproduce the result from the scientific specification?

Physical experiment:
Does nature actually behave in the way the model predicts?

Those questions are related.

But they are not interchangeable.

Figure 1. Same Result — Different Levels of Confidence. Repeatability, cross-platform verification, internal cross-validation, adversarial review, independent reproduction, and physical experiment answer different scientific questions. Agreement at one stage can strengthen confidence, but does not automatically establish the evidentiary status of another.

Created for the Beyond the Light Barrier research project with OpenAI image-generation assistance, September 2026.

---

Where Beyond the Light Barrier Currently Stands

This distinction has a practical consequence for how we classify our own work.

The Beyond the Light Barrier Research Method uses nine evidence and research categories. For computational work, three of them are particularly relevant here:

• Category 6 — analytic estimates or calculations;
• Category 7 — numerical or simulation results; and
• Category 8 — independently reproduced results.

Some BTLB calculations have undergone substantial internal verification, multiple numerical approaches, software testing, and cross-platform verification. Those activities strengthen the work, but none by itself satisfies the project's requirements for Category 8 independent reproduction.

But as of this writing:

Category 8 independent scientific reproduction: NONE.

That is not an embarrassing blank space in the research record.

It is an accurate description of where the evidence currently stands.

Calling internal verification “independent reproduction” would make the project sound more advanced than it actually is.

We would rather preserve the distinction.

---

And Independent Reproduction Still Isn't Experiment

There is one final boundary that matters even more.

Suppose an outside researcher independently reproduces one of our computational results perfectly.

That would be significant.

It could show that the result does not depend on our particular implementation or internal research process.

But it still would not demonstrate that the modeled phenomenon exists in nature.

A mathematical model can be calculated correctly by ten independent researchers and still describe a physical possibility that nature does not actually realize.

That is why Beyond the Light Barrier separates independent computational reproduction from physical experimental evidence.

Eventually, where scientifically justified, predictions must confront calibrated physical measurements, conventional explanations, controls, uncertainty, and experiment.

The computer can tell us what the model predicts.

Independent reproduction can tell us whether someone else can obtain that prediction without simply inheriting our implementation.

Nature still gets the final answer.

---

Why We Want Someone Else to Check Our Work

It would certainly be encouraging if an independent researcher reproduced one of our results.

But agreement is not the only valuable outcome.

We don't want someone else to reproduce our answer merely because agreement would make us feel better about it.

We want them to independently ask the same mathematical question.

If they get the same answer, our confidence increases.

If they don't, that may be even more valuable.

Because somewhere inside that disagreement may be an assumption, approximation, ambiguity, or mistake that neither side would have discovered alone.

And finding it is exactly what scientific verification is supposed to do.

---

Research Status

This article explains the verification and reproduction framework used by the Beyond the Light Barrier project. It does not report a new physical experiment, independently reproduced scientific result, or evidence for faster-than-light communication or propulsion.

BTLB currently has internally verified analytic and computational results, including Category 7 numerical work, but no project result currently qualifies as Category 8 independent scientific reproduction or Category 9 physical experimental evidence.

Cross-platform verification, alternate internal implementations, software testing, and AI-assisted adversarial review may strengthen confidence or reveal defects, but they do not by themselves change the evidence category of a scientific result.

---

Sources & Further Reading

Beyond the Light Barrier Research Method, Version 1.2.
Defines the project's evidence categories, reproducibility requirements, simulation standards, claim-strength rules, and distinction between computational and physical evidence.

Beyond the Light Barrier Verification Roadmap, Version 1.1.
Defines the project's transition from internal verification toward independent reproduction, including independence-preserving comparison, convergence requirements, and preservation of disagreement.

Beyond the Light Barrier Software Development Standards, Version 1.1.
Defines the software-verification, cross-platform, AI-assisted review, reproducibility, provenance, and scientific-integrity requirements used in BTLB research software.

Beyond the Light Barrier Research State, Version 1.11.
Records the current project evidence state, including the distinction between internally verified Category 7 work and the absence, as of this version, of Category 8 independent scientific reproduction or Category 9 physical experimental evidence.

AI-Assisted Research #1 — An Unexpected Experiment Within the Experiment

When I began Beyond the Light Barrier, I wasn't trying to conduct an experiment in artificial intelligence.

I was curious.

I wanted to explore questions about communication, propulsion, spacetime, wormholes, and the possibility—however remote—that there might be things worth investigating beyond the limits of technologies we currently know how to build.

There was an obvious problem.

I am a retired computer engineer and programmer, not a professional physicist or mathematician. Many of the questions that interested me quickly led into general relativity, quantum field theory, numerical methods, particle physics, experimental design, and mathematics well beyond my formal training.

Artificial intelligence changed what I could practically explore.

It could help me find scientific papers, understand unfamiliar mathematics, work through calculations, develop and examine simulation software, question assumptions, organize results, and document what we were learning.

Perhaps most importantly, it allowed one question to lead naturally to the next.

But something unexpected happened along the way.

The use of AI itself became part of the experiment.

From Asking Questions to Doing Research

At first, AI assistance can feel a little like having a very capable reference book that you can talk to.

Ask a question. Get an explanation. Ask another question.

But that isn't quite what happened with Beyond the Light Barrier.

A question would lead us into the scientific literature. A paper would introduce an equation. The equation would raise a question about assumptions or boundary conditions. That might require a calculation. The calculation might suggest something worth simulating. A simulation result might reveal another question—or expose a problem with the original idea.

The process gradually became:

curiosity → question → evidence → analysis → result → verification → new question

And sometimes:

curiosity → question → calculation → exciting result → verification → mistake

That second path turned out to be important too.

The purpose of research cannot simply be to produce the answer we hoped to find.

AI Can Help—and AI Can Be Wrong

One of the lessons of this project has been that useful AI assistance and fallible AI assistance are not contradictory ideas.

AI has been extraordinarily useful to me.

It has also made mistakes.

That forced us to become increasingly careful about what different kinds of results actually mean.

A mathematical possibility is not evidence that nature realizes it. A simulation is not a physical experiment. Repeating a calculation using the same assumptions is not necessarily independent reproduction. A successful software test does not establish that the physics represented by the software is correct.

Those distinctions eventually became formal parts of the Beyond the Light Barrier Research Method.

The project now explicitly separates accepted physical theory, published speculative theory, project hypotheses, engineering concepts, analytic calculations, numerical and simulation results, independently reproduced results, and physical experimental results.

That may sound overly formal for one retired computer engineer exploring physics with AI.

I have discovered that it isn't.

The faster AI allows us to move, the more important it becomes to know exactly what we actually know.

Learning to Value Failure

Another lesson developed gradually.

A failed result can be a successful investigation.

Our verification framework now explicitly requires negative and null results to be preserved. A result that eliminates an approach, exposes an unrealistic requirement, or demonstrates that a predicted observable would be buried beneath conventional backgrounds still tells us something useful.

That philosophy has also influenced the software supporting the research.

For example, VAPE-1—the first accelerator-focused application of the BTLB simulation framework—is explicitly classified as a computational precursor laboratory, not a physical accelerator experiment. Its verification work preserved identified issues even when the applicable readiness gate passed, and its numerical results were not promoted into experimental evidence.

That distinction matters.

The question isn't merely:

Did it work?

It is:

What did we learn?

What assumptions survived?

What failed?

What should we change?

And what question should we ask next?

Eventually, AI Started Reviewing AI

As the project became more sophisticated, AI assistance expanded beyond explanation and calculation.

It became involved in software development, architecture review, verification, and auditing.

That created another interesting development: AI-generated or AI-assisted work could itself be subjected to separate AI review.

Our ongoing AR-1.7 architecture stress audit provides one example.

The audit has included separate review of architecture work, reconciliation of source artifacts, preservation of earlier findings, cross-platform verification, and review gates that must be satisfied before corrective changes can advance.

And importantly, successful tests did not automatically mean the audit passed.

AR-1.7 remained explicitly NOT READY while unresolved work remained. A failed initial Windows verification attempt was preserved in the record rather than disappearing after the corrected attempt succeeded. Proposed corrections remained proposed corrections rather than silently becoming production changes.

This is an important distinction for this series.

Having another AI review AI-assisted work can be useful.

It does not, by itself, constitute independent scientific reproduction.

AI agreement is not scientific truth.

Greater Capability Created Another Question

As AI systems became capable of performing longer and more autonomous tasks, another issue emerged.

What happens when an AI system is technically capable of doing something that the researcher never intended to authorize?

Some of the questions that led us to consider this were prompted by reading reports about unexpected behavior observed elsewhere in increasingly capable AI agents.

That was humbling.

We had not necessarily anticipated every possible failure mode ourselves.

So we learned from what others had encountered.

The result eventually became an explicit principle in Research Method v1.2:

“Capability does not imply permission. Increased technical capability or autonomy does not expand research authorization.”

The method now distinguishes technical accessibility from authorization. Unexpectedly broad or uncertain access is supposed to stop the affected action for human review rather than become an opportunity to explore simply because the system happens to be capable of doing so.

And delegating work to an AI does not transfer responsibility for defining the research objective or its boundaries away from the human researcher.

“It can” is not the same statement as “it should.”

That lesson probably extends considerably beyond warp-drive research.

Why Document This?

I did not begin Beyond the Light Barrier intending to study human-AI scientific collaboration.

That emerged naturally from doing the research.

So I have decided that it is worth documenting.

This new AI-Assisted Research series is not intended to demonstrate that AI can independently conduct scientific research. It is not an argument that AI is always correct, safe, or beneficial. And it certainly isn't an attempt to present only the occasions when AI assistance worked well.

It is something much narrower.

It is a record of one independent researcher's experience using AI assistance to pursue difficult scientific questions while attempting to preserve human direction, verification, scientific accountability, and an honest history of both successes and failures.

When AI makes a significant mistake, that belongs here.

When independent review catches something, that belongs here.

When AI enables an investigation I otherwise could not practically have pursued, that belongs here too.

And when increasing capability causes us to discover that our research methods or safeguards need to change, that may be especially important to document.

Perhaps over time these posts will become a useful case study.

Perhaps they will simply become an interesting record of what it was like to conduct independent research during a period when artificial intelligence was rapidly changing what an individual researcher could do.

Either outcome seems worth preserving.

Curiosity Remains the Starting Point

There is something that AI has not supplied to this project.

The curiosity.

We need the data. We need the analysis. We need to ask questions. We need to be able to follow one question until it reveals the next one.

And above all, we need curiosity—the willingness to explore what might be possible while remaining equally willing to discover that we were wrong.

AI has not supplied that curiosity for me.

It has helped me follow it much farther.

And that may ultimately be one of the most important things AI has contributed to Beyond the Light Barrier.

Research Journal Entry 6

\

Designing Our Ideas to Fail

There is a natural temptation when working on an idea you want to succeed.

You begin asking:

How can I make this work?

For Beyond the Light Barrier, that is probably the wrong question.

We are investigating possibilities involving faster-than-light communication, unconventional propulsion, spacetime geometry, wormholes, and other ideas at the boundaries of established physics.

These subjects already encourage imagination.

What they need from us is skepticism.

So the research process is adopting a deliberately uncomfortable rule:

Once we develop a promising model, we should try to make it fail.

Why Try to Break Our Own Models?

Suppose we develop a mathematical model that appears to produce an interesting result.

It would be easy to continue refining the model until we obtain the result we hoped to see.

But that creates a serious problem.

Are we learning something about nature?

Or are we simply learning how to make our model produce the answer we wanted?

The distinction is fundamental.

A scientific hypothesis becomes stronger when it exposes itself to the possibility of being wrong. For an experimentally testable hypothesis, that means identifying observations that could contradict it. For an earlier theoretical model, it means identifying mathematical, physical, or empirical conditions under which the model would fail, while clearly acknowledging when direct experimental testing is not yet possible.

That means asking questions that might destroy our favorite ideas.

What assumption is carrying the result?

What happens if that assumption changes?

Does the model satisfy the conservation laws and consistency conditions appropriate to the theory being used? In general relativity, this includes checking the covariant conservation of stress-energy and any applicable conserved quantities, while recognizing that global energy and momentum are not defined in every curved spacetime in the same simple way they are in flat spacetime.

Does it require forms or distributions of stress-energy that are not known to be physically realizable?

Does quantum theory introduce additional restrictions?

Does the required energy become unreasonable when the system scales?

Is an apparent effect actually a numerical artifact?

Could ordinary physics produce the same measurement?

Can the result be reproduced from the documented methods, and could it ultimately withstand independent external replication or examination?

And perhaps most importantly:

What result would count against the hypothesis or model?

For an experimentally testable hypothesis, that may be a specific observation. For an earlier theoretical model, it may instead be a mathematical inconsistency, violation of an established physical constraint, failure of a required assumption, numerical instability, or incompatibility with existing evidence. If we cannot identify meaningful conditions under which a claim or model would fail, it is not yet ready to be treated as a serious scientific test.

The Gap Analyzer

This has led to a Beyond the Light Barrier research-method concept that I call the Gap Analyzer.

The Gap Analyzer is not a scientific instrument, established external methodology, or physical theory. It is a project-defined review framework for systematically asking what still stands between a mathematical model, simulation, or engineering concept and a physically supported result.

Instead of asking only what a model accomplishes, the Gap Analyzer asks what stands between the model and physical reality.

For any significant WD or WC model, we can identify several kinds of gaps.

There may be a theory gap.

The mathematics may depend upon physics that has not been established.

There may be an energy gap.

The required energy may exceed anything remotely achievable.

There may be a materials gap.

The model may require properties that no known material possesses.

There may be a measurement gap.

The predicted effect may be too small for available instruments to distinguish from noise.

There may be a control gap.

An effect might theoretically exist without any known way to create, modulate, stabilize, or stop it.

There may be a scaling gap.

Something that appears possible microscopically may become impossible when scaled to useful dimensions.

There may be a causality gap.

A proposed faster-than-light communication or propulsion mechanism must be examined for compatibility with relativistic causality. Under standard relativistic assumptions, controllable faster-than-light signaling can create reference-frame-dependent ordering of events and, in some configurations, causal-loop or closed-causal-curve problems. A proposed mechanism therefore cannot be treated as physically viable merely because it appears to permit faster propagation; its causal structure must also be analyzed.

There may simply be an unknown gap—something we have not yet recognized.

The purpose of identifying these gaps is not to make the project sound more difficult.

It is to determine what question needs to be answered next.

Models Are Not Discoveries

This distinction deserves to be repeated throughout the project.

A model can be useful without being physically real.

A computer simulation can be valuable without demonstrating that nature behaves the same way.

A mathematical solution can be correct while describing conditions that cannot actually be engineered.

An analogy can help us understand a concept without reproducing the underlying physics.

For that reason, Beyond the Light Barrier will continue distinguishing among established evidence, accepted theory, published speculative theory, project hypotheses, engineering concepts, analytic calculations, numerical simulations, and physical experiments.

Those categories should not quietly blend together as the research progresses.

If we simulate a proposed spacetime geometry successfully, we should say:

The model produced this numerical result under these assumptions.

We should not say:

We demonstrated a warp drive.

Those statements mean very different things.

Negative Results Stay

Another rule follows naturally.

Failed models remain part of the research record.

Suppose WD-7 eventually fails because a fundamental constraint makes its proposed mechanism impossible.

We should not erase WD-7 and rename WD-8 as though the failed idea never existed.

Instead, the record should show:

What WD-7 proposed.

Why it initially appeared worth investigating.

What assumptions it used.

What analysis was performed.

What caused it to fail.

What we learned from the failure.

And whether any portion of the model remains useful.

The same principle applies to Project Communication.

If a WC experiment produces a carefully measured null result, that result belongs in the record.

A null result may eliminate one mechanism while helping us design the next experiment.

The same principle applies when a result survives but its original documentation, calculation, interpretation, or level of confidence requires correction. The project should preserve what was originally reported, identify what was incomplete or mistaken, document the corrective work, and state whether the original conclusion was confirmed, revised, or rejected. A corrected result should not be presented as though the stronger evidence had existed from the beginning.

Retiring an Idea Is Progress

This changes the meaning of failure.

Suppose we begin with ten possible mechanisms.

Careful analysis eliminates eight.

It might appear that the research has mostly failed.

In reality, we have learned that eight paths probably do not lead where we hoped.

That is knowledge we did not have before.

The remaining two mechanisms can then receive greater scrutiny.

Perhaps both eventually fail as well.

That would be disappointing, but scientifically it would still tell us something about the boundaries imposed by nature.

Beyond the Light Barrier should therefore be willing to use words such as:

Rejected.

Unsupported.

Inconclusive.

Not reproducible.

Below detection threshold.

Requires revision.

Retired.

Those words are not embarrassing.

Used correctly, they demonstrate that the research process is working.

Artificial Intelligence Needs the Same Scrutiny

AI is an important tool in this project.

It can search and compare scientific literature, explain unfamiliar mathematics, derive and check equations, develop models, write software, perform numerical analysis, identify possible contradictions, and help us explore a much larger number of possibilities than I could reasonably investigate alone.

But AI introduces its own risks.

It can make mistakes.

It can misunderstand scientific literature.

It can generate plausible-looking mathematics that contains an error.

It can connect ideas in ways that sound convincing without sufficient evidence.

It can also become overly accommodating to the direction of a conversation.

For those reasons, an AI-generated result does not receive special authority within this project.

Important calculations should be checked through fresh derivation or recalculation and, where numerical methods are involved, preferably compared using separately implemented computational methods. Such internal cross-checking should not be described as independent external reproduction. Results of sufficient importance should ultimately be reproducible by researchers outside the project.

Numerical results should be reproducible.

Published claims should be distinguished from our interpretation of those claims.

And potentially significant results should eventually receive scrutiny from people with the appropriate scientific expertise.

AI can accelerate the research process.

It cannot eliminate the need for verification.

Beyond the Light Barrier should also disclose material AI assistance when it contributes substantially to model development, mathematical derivation, software, numerical analysis, literature review, or preparation of published research. That disclosure should describe AI as a research and computational tool rather than as an independent scientific authority. Responsibility for the claims, classifications, corrections, and limitations presented by the project remains with the project.

The Strongest Test Comes From the Other Side

As the models become more sophisticated, another practice should become increasingly important.

When we believe we have found a promising result, we should temporarily stop trying to improve it.

Instead, we should construct the strongest argument we can against it.

Assume the result is wrong.

Then ask why.

Search the literature for constraints we may have missed.

Check alternative mathematical formulations.

Change numerical resolution.

Test boundary conditions.

Examine conservation laws.

Look for hidden assumptions.

Try conventional explanations.

Estimate experimental uncertainty.

Ask whether another researcher could reproduce the calculation or analysis from the information, equations, source code, data, parameters, and procedures we provide. Where a claim eventually becomes experimentally testable, independent replication should go further by asking whether researchers outside the project can obtain compatible results using independently controlled methods and experiments.

Only after surviving that process should our confidence increase.

When Something Becomes Worth Publishing

This also helps establish when Beyond the Light Barrier research should move beyond the Research Journal.

A journal entry can document an idea while it is still developing.

A Research Explained paper can communicate a sufficiently mature concept to readers without requiring them to follow advanced mathematics.

A Technical Paper requires considerably more.

Before calling something a Technical Paper candidate, we should expect a clearly defined question, relevant scientific literature, explicit assumptions, mathematical formulation, reproducible methods, quantitative results where applicable, uncertainty and limitations, consideration of alternative explanations, and clearly stated criteria by which the hypothesis or model could be contradicted, falsified, constrained, or shown to fail under its stated assumptions.

Not every model will reach that point.

Most probably should not.

The Standard Going Forward

The objective of Beyond the Light Barrier is ambitious.

But ambitious questions require stricter standards, not weaker ones.

So when a future WD or WC model appears particularly exciting, the next response should not be:

We found it.

The next response should be:

Now let's try to break it.

If it breaks, we document why.

If it survives, we test it harder.

If it continues surviving, we invite others to find the weakness we missed.

And if, someday, a result survives the mathematics, the literature, reproduction, experimental controls, independent examination, and repeated attempts to falsify it—

then we may finally have something genuinely interesting to report.

Until then, the failures are part of the journey too.

Research Integrity Status

Established research principles: Falsifiability, reproducibility, replication, transparency, uncertainty analysis, preservation of negative results, and critical examination of alternative explanations are established elements of scientific practice. The sources below provide background for these principles.

Beyond the Light Barrier research method: The Gap Analyzer, the project's specific model-review workflow, its publication categories, and its application of these broader scientific principles to WD and WC research are Beyond the Light Barrier methodological choices. They should not be presented as externally established scientific standards or independently validated research methods.

AI-assisted research: Artificial intelligence is used within Beyond the Light Barrier as a research, computational, analytical, and writing tool. AI-generated or AI-assisted calculations, interpretations, literature summaries, software, and model developments do not receive independent evidentiary status merely because they were produced or checked by AI. Material results require appropriate verification, documentation, and reproducibility.

Reproducibility and external replication: Internal recalculation, fresh derivation, convergence testing, and separately implemented computational methods can strengthen confidence in a result, but they are not equivalent to independent external reproduction or replication by researchers outside the project.

Corrections and negative results: Null results, failed models, revised interpretations, computational corrections, and retired ideas remain part of the research record when they materially affect the development or evaluation of a claim.

Scope: This entry establishes a research-integrity framework. It does not present experimental evidence for faster-than-light communication, warp propulsion, traversable wormholes, or any other speculative physical mechanism discussed by the project.

Sources & Further Reading

• Popper, Karl R. The Logic of Scientific Discovery. Routledge.
  Foundational discussion of falsifiability and the idea that scientific claims should be exposed to attempts at refutation rather than protected from them.

• National Academies of Sciences, Engineering, and Medicine. Reproducibility and Replicability in Science. National Academies Press, 2019.
  A comprehensive treatment of reproducibility, replication, uncertainty, transparency, and the processes by which scientific results gain credibility.

• National Academies of Sciences, Engineering, and Medicine. Fostering Integrity in Research. National Academies Press, 2017.
  Discusses research integrity, transparency, documentation, correction of errors, and responsibilities within the scientific process.

• Open Science Collaboration. “Estimating the reproducibility of psychological science.” Science, Vol. 349, Issue 6251, 2015.
  A major empirical examination of reproducibility that illustrates why independent replication is important before confidence in reported findings becomes strong.

• Nosek, Brian A., et al. “Promoting an open research culture.” Science, Vol. 348, Issue 6242, 2015.
  Describes transparency and openness practices intended to make scientific claims easier to evaluate, reproduce, and challenge.

• Ioannidis, John P. A. “Why Most Published Research Findings Are False.” PLoS Medicine, 2005.
  An influential analysis of how statistical power, bias, flexibility in research methods, and prior probabilities can affect the reliability of published findings.

Beyond the Light Barrier Research Method
The project's own research framework applies these broader principles by explicitly separating established evidence, accepted theory, published speculative theory, project hypotheses, engineering concepts, simulations, and experimental results—and by preserving negative results, uncertainty, corrections, and abandoned ideas rather than presenting only successful outcomes.

Research Journal Entry 2

From Questions to a Research Program

As the Beyond the Light Barrier project has developed, I have realized that something important has changed.

What began as a series of questions about faster-than-light travel and communication is becoming a structured research program.

Two primary areas of investigation have emerged:

Project Communication explores whether established physics—or a clearly identified and scientifically testable extension of it—permits any mechanism by which controllable information could traverse very large distances with propagation behavior meaningfully different from ordinary electromagnetic communication. This includes the highly speculative question of whether information could ever traverse a distance in less time than light would require to cross the corresponding path.

Project Propulsion explores whether established physics—or a clearly identified and scientifically testable extension of it—permits any mechanism by which an object could traverse a distance in less time than light would require to cross the corresponding ordinary-space path. This includes published speculative concepts involving spacetime geometry as well as other candidate mechanisms that may emerge from the research. Warp-drive physics is therefore an important area of investigation, but the project is deliberately not limited to a particular warp-drive metric, a conventional "warp bubble," or even to warp-drive concepts if another physically testable approach proves more promising.

The objective is not to prove that either possibility exists.

The objective is to find out what physics allows.

Research Rather Than Answers

Artificial intelligence plays an important role in this project, but an important distinction needs to be maintained.

AI is used in this project as a research and analytical tool. It can draw upon patterns learned from existing human knowledge and, when appropriate tools and sources are available, help locate and examine published physics, mathematics, engineering, and experimental research. Its outputs, however, are not themselves scientific sources and can contain errors, omissions, incorrect assumptions, or unsupported conclusions.

The models developed within Beyond the Light Barrier are therefore not treated as pre-existing answers retrieved from the scientific literature, nor are AI-generated ideas automatically treated as new scientific results.

They are developed iteratively.

I provide research questions, possible directions, engineering observations, and sometimes unconventional "what if?" questions. AI assists with literature discovery and comparison, mathematical and computational analysis, consistency checks, identification of assumptions and contradictions, development of testable predictions, experiment design, and successive model refinement.

Claims attributed to existing science should be checked against appropriate sources. Mathematical derivations, calculations, simulations, and other AI-assisted results should be independently checked where practical, with assumptions, methods, uncertainty, limitations, and corrections preserved in the research record.

That process does not automatically make the resulting ideas correct or novel.

Any result that appears potentially new must be treated provisionally. A claim of novelty requires careful comparison with the existing scientific literature; a mathematical or analytic result requires verification of its assumptions and derivation; a numerical or simulation result requires documented methods and reproducibility; and a claim about physical reality ultimately requires appropriate experimental or observational evidence. Independent external review or replication provides substantially stronger support than repeated analysis within the project alone.

Failure to find an existing publication describing the same idea is not, by itself, evidence that the idea is novel. Until an adequate literature review has been performed, the appropriate description is that the idea was developed within the project without a claim of priority or originality.

Trying to Disprove Our Own Ideas

One principle is becoming increasingly important:

We should not try to prove that faster-than-light communication or propulsion works. We should try to break every model we create.

For each significant hypothesis, the questions should include:

• What assumptions does this depend upon?

• Is the hypothesis consistent with established experimental and observational evidence within the conditions already tested, and if it predicts a departure from established theory, does it clearly identify where that departure occurs and what new observation could test it?

• Does the mathematics remain internally consistent?

• What energy would actually be required?

• Does it introduce causality problems?

• Is the proposed effect distinguishable from ordinary physics?

• What observation or experimental result would contradict or falsify a specific prediction of the hypothesis?

• Can the hypothesis produce a quantitative, testable prediction at a much smaller scale?

• Are the assumptions, derivations, code, numerical methods, and analysis documented well enough for another researcher to reproduce the result and, where applicable, independently replicate the experiment?

A model that fails one of these tests should not simply disappear from the project.

The failure is part of the research record.

If, for example, a proposed model fails because its required energy becomes physically unrealistic, that negative result may help constrain the next model.

A Living Research Record

From this point forward, the project will preserve the development history of its models.

The research record will distinguish among:

Established evidence — observations or measurements supported by appropriate experimental or observational evidence.

Accepted theory — theoretical frameworks strongly supported by existing evidence and established scientific work.

Published speculative theory — ideas appearing in the scientific literature but not experimentally established.

Project hypotheses — possibilities being investigated within Beyond the Light Barrier and not assumed to be physically correct.

Engineering concepts — proposed apparatus, implementations, or applications that may depend upon physics not yet demonstrated.

Analytic results — conclusions derived mathematically from explicitly stated assumptions and methods.

Numerical or simulation results — computational results obtained from specified models, assumptions, algorithms, and parameters. These must not be described as physical experiments or direct evidence that the modeled phenomenon exists in nature.

Computational verification and physical validation — these are separate questions. Verification asks whether the equations, algorithms, code, and numerical methods were implemented and solved correctly for the stated model. Validation asks whether that model adequately represents the physical system or phenomenon being investigated. A simulation may be computationally correct while the underlying physical model is incomplete, unrealistic, or unsupported by experiment.

Reproduced results — analytic or computational results that have been independently recalculated or rerun from sufficiently documented methods and found to agree within stated tolerances. Reproduction strengthens confidence in the calculation or implementation but does not by itself establish that the modeled physics exists in nature.

Experimental results — measurements obtained from actual physical experiments, reported together with the relevant apparatus, procedure, controls, calibration, uncertainty, analysis, and limitations.

Independent external replication — experimental results obtained by researchers outside the original project using sufficiently independent apparatus or implementation. External replication provides stronger evidence than repeated measurements performed only by the originating research team.

Negative and null results, abandoned or retired models, corrections, uncertainty, assumptions, limitations, unresolved questions, and changes in interpretation will remain part of the research record rather than being removed simply because they do not support a preferred hypothesis.

Communication Before Transportation

Another important direction has emerged.

If humanity someday developed a practical method of traveling across enormous distances much faster than we can today, conventional communication could become a serious limitation.

If a spacecraft could someday reach a distant destination much more rapidly than conventional propulsion allows while communication with Earth remained limited by ordinary light-travel time, communication latency could become a major operational constraint. Depending on the distance, information exchanged between the spacecraft and Earth could still require months or years to arrive.

For that reason, Project Communication is not merely a secondary problem that can be addressed after propulsion succeeds.

Communication deserves its own research path.

It may also offer opportunities for much smaller and more achievable experiments than propulsion.

Rather than beginning with interstellar distances, communication research should begin with a specific hypothesis that makes a quantitative, testable prediction at laboratory or terrestrial scale. The first experiment should seek the smallest measurable observable capable of distinguishing that prediction from conventional physics and known experimental effects.

An apparent effect should not be scaled to larger distances merely because it appears repeatedly. It should first survive appropriate controls, quantified uncertainty, challenges to conventional explanations, reproducibility work, and, when warranted, independent external replication. Only then should increasing distance become an experimental variable, guided by the quantitative predictions of the model.

The same philosophy applies to propulsion: begin with the smallest physically meaningful observable predicted by a specific model rather than assuming that a complete propulsion system—or a starship—must be designed first.

Where This Leads

Beyond the Light Barrier will therefore develop through several interconnected forms of publication.

The Research Journal will preserve the development process, including questions, decisions, model changes, failures, and lessons learned.

Research Explained papers will present significant ideas and results in language intended for interested readers who are not physicists or mathematicians.

Technical Papers will be reserved for work mature enough to present the relevant prior literature, assumptions, mathematical formulation, methodology, calculations, numerical methods or simulations, predicted observables, uncertainty where applicable, limitations, falsification criteria, and results in a form suitable for serious technical scrutiny. Each paper should clearly identify whether its results are analytic, numerical or simulated, reproduced, or experimental, and should provide sufficient methodological detail for qualified readers to evaluate and, where practical, reproduce the work.

A Technical Paper designation does not mean that the underlying hypothesis has been experimentally validated. A paper may rigorously document a theoretical, analytic, numerical, engineering, or negative result while clearly stating what remains untested. Experimental claims require physical measurements, and claims of independent replication require evidence from genuinely independent work.

Not every idea will reach the Technical Paper stage.

That is intentional.

Some ideas should fail.

The Goal

The goal of Beyond the Light Barrier is not to demonstrate that science fiction is possible.

It is to ask difficult questions about communication, spacetime, and propulsion—and then subject possible answers to increasingly difficult tests.

Perhaps physics ultimately says that some of these things cannot be done.

That would still be a result.

But if an idea remains mathematically and internally consistent, remains compatible with established evidence or clearly identifies the testable departure it proposes, survives serious attempts to falsify its predictions, and eventually survives increasingly rigorous experimental testing, then we will have learned something worth pursuing further.

Even then, the strength of the conclusion must match the strength of the evidence. A successful calculation supports the calculation, a successful simulation supports the behavior of the specified model, and a successful experiment supports only what that experiment was capable of testing. Broader claims require broader evidence, reproducibility, and, where appropriate, independent external replication.

For now, the research continues.

And so does the record of how we got there.

Research Integrity Status

Established science: The project begins from established experimental evidence and well-supported physical theories, including the relativistic constraints governing ordinary matter, information, and electromagnetic propagation. These established results are treated as constraints that proposed models must address rather than assumptions that may be ignored.

Published speculative theory: Some Beyond the Light Barrier research examines concepts already discussed in the scientific literature, including speculative approaches to unusual spacetime geometries and other mechanisms relevant to communication or propulsion. Publication in the scientific literature does not by itself establish that such mechanisms exist in nature or can be engineered.

Beyond the Light Barrier research: Project Communication and Project Propulsion investigate questions rather than predetermined answers. Project hypotheses, AI-assisted analyses, mathematical derivations, numerical simulations, and engineering concepts are identified according to their evidentiary status and are not treated as established physics merely because they were developed or analyzed within the project.

Research method: Models should state their assumptions, identify relevant established constraints, make quantitative and falsifiable predictions where possible, and be subjected to attempts to expose errors or conventional explanations. Analytic and computational results should be reproducible from documented methods, while physical claims require appropriate experimental or observational evidence and increasingly strong independent scrutiny.

Negative results: Null results, failed predictions, abandoned or retired models, corrections, limitations, uncertainty, and unresolved questions remain part of the research record. A model is not preserved merely because it supports the possibility of faster-than-light communication or propulsion.

Not demonstrated: This entry establishes a research program and methodology. It does not report experimental evidence for faster-than-light communication or propulsion, a demonstrated new spacetime effect, or a validated engineering system capable of producing such effects.

Sources & Further Reading

• Albert Einstein (1905), “On the Electrodynamics of Moving Bodies.” Einstein's special-relativity paper established the framework in which the speed of light in vacuum is invariant for inertial observers and helped define the relationship among space, time, motion, and causality that underlies modern relativistic physics. Modern tests of relativity have greatly extended the experimental evidence beyond this original paper. For Beyond the Light Barrier, special relativity provides part of the established physical framework against which proposals for unconventional communication or propulsion must be evaluated; citing the theory does not by itself determine whether a proposed spacetime-based mechanism is physically realizable.
  Einstein (1905) — On the Electrodynamics of Moving Bodies

• NASA — Deep Space Network. NASA's Deep Space Network is an international system of large antennas and communications facilities used to communicate with, command, and track spacecraft across the Solar System and beyond. It demonstrates the extraordinary reach of established electromagnetic communication technology while also illustrating a fundamental limitation that improved antennas, transmitters, receivers, and signal processing cannot remove: electromagnetic information still requires light-travel time to cross the distance between Earth and a spacecraft. The DSN therefore provides a real-world reference for the conventional communication problem that Project Communication seeks to investigate rather than evidence for an unconventional communication mechanism.
  NASA — Deep Space Network

• NASA — Space Communications: 7 Things You Need to Know. NASA's discussion of space communications illustrates the fundamental role of light-travel time in communication across large distances. Radio and optical communications both use electromagnetic radiation and therefore remain subject to the propagation speed of light in vacuum. Improvements in antennas, transmitters, receivers, coding, optical communication, and other technologies can substantially improve communication capability and data rates, but they do not eliminate the propagation delay imposed by distance. Earth–Mars communication provides a practical example because the delay changes substantially as the distance between the planets changes.
  NASA — Space Communications: 7 Things You Need to Know

• NASA — Delay/Disruption Tolerant Networking (DTN). NASA's work on Delay/Disruption Tolerant Networking demonstrates an important distinction between improving communication systems and changing the underlying propagation time of information. DTN is designed to help space networks operate despite long delays, intermittent connectivity, and disruptions by storing and forwarding data when an end-to-end connection is unavailable. Such networking techniques can make communication across large distances more reliable and operationally useful, but they do not eliminate the light-travel-time delay of the electromagnetic signals carrying the information. DTN therefore represents an engineering response to long-distance communication latency rather than a mechanism for faster-than-light communication.
  NASA — Delay/Disruption Tolerant Networking

• Stanford Encyclopedia of Philosophy — Scientific Method. The Stanford Encyclopedia's discussion of scientific method provides background for hypothesis testing, falsifiability, evidence, and the broader question of how scientific claims are evaluated. For Beyond the Light Barrier, the practical lesson is that a useful hypothesis should expose specific predictions to meaningful tests rather than seek only observations that appear to support it. A result consistent with a prediction can strengthen confidence in a model under the tested conditions, but it does not prove the model uniquely correct; contradictory results, alternative explanations, assumptions, measurement uncertainty, reproducibility, and independent scrutiny must also be considered.
  Stanford Encyclopedia of Philosophy — Scientific Method