The Core Problem

A speculative cosmology model is easy to describe in words and very hard to simulate honestly.

If the model claims that the universe is static rather than expanding, then redshift cannot be hidden inside an expanding metric. If the model allows the speed of light to vary over cosmic time, then mass, charge, and Planck-scale quantities cannot be changed carelessly without breaking atomic stability. If the model treats tired light as a real physical process, then the lost photon energy must be tracked, transferred, stored, or converted.

That is why ArcSecs needs a physics engine instead of a loose collection of equations.

The purpose of the engine is not to prove a speculative cosmology true. The purpose is to force every speculative cosmology to run through a strict computational ledger.

In TDD Physics terms, the universe under simulation is treated as a system under test.

Assert.Conserves(Energy);
Assert.Conserves(Momentum);
Assert.Preserves(DimensionlessConstants);
Assert.DoesNotHideNumericalInstability);
Assert.Identifies(FalsificationCondition);
Assert.Matches(SelectedObservationalTargets);

The engine is designed to ask a simple but brutal question:

Can a speculative static-universe model survive 15 billion years of simulated time without breaking its own physics?

The Architecture in One Sentence

The ArcSecs speculative cosmology engine is a strongly typed TypeScript simulation framework that separates covariant constants, particles, photons, metric calculations, adaptive integration, orchestration, memory storage, and visualization into isolated modules that can be tested independently.

The core pipeline is:

1. Initialize a cosmological hypothesis.
2. Generate the starting cosmic state.
3. Mutate constants through a controlled manager.
4. Propagate photons through tired-light and Proca dispersion logic.
5. Scale particle mass according to the selected covariant model.
6. Integrate over time using adaptive RKF45 steps.
7. Store raw state in Float64Array-backed buffers.
8. Downsample with LTTB for visualization.
9. Run the test suite against invariants and observational targets.

Observation -> Hypothesis -> CosmicState -> Integration -> Buffer -> Visualization -> Test Result

Why This Must Be Test-Driven

A static cosmology engine can fail in many ways that are not obvious from a graph.

• The simulation can lose energy numerically.
• The fine-structure constant can drift and silently destroy chemistry.
• The time step can become too coarse during high-curvature epochs.
• The visualization can smooth away the very anomaly being tested.
• The model can explain redshift while breaking supernova time dilation or baryon acoustic oscillation constraints.
• The engine can appear stable only because floating-point precision has collapsed.

TDD Physics prevents the engine from hiding those failures.

describe("Cosmology Engine Invariants", () => {
    test("Energy ledger remains closed", () => {
        expect(totalEnergyDelta).toBeLessThan(allowedTolerance);
    });

    test("Fine structure constant remains dimensionless-stable", () => {
        expect(alphaDrift).toBeLessThan(allowedTolerance);
    });

    test("Adaptive integrator responds to high curvature", () => {
        expect(timeStepSec).toBeLessThan(maximumStepDuringHighCurvature);
    });
});

The tests are not decorative. They are the boundary between a physics engine and a visual toy.

Core Project Structure

The engine should be organized around physical responsibility, not around convenience. Each module owns one kind of mutation.

The key rule is:

No module should mutate a physical state it does not own.

The CosmicState Boundary

The engine needs one primary state shape that every major subsystem understands. That state must be explicit, numeric, serializable, and stable enough to survive millions of integration steps.

export interface CosmicState {
    timeGy: number;
    timeStepSec: number;
    c_t: number;
    G_t: number;
    alpha: number;
    e_charge: number;
    h_bar: number;
    massMultiplier: number;
}

Each field has a strict purpose.

SimulationConfig: The Hypothesis Switchboard

The engine should not hard-code one cosmology. It should allow competing speculative models to run through the same test harness.

export type VslModel = "NONE" | "PIPINO_EXPONENTIAL" | "ALFONSO_FAUS_FRACTAL" | "CUSTOM";

export type TiredLightModel = "NONE" | "CONTINUOUS_DECAY" | "COMPTON_SCATTERING" | "PROCA_DISPERSION";

export interface SimulationConfig {
    startTimeGy: number;
    endTimeGy: number;
    initialTimeStepSec: number;
    minimumTimeStepSec: number;
    maximumTimeStepSec: number;
    vslModel: VslModel;
    tiredLightModel: TiredLightModel;
    preserveFineStructureConstant: boolean;
    enableMassBoom: boolean;
    enableProcaPhotonMass: boolean;
    photonMassEv: number;
    errorTolerance: number;
    outputSampleLimit: number;
}

This makes the engine comparative. A researcher can run the same supernova redshift scenario under different assumptions and compare failures instead of defending only one preferred interpretation.

Model Branch One: Variable Speed of Light

The first speculative branch is a Variable Speed of Light model. In this branch, the engine allows c_t to vary across cosmic time instead of treating it as a fixed universal value for every epoch.

This is not mainstream cosmology. It is a hypothesis under test. The engine’s job is to make that hypothesis computationally accountable.

public calculateSpeedOfLight(timeGy: number, config: SimulationConfig): number {
    if (config.vslModel === "NONE") {
        return PhysicalConstants.SpeedOfLightNow;
    }

    if (config.vslModel === "PIPINO_EXPONENTIAL") {
        return this.calculatePipinoExponentialSpeed(timeGy);
    }

    if (config.vslModel === "ALFONSO_FAUS_FRACTAL") {
        return this.calculateAlfonsoFausSpeed(timeGy);
    }

    return this.calculateCustomSpeed(timeGy);
}

The TDD question is:

If c_t changes, what else must covary so the universe does not become chemically or thermodynamically impossible?

Model Branch Two: Mass-Boom Scaling

If the speed of light changes across time, the engine cannot ignore mass. A static-universe model that changes c_t while leaving every other quantity untouched can easily destroy energy conservation.

The mass-boom branch solves that by allowing particle mass to scale covariantly.

public calculateMassMultiplier(currentSpeedOfLight: number): number {
    const presentSpeedOfLight: number = PhysicalConstants.SpeedOfLightNow;
    return presentSpeedOfLight / currentSpeedOfLight;
}

The exact formula depends on the selected hypothesis, but the TDD requirement does not change:

Assert.True(MassScalingDefined);
Assert.True(EnergyLedgerCloses);
Assert.False(MassMutationIsHiddenSideEffect);

The engine should treat mass scaling as a visible, testable result, not as an invisible correction factor.

Model Branch Three: CCC + Tired Light

The covarying-coupling-constants plus tired-light branch adds another constraint. If dimensional constants vary, dimensionless constants must remain stable.

The fine-structure constant is especially important because it governs electromagnetic interaction strength and atomic structure.

public enforceFineStructureStability(state: CosmicState): CosmicState {
    if (!this.config.preserveFineStructureConstant) {
        return state;
    }

    const targetAlpha: number = PhysicalConstants.FineStructureConstant;
    const adjustedCharge: number = this.solveChargeForAlpha(
        targetAlpha,
        state.h_bar,
        state.c_t
    );

    return {
        ...state,
        alpha: targetAlpha,
        e_charge: adjustedCharge
    };
}

The test is non-negotiable:

Assert.Equal(PhysicalConstants.FineStructureConstant, state.alpha, tolerance);

If the engine allows alpha to drift without explanation, the simulation may still render a pretty graph, but the universe it describes no longer supports the same chemistry.

Model Branch Four: Proca Tired-Light Photons

The tired-light branch requires photon energy to decay across long-distance propagation. In the ArcSecs speculative framework, this is paired with Proca-style massive photon behavior.

In ordinary Maxwellian electrodynamics, photons are treated as massless. In a Proca branch, photon-like excitations have a tiny nonzero rest mass, which can produce frequency-dependent propagation behavior.

The engine should model this carefully and label it clearly as a speculative branch.

export interface PhotonState {
    emittedFrequencyHz: number;
    currentFrequencyHz: number;
    emittedEnergyJ: number;
    currentEnergyJ: number;
    groupVelocity: number;
    distanceTraveledM: number;
    redshift: number;
    condensateFraction: number;
}

The photon entity must answer three questions:

1. How much energy has the photon lost?
2. Where did that energy go?
3. Has the photon crossed a tired-light phase threshold?

Assert.True(photon.currentEnergyJ <= photon.emittedEnergyJ);
Assert.NotNull(photonEnergyReservoir);
Assert.True(totalPhotonEnergy + reservoirEnergy === initialPhotonEnergy);

Tired Light as a Phase-Transition Problem

The most useful way to simulate tired light is not as a vague fading effect. It should be modeled as an explicit state transition.

The engine can treat ancient photons as progressing through phases:

1. Active high-frequency radiation.
2. Redshifted propagating radiation.
3. Low-energy massive photon state.
4. Cold sub-luminal tired-light condensate.
5. Dark-matter-like gravitational substrate.

export type PhotonPhase =
    | "ACTIVE_RADIATION"
    | "REDSHIFTED_RADIATION"
    | "LOW_ENERGY_PROCA_STATE"
    | "TIRED_LIGHT_CONDENSATE"
    | "DARK_MATTER_SUBSTRATE";

That gives the simulation a testable transition boundary.

if (photon.currentFrequencyHz < config.condensateThresholdHz) {
    photon.phase = "TIRED_LIGHT_CONDENSATE";
}

Without a phase boundary, the tired-light model becomes vague. With a phase boundary, it can be tested, graphed, and falsified.

The Adaptive Integration Problem

A 15-billion-year simulation cannot use one naive fixed time step.

Some epochs may be numerically calm. Others may involve steep exponential decay, high dispersion, or sharp phase transitions. If the time step is too large, the engine jumps over the very behavior it needs to test. If the time step is too small everywhere, the simulation becomes computationally impossible.

The solution is an adaptive Runge-Kutta-Fehlberg integration loop, commonly known as RKF45.

public integrateNextState(state: CosmicState): CosmicState {
    const candidate = this.rkf45Solver.step(state);
    const error = candidate.estimatedError;

    if (error > this.config.errorTolerance) {
        this.timeStepSec = this.timeStepSec / 2;
        return this.integrateNextState(state);
    }

    if (error < this.config.errorTolerance / 10) {
        this.timeStepSec = Math.min(
            this.timeStepSec * 2,
            this.config.maximumTimeStepSec
        );
    }

    return candidate.nextState;
}

The integrator is not only a performance feature. It is a truth-preservation feature.

A cosmology engine that cannot adapt its time step cannot be trusted near the boundaries where the theory is most likely to fail.

The Memory Problem: Why Normal Arrays Fail

A high-resolution cosmic simulation can generate tens of millions of state records. Storing those records as ordinary JavaScript objects creates enormous memory pressure.

A standard object array like this is easy to write but expensive to run:

const states: CosmicState[] = [];

Every object carries structural overhead. Over millions of iterations, the Node.js or browser runtime can spend more time managing memory than simulating physics.

The engine should use a flattened numeric layout backed by Float64Array.

const valuesPerTick: number = 10;
const maximumTicksPerChunk: number = 1_250_000;
const buffer: ArrayBuffer = new ArrayBuffer(
    valuesPerTick * maximumTicksPerChunk * Float64Array.BYTES_PER_ELEMENT
);

const view: Float64Array = new Float64Array(buffer);

A flattened layout makes every tick predictable:

The simulation can then write directly into memory:

public writeState(index: number, state: CosmicState, photonEnergyDelta: number, error: number): void {
    const offset: number = index * this.valuesPerTick;

    this.view[offset] = state.timeGy;
    this.view[offset + 1] = state.timeStepSec;
    this.view[offset + 2] = state.c_t;
    this.view[offset + 3] = state.G_t;
    this.view[offset + 4] = state.alpha;
    this.view[offset + 5] = state.e_charge;
    this.view[offset + 6] = state.h_bar;
    this.view[offset + 7] = state.massMultiplier;
    this.view[offset + 8] = photonEnergyDelta;
    this.view[offset + 9] = error;
}

This architecture makes the simulation much more suitable for worker threads, disk streaming, and visualization.

Chunked Buffers and Worker Execution

A large simulation should not attempt to allocate one giant contiguous buffer. Instead, the orchestrator should allocate fixed-size chunks.

export interface SimulationChunk {
    chunkIndex: number;
    startTick: number;
    endTick: number;
    buffer: ArrayBuffer;
}

The orchestrator writes to the current chunk until it is full. Then it flushes that chunk to storage, transfers it to a worker, or queues it for visualization.

if (this.currentChunkCursor >= this.maximumTicksPerChunk) {
    this.flushCurrentChunk();
    this.allocateNextChunk();
}

This prevents a long-running simulation from collapsing under its own memory footprint.

For browser-based visualization, the heavy integration loop should run in a Web Worker. The main thread should remain responsive and only receive decimated data or chunk status updates.

worker.postMessage({
    messageType: "START_SIMULATION",
    config: simulationConfig
});

The Visualization Problem

Raw physics data is not automatically useful to a human reader.

A 50-million-point simulation cannot be rendered directly in a normal chart. Even if the chart library accepts the data, the browser will freeze or the plot will become visually meaningless.

The naive solution is averaging. But averaging is dangerous because it destroys spikes, phase transitions, inflection points, and sharp early-universe behavior.

The better approach is Largest-Triangle-Three-Buckets, usually abbreviated as LTTB.

LTTB reduces the number of plotted points while preserving the visual geometry of the signal.

The algorithm preserves the first and last data points, divides the remaining data into buckets, and selects the point that forms the largest triangle area relative to neighboring bucket references.

public downsampleWithLttb(points: DataPoint[], threshold: number): DataPoint[] {
    if (threshold >= points.length || threshold === 0) {
        return points;
    }

    const sampled: DataPoint[] = [];
    sampled.push(points[0]);

    const bucketSize: number = (points.length - 2) / (threshold - 2);
    let selectedIndex: number = 0;

    for (let bucketIndex: number = 0; bucketIndex < threshold - 2; bucketIndex++) {
        const currentBucketStart: number = Math.floor((bucketIndex + 0) * bucketSize) + 1;
        const currentBucketEnd: number = Math.floor((bucketIndex + 1) * bucketSize) + 1;

        const nextBucketStart: number = Math.floor((bucketIndex + 1) * bucketSize) + 1;
        const nextBucketEnd: number = Math.floor((bucketIndex + 2) * bucketSize) + 1;

        const averagePoint: DataPoint = this.calculateAveragePoint(points, nextBucketStart, nextBucketEnd);
        const previousPoint: DataPoint = points[selectedIndex];

        let maximumArea: number = -1;
        let maximumAreaIndex: number = currentBucketStart;

        for (let index: number = currentBucketStart; index < currentBucketEnd; index++) {
            const area: number = this.calculateTriangleArea(previousPoint, points[index], averagePoint);

            if (area > maximumArea) {
                maximumArea = area;
                maximumAreaIndex = index;
            }
        }

        sampled.push(points[maximumAreaIndex]);
        selectedIndex = maximumAreaIndex;
    }

    sampled.push(points[points.length - 1]);

    return sampled;
}

This matters because the visual anomalies are often the point of the simulation. If the graphing layer smooths them away, the visualization becomes misleading.

What the Engine Should Graph

The visualization layer should not only graph one curve. It should expose the model’s internal accounting.

• c_t over cosmic time.
• G_t over cosmic time.
• Mass multiplier over cosmic time.
• Fine-structure constant drift.
• Photon energy decay.
• Redshift versus distance.
• Condensate fraction of tired-light photons.
• Integration error per time step.
• Adaptive time step size over the run.

Each graph should answer a different test question.

The Regression Suite

A speculative physics engine needs a regression suite that is stricter than a normal application test suite. A user interface bug is annoying. A hidden conservation-law bug invalidates the whole simulation.

describe("Dimensionless Stability", () => {
    test("alpha remains stable across the full simulation", () => {
        const maximumDrift: number = result.getMaximumAlphaDrift();
        expect(maximumDrift).toBeLessThan(1e-12);
    });
});

The Editorial Boundary: Engine, Not Proof

This engine should not be described as proof that a static universe, tired light, VSL, or massive photons are correct.

The engine is better described as a structured test environment.

A simulation can show whether a hypothesis is internally coherent under stated assumptions. It does not automatically prove that the hypothesis describes the real universe.

That distinction is important for ArcSecs.

The engine can help sort claims into categories:

• passes internal conservation tests,
• fails internal conservation tests,
• matches selected observations,
• fails selected observations,
• requires unphysical parameters,
• or produces a falsifiable prediction.

That is exactly what TDD Physics is for.

What Makes This an ArcSecs Engine

A normal cosmology simulator usually begins with the accepted metric framework and solves forward from there.

An ArcSecs engine does something different. It treats the assumptions themselves as swappable modules.

const simulationConfig: SimulationConfig = {
    startTimeGy: -15,
    endTimeGy: 0,
    initialTimeStepSec: 31_556_926,
    minimumTimeStepSec: 1,
    maximumTimeStepSec: 31_556_926_000_000,
    vslModel: "ALFONSO_FAUS_FRACTAL",
    tiredLightModel: "PROCA_DISPERSION",
    preserveFineStructureConstant: true,
    enableMassBoom: true,
    enableProcaPhotonMass: true,
    photonMassEv: 1e-18,
    errorTolerance: 1e-9,
    outputSampleLimit: 5000
};

That makes the engine a hypothesis comparison system.

The key ArcSecs rule is:

Do not protect the theory. Protect the tests.

Full Simulation Flow

A single run should follow this pattern:

1. Load the SimulationConfig.
2. Validate that the selected model combination is allowed.
3. Initialize the first CosmicState.
4. Start the RKF45 integration loop.
5. Update covariant constants through ConstantsManager.
6. Update particle mass through ParticleEntity.
7. Update photon attenuation and dispersion through PhotonEntity.
8. Write each accepted step into chunked Float64Array buffers.
9. Flush chunks to storage or a worker pipeline.
10. Downsample selected series using LTTB.
11. Render charts.
12. Run invariant and observational tests.
13. Generate a pass/fail report.

public runSimulation(config: SimulationConfig): SimulationResult {
    this.validator.validate(config);

    let state: CosmicState = this.initializer.createInitialState(config);

    while (state.timeGy < config.endTimeGy) {
        state = this.physicsEngine.integrate(state, config);
        this.bufferWriter.write(state);
        this.testProbe.capture(state);
    }

    const rawResult: RawSimulationResult = this.bufferWriter.complete();
    const charts: ChartSeries[] = this.visualizationGrapher.project(rawResult, config.outputSampleLimit);
    const testReport: TestReport = this.testRunner.run(rawResult);

    return {
        rawResult,
        charts,
        testReport
    };
}

Failure Is a Feature

The most useful result of this engine may be failure.

A failed model tells ArcSecs exactly which assumption broke:

• Did energy fail to conserve?
• Did momentum disappear?
• Did the fine-structure constant drift?
• Did tired light fail to reproduce time-dilation-like behavior?
• Did photon mass exceed observational bounds?
• Did the visualization hide the anomaly?
• Did the integrator skip the critical transition?

That makes the engine more valuable than an argument. It turns speculation into a debugging target.

if (!testReport.passed) {
    return {
        modelStatus: "REJECT_OR_REFACTOR",
        failedAssumptions: testReport.failedTests,
        nextAction: "Narrow the model or define a better mechanism."
    };
}

Conclusion: Make the Cosmology Compile

The ArcSecs speculative cosmology engine is not merely a charting tool. It is a discipline.

It forces static-universe models, tired-light models, variable-speed-of-light models, and covariant-constant models to behave like executable systems. Every assumption must enter through a configuration boundary. Every mutation must pass through a module that owns it. Every step must preserve the ledger. Every graph must preserve the signal. Every theory must define what would break it.

That is the value of TDD Physics.

A speculative cosmology does not earn trust because it is imaginative. It earns trust by surviving the test harness.

In software, a build that fails honestly is better than one that passes by accident. In ArcSecs, the same rule applies to the universe under test.

References and Further Reading

1. R. Gupta, “Testing CCC+TL Cosmology with Observed Baryon Acoustic Oscillation Features,” The Astrophysical Journal, 2024.
   IOPscience article
2. R. Gupta, “JWST early Universe observations and ΛCDM cosmology,” Monthly Notices of the Royal Astronomical Society, 2023.
   Oxford Academic article
3. A. Alfonso-Faus, “Fractal Universe and the Speed of Light: Revision of the Universal Constants,” arXiv, 2009.
   PDF
4. A. Alfonso-Faus, “Cosmology with New Astrophysical Constants,” arXiv, 2008.
   PDF
5. “Runge-Kutta Method,” Oklahoma State University course notes.
   PDF
6. “Runge-Kutta-Fehlberg Method,” CNAM mathematics notes.
   PDF
7. W. H. Press and S. A. Teukolsky, “Adaptive Stepsize Runge-Kutta Integration.”
   PDF
8. MDN Web Docs, “Float64Array.”
   MDN reference
9. Telerik, “Array Buffers in JavaScript.”
   Article
10. “Largest Triangle Three Buckets: Downsampling Time-Series Data Without Losing Signal.”
    Article
11. H. Liu, C. D. Zhang, and Y. J. Liu, “Variations of the Speed of Light with Frequency and Implied Photon Mass,” Chinese Physics Letters.
    Article
12. L.-C. Tu, J. Luo, and G. T. Gillies, “The mass of the photon,” Reports on Progress in Physics.
    PDF
13. “Cosmology-independent Photon Mass Limits from Localized Fast Radio Bursts by using Artificial Neural Networks,” arXiv, 2024.
    arXiv article
14. C. Liu, Z. Dutton, C. H. Behroozi, and L. V. Hau, “Observation of coherent optical information storage in an atomic medium using halted light pulses,” Nature, 2001.
    Nature article
15. M. Fleischhauer and M. D. Lukin, “Dark-State Polaritons in Electromagnetically Induced Transparency,” Physical Review Letters, 2000.
    APS DOI page
16. NASA/IPAC Extragalactic Database, “Cosmic Microwave Background.”
    CMB overview

Editorial Note

This article describes a speculative simulation architecture, not a completed replacement for standard cosmology. Variable speed of light models, tired-light cosmologies, Proca-style massive photon behavior, and static-universe frameworks remain non-mainstream and must be tested against observational constraints. The ArcSecs value is methodological: turn each speculative claim into a typed, testable, executable model with clear invariants, failure modes, and visual outputs.