Research Records #2
Public Technical Research Record — October 27, 2026
NAE-1: Establishing the Next Architecture Exploration
Purpose of This Record
On October 24, 2026, Beyond the Light Barrier adopted the BTLB-SIM Next Architecture Exploration Charter v1.0, establishing NAE-1 as the next architecture investigation for the project's scientific simulation framework.
The adoption followed AR-1.7's final bounded investigative closure, which preserved eight unresolved architectural findings and their corrective obligations.
NAE-1 is not an implementation project. It is an investigation intended to determine what architectural direction BTLB-SIM should take next.
This public record explains the charter's scientific and engineering rationale, the alternatives it permits, the questions it leaves open, and the boundaries of its authorization.
1. Why a New Architecture Investigation Was Needed
BTLB-SIM was developed to support multiple scientific investigations without making its shared infrastructure dependent on any single physical model.
During earlier VAPE development, the project deliberately moved toward separating shared execution infrastructure from application-specific scientific behavior.
The intended separation included three broad responsibilities:
- A shared framework for coordination, execution, validation, artifacts, and provenance.
- Specialized modules providing computational or scientific capabilities.
- Scientific applications defining experiments, physical models, assumptions, and interpretations.
This historical design intent remains important. However, the implementation and verification record does not establish that every proposed boundary was correctly defined or comprehensively verified.
AR-1.7 exposed unresolved questions about those boundaries, particularly how scientific meaning, authority, and evidence should move through a composed computational system.
The next investigation must therefore consider whether to retain, refine, replace, or reject parts of the inherited architecture.
2. The Central Architectural Hypothesis
The adopted charter establishes a proposition for investigation:
Coordination of scientific capabilities does not by itself confer scientific interpretive authority.
In abbreviated form:
Coordination ≠ Scientific Interpretation
Consider a framework that connects a numerical solver to a scientific experiment.
The framework may know which solver was used, what inputs it received, what units were declared, what software version executed, and where the resulting artifacts were stored.
That information does not automatically make the framework authoritative about whether the solver's output supports a physical hypothesis.
Yet the opposite extreme is also unacceptable.
A framework cannot simply ignore units, domain restrictions, uncertainty, evidence classifications, or integrity requirements because scientific interpretation belongs elsewhere.
The question is not whether coordination should understand anything about science.
The question is:
What semantic and contractual knowledge must a coordination framework possess to operate reliably, without unnecessarily acquiring authority over scientific interpretation?
The charter treats the location of this boundary as a hypothesis under review, not an established architectural answer.
3. A Candidate Architecture, Not a Selected Architecture
The charter permits investigation of a cohesive architecture organized around several conceptual responsibilities.
Coordination Framework
May provide capability discovery, dependency resolution, compatibility checks, execution coordination, lifecycle management, diagnostics, provenance, artifacts, and reproducibility infrastructure.
Capability Modules
May provide specialized numerical, analytical, scientific, verification, instrumentation, or other computational capabilities. Different module families may require different internal designs.
Experiment/Application Layer
Primarily defines the scientific purpose, physical model, equations, assumptions, approximations, initial and boundary conditions, predicted observables, and interpretation. Some responsibilities may be shared with scientifically responsible modules where justified.
Cohesive Research View
May allow researchers to reconstruct the relationship among models, experiments, software versions, execution environments, numerical results, uncertainty, negative findings, and scientific conclusions.
These are candidate responsibilities. Their exact placement, interfaces, and composition rules have not been selected.
Unified research view ≠ Single execution architecture
A project may eventually support different computational systems while maintaining a coherent scientific record across them.
Whether BTLB-SIM needs such an arrangement remains an open question.
Figure 1 — Proposed Conceptual Architecture
Image attribution: AI-generated conceptual infographic created for Beyond the Light Barrier, October 2026. Based on the BTLB-SIM Next Architecture Exploration Charter v1.0 — Adopted. This is an explanatory visualization of candidate architectural responsibilities, not an accepted or implemented design, a screenshot of verified software, a numerical simulation result, independent reproduction, or a physical experiment.
4. One Architecture or Several?
Scientific software does not necessarily benefit from a single universal internal design.
A deterministic numerical solver, a symbolic mathematics system, a GPU-accelerated computation, and an AI-assisted reasoning component may have very different requirements.
NAE-1 permits investigation of specialized architectures, including compiled numerical modules, numerical-relativity systems, distributed computation, external scientific software, and other approaches.
These examples do not establish that BTLB-SIM requires those capabilities.
Architectural diversity introduces costs: additional interfaces, compatibility rules, testing, provenance, maintenance, and opportunities for inconsistent scientific interpretation.
A specialized architecture should therefore be justified by its requirements and benefits, not merely by the fact that modularity makes it possible.
The investigation must also consider whether common external contracts can support different internal implementations.
Common contract ≠ Common implementation
Existing governing obligations remain binding unless changed through the applicable governance process. Architectural flexibility does not authorize abandoning integrity, reproducibility, or preservation requirements.
5. Who Has Authority to Interpret a Result?
A scientific simulation produces information. That information may pass through multiple components before a researcher examines it.
NAE-1 must investigate questions such as:
- Which component produced a result, and under what contract?
- What scientific or numerical meaning does the result claim?
- Which component may transform or combine it?
- Which component may rely on it?
- Who is responsible for interpreting it?
- What evidence supports that interpretation?
- What authority is transferred across an interface, if any?
These questions become especially important when results from different modules are combined.
An application cannot avoid shared validation or integrity safeguards merely by claiming exclusive scientific authority.
Likewise, a coordination framework cannot silently assume scientific authority because it transported, stored, or scheduled a result.
The charter also rejects circular responsibility assignments in which components justify each other's authority without an independent evidentiary basis.
A trustworthy architecture must establish responsibilities through explicit, supportable contracts rather than implied authority.
6. Scientific Requirements Must Come Before Software Decisions
NAE-1 adopts a governing development distinction:
Requirement Discovery ≠ Architecture Selection ≠ Implementation
A scientific program should describe the research problem it needs to investigate before deciding how software must be structured to solve it.
For example, a WC or WD investigation might require numerical propagation through a candidate spacetime geometry, specified precision, defined initial and boundary conditions, and comparisons against known limiting cases.
That scientific need does not automatically determine whether the calculation belongs in an existing module, a new module, an external package, or a specialized computational architecture.
NAE-1 will distinguish scientific, verification, scientific-validation, reproducibility, architecture-integrity, interoperability, operational, exploratory, derived, and corrective requirements.
Classification does not itself establish acceptance or priority.
Consequential architecture decisions must compare alternatives, assumptions, limitations, failure modes, verification implications, maintenance costs, scientific consequences, and evidence that could justify reconsideration.
7. Relationship to WC and WD
The Wormhole Communication (WC) and advanced propulsion (WD) research programs remain responsible for their scientific questions, hypotheses, and proposed experiments.
They should not be forced to conform their research questions to assumptions embedded in an existing software architecture.
However, the adopted NAE-1 charter does not itself open formal WC or WD requirement intake.
At adoption:
WC_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPEN
WD_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPENResearch preparation may continue. Formal intake requires separate explicit authorization.
Once opened, proposed capabilities can be evaluated against existing simulator functionality, AR-1.7 findings, scientific justification, verification requirements, and possible architectural alternatives.
8. AI Is a Candidate Capability, Not an Authority
The charter permits investigation of AI-assisted architecture analysis, anomaly identification, experiment planning, semantic consistency checks, provenance analysis, and result challenges.
It does not assign AI an established architectural role.
AI reasoning introduces particular concerns involving nondeterminism, reproducibility, unsupported inference, provenance, and the possibility of silently strengthening scientific claims.
NAE-1 must investigate where AI might be useful and where it should be prohibited from exercising scientific or architectural authority.
Recording an AI-generated interpretation does not make that interpretation scientifically established.
Human intervention that materially influences results or decisions must likewise be handled according to applicable provenance and authorization requirements.
9. What the Charter Actually Authorized
The charter was adopted by explicit project-owner authorization on October 24, 2026.
Its v0.3 adoption candidate received a fresh bounded AI-assisted documentary review with the disposition A — SUPPORTS ADOPTION.
Three optional editorial clarifications were incorporated into the v1.0 adopted derivative, together with administrative adoption updates.
The adoption record preserves the exact reviewed source identity, the changes made, and the review limitations. It does not claim that the final v1.0 text received a new full independent review.
The current adopted state was:
NAE1_STATUS = CHARTER_ADOPTED
CHARTER_VERSION = 1.0
COORDINATION_APPLICATION_BOUNDARY = HYPOTHESIS_UNDER_REVIEW
COMPOSITION_RESPONSIBILITY_MODEL = NOT_ESTABLISHED
COHESIVE_FRAMEWORK_SELECTED = NO
MULTIPLE_ARCHITECTURES_REQUIRED = NOT_ESTABLISHED
ARCHITECTURE_SELECTED = NO
IMPLEMENTATION_AUTHORIZED = NO
WC_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPEN
WD_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPEN
AR17_STATUS = CLOSED_BOUNDEDThese are the recorded states at adoption, not an assertion that no subsequent work could change them.
The charter did not close AR-1.7's eight findings, freeze AD01–AD06, establish architecture acceptance, authorize implementation, or demonstrate scientific validation.
The bounded review was internal and AI-assisted. It was not external peer review, Category 8 independent scientific reproduction, or Category 9 physical experimental evidence.
10. How NAE-1 Will Proceed
The charter establishes an initial investigation program rather than an implementation schedule.
Its activities include constructing an authoritative AR-1.7 inheritance register, inventorying existing capabilities, reconstructing historical architecture boundaries, classifying requirements, investigating semantic authority and composition responsibilities, comparing alternatives, and establishing criteria for future decisions.
The investigation must preserve negative results and rejected alternatives.
It should stop or defer decisions when requirements are insufficiently understood, evidence is unavailable, responsibilities are circular, governing obligations would be bypassed, or architectural complexity lacks sufficient justification.
Stopping is an acceptable outcome.
NAE-1 succeeds when sufficient justified architectural direction exists to authorize a defined next phase, with explicit requirements, decisions, risks, verification strategy, and implementation authorization criteria.
It does not succeed merely by producing a convincing diagram.
Research Conclusion
The adoption of NAE-1 marks a change in the project's architectural investigation, not the completion of a successor architecture.
AR-1.7 established important constraints and preserved unresolved obligations. NAE-1 now provides a governed process for determining how those constraints should influence future design.
Its central challenge is to create trustworthy coordination among scientific capabilities without confusing software execution, semantic responsibility, scientific interpretation, and evidentiary authority.
The outcome remains open.
Sources and Record Identity
-
Beyond the Light Barrier (2026).
BTLB-SIM Next Architecture Exploration Charter.
Document ID
BTLB-SIM-NAE-CHARTER, v1.0 — Adopted, October 24, 2026. -
Beyond the Light Barrier (2026).
BTLB-SIM Next Architecture Exploration Charter — Adoption Record.
Document ID
BTLB-SIM-NAE-ADOPTION-RECORD, v1.0, October 24, 2026. -
Beyond the Light Barrier (2026).
AR-1.7 Final Bounded Closure Record.
Git commit
cee28d7a3016223e0f28b776683a780d77fd707e, annotated tagar17-final-closure. - Beyond the Light Barrier (2026). Research Method v1.2.
- Beyond the Light Barrier (2026). Software Development Standards v1.1.
Evidence classification: Adopted internal architecture-exploration governance and documentary review. This article reports no selected successor architecture, implementation authorization, Category 8 independent reproduction, Category 9 physical experimental result, or scientific validation.
No comments:
Post a Comment