Research Records #3 — From Architecture Findings to Research Requirements: What NAE-1 Must Inherit

Research Records #3
Public Technical Research Record — October 28, 2026

From Architecture Findings to Research Requirements: What NAE-1 Must Inherit

Purpose of This Record

On October 24, 2026, Beyond the Light Barrier closed the AR-1.7 Architecture Stress Audit investigation with eight unresolved architectural findings and their corrective obligations preserved.

On the same date, the project adopted the BTLB-SIM Next Architecture Exploration Charter v1.0, establishing NAE-1 as a separate investigation into the future architecture of the scientific simulation framework.

These decisions create an important research-governance question:

How can a new architecture investigation preserve the lessons of an earlier investigation without prematurely deciding what the new architecture must look like?

This record examines the eight findings that NAE-1 must account for, the distinction between findings and requirements, and a proposed method for maintaining traceability across architectural changes.

Scope limitation: This article explains established AR-1.7 obligations and a proposed inheritance approach. It does not claim that NAE-1 has completed or accepted an authoritative inheritance register, frozen new requirements, or selected a successor architecture.

1. Why Architecture Inheritance Matters

A software architecture can be replaced without eliminating the problems that motivated its replacement.

For example, if an earlier system accepted an inconsistent checkpoint history, replacing its storage implementation does not automatically establish that the successor validates checkpoint ancestry correctly.

Likewise, dividing a framework into smaller modules does not automatically resolve questions about publication durability, shared mutable state, scientific authority, or verification coverage.

An architecture investigation therefore needs to preserve more than a list of desired features.

It needs to retain the evidence explaining why particular behaviors are unacceptable, what was actually demonstrated, what remains uncertain, and what future design decisions must address.

This is the purpose of architectural inheritance: to carry forward justified obligations without automatically carrying forward every historical implementation choice.

Preserve the obligation, not necessarily the implementation.

2. The Eight Findings AR-1.7 Preserved

The authoritative AR-1.7 Final Bounded Closure Record preserved eight unresolved architectural findings. Their identifiers, mechanisms, qualifications, and corrective obligations are summarized below.

Finding	Preserved evidence and qualification	Open corrective obligation
F001 AR17-F006	Completion metadata was observed alongside incomplete persistence. A whole-publication guarantee remains prospective. Numerical corruption was not demonstrated.	Establish coherent publication, consumer, and durability semantics.
F002 Historical AR17-F007	An inconsistent checkpoint history was accepted. The finding concerns consistency, not whole-archive authentication.	Establish explicit history, prefix, and ancestry validation.
F003 AR17-F009	A stronger registered-row verification scope failed. A narrower explicit-Ref breach was not established.	Establish explicit bounded verification closure and acceptance.
F004 AR17-F011	Public nested policy aliases were mutable. No altered scientific calculation was demonstrated.	Establish ownership and nested policy integrity.
F005 AR17-F012	Run-entry release-byte drift was accepted. The newline probe did not establish semantic change.	Establish release-byte lifetime validation.
F006 AR17-F022	Partial additions survived a later conflict. Existing conflicting records remained intact.	Establish prospective batch atomicity.
F007 AR17-F026	Indirect synthetic aliases evaded the bounded scanner. An actual dependency leak was not demonstrated.	Establish scoped analysis policy and verification.
F008 AR17-F027	Nested pytest collection/profile mismatch was observed. A missed scientific regression was not demonstrated.	Establish complete intended collection and profile accounting.

Identifier clarification: F002 refers to historical AR17-F007. The separate corrective finding F007 refers to AR17-F026, case 026.

These findings must not be exaggerated. For example, a demonstrated integrity weakness does not establish that a scientific calculation was corrupted unless the evidence actually supports that conclusion.

3. Findings Are Not Automatically Requirements

A finding describes something established or constrained by an investigation.

A corrective obligation describes what remains to be addressed.

A requirement, in contrast, should define an expected property or behavior sufficiently precisely that compliance can eventually be evaluated.

These are related but distinct forms of information.

Finding ≠ Corrective Obligation ≠ Accepted Requirement

Consider F002, the accepted inconsistent checkpoint history.

The preserved finding establishes a specific consistency problem. Its corrective obligation calls for explicit history, prefix, and ancestry validation.

A future candidate requirement might specify that a checkpoint consumer must reject a history whose recorded ancestry is inconsistent with the governing history contract.

However, the precise contract, validation boundary, acceptable failure behavior, and verification method would still need to be established.

The example requirement is an illustrative formulation, not an already adopted NAE-1 requirement.

4. A Proposed Inheritance Process

The NAE-1 charter calls for an authoritative AR-1.7 inheritance register.

One possible process for developing that register is described below. This is a proposed implementation of the charter's investigation objectives, not a claim that these steps have been completed.

1. Identify the source evidence. Preserve the original finding, its historical identifier, supporting observations, classifications, and qualifications.
2. Extract the corrective obligation. Record what the investigation established must be addressed, without assuming a particular implementation.
3. Classify the proposed requirement. Determine whether it concerns scientific behavior, verification, architecture integrity, reproducibility, interoperability, operations, or another governed category.
4. Define the proposed acceptance boundary. Specify what future evidence would demonstrate compliance and what would count as failure or an inconclusive result.
5. Compare architectural alternatives. Investigate whether different designs could satisfy the same obligation, including retaining, replacing, or eliminating the relevant historical mechanism.
6. Record the decision and its authority. Preserve the disposition, rationale, remaining uncertainty, review scope, and explicit authorization status.
7. Maintain traceability. Connect the original evidence to the accepted requirement, future design decision, implementation, verification, and any later revision.

The process must also preserve the possibility that a candidate requirement is revised, deferred, rejected, or found inapplicable to a particular successor design.

Such a disposition would require justification and traceability. It must not silently erase the historical finding or its evidence.

5. Figure 1 — Proposed Evidence-to-Requirement Traceability

Figure 1. Proposed traceability process connecting preserved AR-1.7 evidence and corrective obligations to candidate NAE-1 requirements, review decisions, future architecture choices, and verification evidence. The diagram illustrates a possible governance workflow; it does not represent a completed inheritance register or accepted successor architecture.
Image attribution: AI-generated conceptual infographic created for Beyond the Light Barrier, October 2026. Based on the AR-1.7 Final Bounded Closure Record and the adopted BTLB-SIM Next Architecture Exploration Charter v1.0. This illustration depicts a proposed evidence-to-requirements traceability process, not a completed inheritance register, accepted requirements, selected architecture, verified implementation, numerical simulation result, independent reproduction, or physical experiment.

6. Inheritance Must Preserve Evidence Qualifications

The AR-1.7 investigation preserved a frozen set of 30 cases:

PASS          20
FAIL           8
INCONCLUSIVE   2
TOTAL         30

The broader evidence record contained 64 FAIL observations associated with the eight findings.

These were supporting repetitions or variants, not 64 independent architectural defects.

The record also preserved limitations involving an original harness timeout, an unreached cooperative injection, a Windows symlink permission limitation, and a pre-verification package-import failure.

A successor architecture investigation must not convert such limitations into demonstrated failures, nor treat inconclusive evidence as proof of successful behavior.

Likewise, a design-review ACCEPT disposition does not establish implementation acceptance.

In the final AR-1.7 review, F003 through F006 received ACCEPT at bounded design-review scope. F001, F002, F007, and F008 retained REVISE dispositions.

All eight corrective findings remained open at investigative closure.

7. The Broader Unresolved Architecture Frontier

The eight findings do not represent every unresolved question inherited from AR-1.7.

The closure also preserved incomplete work involving comparator behavior, graph structure, lexical and environment relationships, ordering, and other semantic obligations.

Its distinct historical evidence populations included 28 AST classes, 601 source-indexed rows, 401 owner records, 10 lexical histories, 13 roots, and 36 specification-only witnesses.

These populations are not additive measures of comprehensive semantic coverage.

The CP130 work retained necessary constraints without deriving sufficient positive H1 admissibility.

SC-1 remained INDETERMINATE/STOP, while SC2 through SC4 had not begun.

These boundaries require their own traceability and disposition decisions. They must not be assumed resolved merely because the eight corrective findings receive attention.

8. Architecture Freedom Does Not Eliminate Obligations

NAE-1 may investigate evolutionary correction, substantial redesign, specialized architectures, cohesive modular coordination, or other justified alternatives.

None has been selected in advance.

A replacement architecture might satisfy an obligation through a different mechanism than the original system used.

It might also eliminate the mechanism that originally exposed a problem.

In either case, the investigation still needs to establish what happens to the underlying obligation.

Eliminating an old component does not automatically prove that its associated integrity requirement is unnecessary.

Conversely, carrying forward every old implementation constraint could unnecessarily restrict architectural exploration.

NAE-1 must distinguish these cases through explicit reasoning and review.

9. What Would Count as Progress?

Progress in this phase should be measured by improved clarity and justified decisions, not by the amount of new code produced.

Examples of meaningful future milestones include:

• An authoritative, source-traceable AR-1.7 inheritance register.
• Reviewed candidate requirements with explicit scope and classification.
• Documented acceptance criteria and proposed verification methods.
• Comparative analysis of architectural alternatives and their failure modes.
• Explicit dispositions for obligations that are revised, deferred, or found inapplicable.
• A justified decision about whether architecture selection is ready to proceed.

These are possible future milestones. This article does not report that they have already occurred.

10. What Remains Unauthorized

The AR-1.7 closure and NAE-1 charter preserve distinct authorization boundaries.

At AR-1.7 closure:

AR17_INVESTIGATIVE_AUDIT = CLOSED_BOUNDED
OPEN_FINDINGS = 8
ARCHITECTURE_ACCEPTANCE = NOT_ESTABLISHED
CORRECTIVE_ARCHITECTURE_FROZEN = NO
IMPLEMENTATION_READY = NO
IMPLEMENTATION_AUTHORIZED = NO
SCIENTIFIC_VALIDATION = NONE

At NAE-1 charter adoption:

NAE1_STATUS = CHARTER_ADOPTED
COORDINATION_APPLICATION_BOUNDARY = HYPOTHESIS_UNDER_REVIEW
COMPOSITION_RESPONSIBILITY_MODEL = NOT_ESTABLISHED
ARCHITECTURE_SELECTED = NO
IMPLEMENTATION_AUTHORIZED = NO
WC_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPEN
WD_REQUIREMENT_INTAKE = NOT_YET_FORMALLY_OPEN

These values identify recorded historical states at their respective decisions. They are not claims about the outcome of any later work.

The proposed inheritance process does not itself authorize implementation, freeze architectural decisions, open formal WC/WD requirement intake, or establish scientific validation.

Research Conclusion

AR-1.7's final bounded closure preserved more than a list of software problems. It preserved evidence, qualifications, corrective obligations, and unresolved questions that constrain future decisions.

NAE-1 must account for that inheritance while retaining freedom to investigate substantially different architectures.

The next important step is not to assume that the old design should be repaired or replaced.

It is to establish which obligations remain necessary, what they mean, how they can be tested, and what architectural alternatives might satisfy them.

A new architecture should be free to change its design, but not free to forget the evidence.

Sources and Record Identity

1. Beyond the Light Barrier (2026). AR-1.7 Final Bounded Closure Record. Git commit cee28d7a3016223e0f28b776683a780d77fd707e, annotated tag ar17-final-closure, October 24, 2026.
2. Beyond the Light Barrier (2026). BTLB-SIM Next Architecture Exploration Charter v1.0 — Adopted. October 24, 2026.
3. Beyond the Light Barrier (2026). BTLB-SIM Next Architecture Exploration Charter — Adoption Record v1.0. October 24, 2026.
4. Beyond the Light Barrier (2026). Beyond the Light Barrier Research Method v1.2.
5. Beyond the Light Barrier (2026). BTLB Software Development Standards v1.1.

Evidence classification: This public technical record combines documented internal architecture-audit findings and adopted exploration governance with an explicitly proposed inheritance process. It does not report an accepted NAE-1 requirements register, a selected successor architecture, implementation authorization, Category 8 independent reproduction, Category 9 physical experimental evidence, or scientific validation.

Research Records #2 — NAE-1: Establishing the Next Architecture Exploration

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

Figure 1. Conceptual illustration of the architectural responsibilities under investigation in NAE-1. A possible coordination framework connects specialized capability modules and scientific experiments while supporting a cohesive research record. The figure illustrates candidate boundaries, not an accepted or implemented successor 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_OPEN

Research 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_BOUNDED

These 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

1. Beyond the Light Barrier (2026). BTLB-SIM Next Architecture Exploration Charter. Document ID BTLB-SIM-NAE-CHARTER, v1.0 — Adopted, October 24, 2026.
2. 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.
3. Beyond the Light Barrier (2026). AR-1.7 Final Bounded Closure Record. Git commit cee28d7a3016223e0f28b776683a780d77fd707e, annotated tag ar17-final-closure.
4. Beyond the Light Barrier (2026). Research Method v1.2.
5. 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.

Research Records #1 — AR-1.7: What the Final Architecture Audit Established—and What Remains Open.

Research Records #1
Public Technical Research Record — October 27, 2026

On October 24, 2026, Beyond the Light Barrier formally closed the AR-1.7 Architecture Stress Audit investigation for BTLB-SIM, the project's scientific simulation framework.

The investigation reached its justified boundary, but the architectural problems it identified were not all resolved. Eight findings and their corrective obligations remain open.

This record makes the final disposition, the eight findings, their qualifications, and the remaining authorization boundaries accessible to future researchers.

Closing an investigation is not the same as accepting the architecture it investigated.

Purpose and Authority of This Public Record

This article is a public explanatory derivative of the authoritative AR-1.7 closure records. It summarizes their reported findings and limitations; it does not replace the original evidence, independently reproduce the investigation, or establish new acceptance decisions.

The final closure was recorded at Git commit cee28d7a3016223e0f28b776683a780d77fd707e, with annotated tag ar17-final-closure. The tag was created on October 24, 2026.

1. Final Investigative Disposition

The recorded closure state is:

AR17_INVESTIGATIVE_AUDIT = CLOSED_BOUNDED
FINAL_AR17_CLOSURE_DECLARED = YES
OPEN_FINDINGS = 8

The designation CLOSED_BOUNDED means that sufficient investigation, synthesis, reconciliation, preservation, and bounded review had been completed to close the defined investigative program while retaining unresolved findings.

The frozen overall architecture-acceptance criterion remained unmet because unresolved invariant failures and corrective obligations survived.

2. Frozen Investigation Results

The original frozen set of 30 cases retained the following classifications:

PASS          20
FAIL           8
INCONCLUSIVE   2
TOTAL         30

The eight FAIL case identifiers were 006, 007, 009, 011, 012, 022, 026, 027. Cases 016 and 029 remained inconclusive.

The historical record also preserves distinct limitations involving the original case 001 harness timeout, case 016's unreached native cooperative injection, case 029's Windows symlink permission limitation, and case 030's pre-verification package-import failure.

The broader evidence record contains 64 FAIL observations. These are supporting repetitions or variants associated with eight findings, not 64 independently established architectural defects.

3. The Eight Open Architectural Findings

The following table preserves the finding identifiers, qualified mechanisms, and corrective obligations from the final closure record. The explanations are condensed for public readability.

Finding	Preserved mechanism and qualification	Open corrective obligation
F001 / AR17-F006	Completion metadata versus incomplete persistence. A prospective whole-publication guarantee is needed; numerical corruption was not demonstrated.	Coherent publication, consumer, and durability semantics.
F002 / historical AR17-F007	Inconsistent checkpoint history was accepted. The finding concerns consistency, not demonstrated failure of whole-archive authentication.	Explicit history, prefix, and ancestry validation.
F003 / AR17-F009	Stronger registered-row verification scope failed. A narrower explicit-Ref breach was not established.	Explicit bounded verification closure and acceptance.
F004 / AR17-F011	Public nested policy aliases were mutable. An altered scientific calculation was not demonstrated.	Ownership and nested policy integrity.
F005 / AR17-F012	Run-entry release-byte drift was accepted. The newline probe did not establish semantic change.	Release-byte lifetime validation.
F006 / AR17-F022	Partial additions survived a later conflict. Existing conflicting records remained intact.	Prospective batch atomicity.
F007 / AR17-F026	Indirect synthetic aliases evaded the bounded scanner. An actual dependency leak was not demonstrated.	Scoped analysis policy and verification.
F008 / AR17-F027	Nested pytest collection/profile mismatch. A missed scientific regression was not demonstrated.	Complete intended collection and profile accounting.

Identifier clarification: F002 corresponds to historical AR17-F007. The separate corrective finding F007 corresponds to AR17-F026, case 026.

4. Corrective Design-Review Status

The corrective architecture work had reached different bounded design-review dispositions:

F001  REVISE
F002  REVISE
F003  ACCEPT (bounded design-review scope)
F004  ACCEPT (bounded design-review scope)
F005  ACCEPT (bounded design-review scope)
F006  ACCEPT (bounded design-review scope)
F007  REVISE
F008  REVISE

These dispositions do not constitute implementation acceptance. Architecture Decisions AD01 through AD06 remain unfrozen. AD05's favorable scoped review does not override its integrated REVISE context.

5. Visual Summary of the Closure Boundary

Figure 1. Conceptual summary of AR-1.7's final bounded investigative closure. The original frozen 30-case classifications, eight open findings, 64 supporting FAIL observations, and bounded corrective design-review dispositions are shown as distinct evidence populations. Closure preserves unresolved obligations; it does not establish architecture acceptance, implementation readiness, or scientific validation.
Image attribution: AI-generated conceptual infographic created for Beyond the Light Barrier, October 2026. Based on the project's AR-1.7 Final Bounded Closure Record. This is an explanatory visualization, not a screenshot of verified software, a numerical simulation result, independent reproduction, or a physical experiment.

6. Additional Unresolved Evidence Boundaries

The eight findings are not the entire unresolved record. The final closure also preserves incomplete comparator, graph, lexical, environment, and ordering work.

The historical populations of 28 AST classes, 601 source-indexed rows, 401 owner records, 10 lexical histories, 13 roots, and 36 specification-only witnesses remain distinct. They cannot be added together and represented as comprehensive semantic coverage.

The CP130 requirements retain their recorded classifications and qualifications. Necessary constraints do not establish sufficient positive H1 acceptance.

Positive H1 admissibility remains unestablished. NC-A remains open; E3 is undecomposed; current E4 and RCH remain unresolved; NC-T remains parked. No complete positive producer/authority chain was established by closure.

The original H+ reports remain unavailable in the preserved package. Later summaries are not substitutes for the originals. The bounded closure review treated that provenance limitation as immaterial to the narrower closure decision, not as validation of the original arguments.

SC-1 remained INDETERMINATE/STOP, while SC2 through SC4 had not begun. The P-NEG work retained conditional eligibility and unresolved executable-testability and oracle questions. No positive reuse rule was established.

7. Preservation and Review Limitations

The final closure record reports a fresh verifier-first restoration, remote preservation verification, and zero changes to production source, tests, or fixtures during final closure.

A separately delegated fresh-context AI review returned the disposition SUPPORTS BOUNDED CLOSURE. The review was limited to whether the preserved investigation supported its stated bounded closure decision.

That review does not establish architecture acceptance, independent scientific reproduction, external peer review, or physical validation. Documentary agreement must not be counted as independent experimental evidence.

8. What Remains Unauthorized

The formal closure preserves these restrictions:

ARCHITECTURE_ACCEPTANCE = NOT_ESTABLISHED
CORRECTIVE_ARCHITECTURE_FROZEN = NO
IMPLEMENTATION_READY = NO
IMPLEMENTATION_AUTHORIZED = NO
CATEGORY_8_RESULT = NONE
CATEGORY_9_RESULT = NONE
SCIENTIFIC_VALIDATION = NONE

These restrictions are substantive research boundaries, not administrative formalities. A later architecture must establish its own requirements, evidence, verification, and authorization before stronger claims are justified.

9. Relationship to NAE-1

Also on October 24, 2026, Beyond the Light Barrier adopted the BTLB-SIM Next Architecture Exploration Charter v1.0.

This established NAE-1 as a separate architecture exploration phase. It did not reopen AR-1.7, close the eight findings, freeze AD01–AD06, select a successor architecture, or authorize implementation.

NAE-1 may investigate evolutionary correction, substantial redesign, cohesive modular coordination, multiple specialized architectures, or other justified alternatives. None is selected in advance.

A separate public record will address the NAE-1 charter and its governing hypotheses in greater detail.

10. Reproducibility and Traceability

The authoritative source for this public summary is:

Repository: BTLB-SIM
Git tag: ar17-final-closure
Commit: cee28d7a3016223e0f28b776683a780d77fd707e

Source:
docs/architecture/AR-1.7/AR-1.7-FINAL-BOUNDED-CLOSURE.md

The source record points to the reconciled synthesis, reconciliation register, negative/null register, original specification, and primary evidence. Each retains its own scope and provenance qualifications.

This public summary is not a complete reproduction package. Repository access and access to the underlying evidence are not implied by publishing these identifiers.

Research Conclusion

AR-1.7 established a defensible stopping point for a defined architecture investigation while retaining its failures, unresolved obligations, historical limitations, and evidence boundaries.

Its most important result is not that BTLB-SIM passed architecture acceptance. It did not.

The contribution is a preserved, traceable account of what was investigated, what failed, what remains inconclusive, and what a future architecture must still establish.

A completed investigation can be a valid research result even when the system it investigated is not yet accepted.

Sources and Further Reading

1. Beyond the Light Barrier (2026). AR-1.7 Final Bounded Closure Record. Git commit cee28d7a3016223e0f28b776683a780d77fd707e, annotated tag ar17-final-closure, October 24, 2026.
2. Beyond the Light Barrier (2026). AR-1.7 Final Synthesis and Closure Dossier, Draft 2. Preserved supporting synthesis; not a replacement for the final closure decision.
3. Beyond the Light Barrier (2026). BTLB-SIM Next Architecture Exploration Charter v1.0 — Adopted. October 24, 2026.
4. Beyond the Light Barrier (2026). NAE-1 Adoption Record v1.0. October 24, 2026.
5. Beyond the Light Barrier (2026). Beyond the Light Barrier Research Method v1.2.
6. Beyond the Light Barrier (2026). BTLB Software Development Standards v1.1.

Evidence classification: This public technical record summarizes an internal software-architecture investigation and its documentary closure. It does not establish Category 8 independent reproduction, Category 9 physical experimental evidence, scientific validation, architecture acceptance, or implementation authorization.