The Core Problem

Most browser physics engines are built for games. They are excellent at collisions, rigid bodies, constraints, gravity, joints, and real-time interaction. Engines such as Matter.js, Planck.js, and Rapier are useful tools when the universe being simulated is basically Newtonian.

ArcSecs needs something different.

A speculative cosmology engine cannot assume that the speed of light is always constant, that photon mass is always zero inside every branch of the model, that inertia is purely intrinsic, or that redshift must be represented as metric expansion. It must be able to simulate competing cosmological assumptions as testable modules.

The goal is not to make speculation look scientific. The goal is to force speculation into an executable test harness.

That requires a custom TypeScript physics engine designed around TDD Physics: every theoretical branch must define its assumptions, mutate state through controlled modules, preserve conservation laws, expose numerical error, and produce falsifiable output.

Assert.Conserves(Energy);
Assert.Conserves(Momentum);
Assert.Preserves(DimensionlessConstants);
Assert.Exposes(NumericalError);
Assert.Defines(FalsificationCondition);
Assert.DoesNotHideFailureBehindRendering);

Why Standard Physics Engines Are Not Enough

A standard JavaScript or TypeScript physics engine usually assumes a practical game-world model:

• space is a stable background grid,
• mass is an ordinary scalar value,
• time advances in frame-sized steps,
• collisions are local and mechanical,
• gravity is either fixed or simplified,
• the speed of light is irrelevant or treated as a constant,
• and rendering can often tolerate approximation.

A speculative cosmology and advanced propulsion engine has a different burden:

• fundamental constants may vary by model branch,
• mass may covary to preserve energy,
• photon behavior may depend on frequency and mass terms,
• tired light must transfer energy into a defined reservoir,
• relational inertia may depend on a cosmic background shell,
• dark matter may be modeled as a simulated substrate,
• and the engine must run across both microscopic interaction time and cosmological time.

This cannot be a normal rigid-body toy with a few exotic variables attached. The architecture must be designed from the ground up.

The Engine in One Sentence

The ArcSecs TypeScript physics engine is a data-oriented, test-driven, multi-scale simulation framework that separates physical state, numerical integration, collision detection, cosmological constants, photon mechanics, relational inertia, propulsion dynamics, and visualization into isolated modules.

The high-level pipeline is:

1. Load a simulation hypothesis.
2. Initialize cosmic and local state.
3. Update constants through a controlled manager.
4. Update photons, particles, and fields through isolated entity systems.
5. Run adaptive RK4 integration.
6. Resolve collisions and interactions through broad-phase and narrow-phase pipelines.
7. Write state into typed-array buffers.
8. Expose read-only visualization data to the rendering layer.
9. Run the TDD Physics validation matrix.
10. Accept, reject, or refactor the model.

Hypothesis -> Config -> State Buffers -> Physics Systems -> Integrator -> Tests -> Visualization -> Verdict

Data-Oriented Design: Why the Engine Should Not Be Object-Heavy

A simple object-oriented approach is tempting. It is easy to imagine a PhotonEntity class, a ParticleEntity class, a SpacecraftEntity class, and thousands or millions of instances updating themselves.

That design is easy to understand but expensive to run. In JavaScript engines such as V8, millions of objects can create cache misses, hidden-class churn, and garbage collection pressure. A cosmological simulation that runs millions of calculations per frame cannot afford that.

The better design is Data-Oriented Design using Structure of Arrays.

export interface EntityBufferLayout {
    positionX: Float64Array;
    positionY: Float64Array;
    positionZ: Float64Array;
    velocityX: Float64Array;
    velocityY: Float64Array;
    velocityZ: Float64Array;
    mass: Float64Array;
    charge: Float64Array;
    localSpeedOfLight: Float64Array;
    phaseState: Uint8Array;
}

Instead of storing one object per entity, the engine stores one typed array per property. This keeps memory contiguous and makes the simulation loop predictable.

for (let entityIndex: number = 0; entityIndex < entityCount; entityIndex++) {
    positionX[entityIndex] += velocityX[entityIndex] * timeStepSec;
    positionY[entityIndex] += velocityY[entityIndex] * timeStepSec;
    positionZ[entityIndex] += velocityZ[entityIndex] * timeStepSec;
}

That structure matters because ArcSecs is not only rendering objects. It is testing physical ledgers.

Separating Physics from Visualization

Rendering must never control the physics.

A browser frame rate is not a reliable physics clock. A tab can lose focus. A frame can drop. The main thread can pause. A chart can take too long to redraw. If the physics loop depends on rendering speed, numerical drift enters the simulation through the user interface.

The engine should run the physics loop inside a dedicated Web Worker while the main thread handles rendering, charts, controls, and interaction.

const physicsWorker: Worker = new Worker("/js/arcsecs-physics-worker.js");

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

Where supported and secure, SharedArrayBuffer can expose read-only slices of simulation state to the visualization layer.

export interface WorkerSimulationMessage {
    messageType: "START_SIMULATION" | "PAUSE_SIMULATION" | "STOP_SIMULATION";
    simulationConfig: SimulationConfig;
}

The rule is strict:

The visualization layer may observe the universe. It may not mutate the universe.

Multi-Scale Time: Two Clocks, One Engine

A speculative cosmology engine must simulate two radically different time scales.

The first is cosmological time. This governs billion-year changes: tired light decay, variable speed of light curves, covariant constants, and mass scaling.

The second is local interaction time. This governs fast events: photon-electron scattering, collision resolution, spacecraft intake dynamics, Ramscoop vortex compression, and field modulation.

export interface SimulationClockState {
    cosmicTimeGy: number;
    localTimeSec: number;
    localTimeStepSec: number;
    cosmicTimeStepGy: number;
    accumulatedRenderTimeSec: number;
}

One clock answers, “Where are we in cosmic history?” The other answers, “What happens in the next local interaction step?”

Combining these clocks allows the engine to simulate slow cosmological mutation without sacrificing local interaction precision.

Adaptive RK4 Integration

A speculative cosmology engine should not rely on semi-implicit Euler for its core scientific calculations. Euler methods are inexpensive, but they accumulate energy drift and become unreliable in long-running simulations with non-linear state changes.

ArcSecs needs adaptive Runge-Kutta integration. A practical starting point is RK4 with error-control scaffolding that can later evolve toward RKF45.

export interface IntegratorState {
    positionX: number;
    positionY: number;
    positionZ: number;
    velocityX: number;
    velocityY: number;
    velocityZ: number;
    mass: number;
    localSpeedOfLight: number;
}

export interface DerivativeState {
    velocityX: number;
    velocityY: number;
    velocityZ: number;
    accelerationX: number;
    accelerationY: number;
    accelerationZ: number;
    massRate: number;
    speedOfLightRate: number;
}

To avoid allocation pressure, intermediate derivative vectors should be pre-allocated as typed arrays.

const k1: Float64Array = new Float64Array(valuesPerEntity);
const k2: Float64Array = new Float64Array(valuesPerEntity);
const k3: Float64Array = new Float64Array(valuesPerEntity);
const k4: Float64Array = new Float64Array(valuesPerEntity);

The integrator must expose its error behavior. A model that only returns the next position is not enough.

export interface IntegrationResult {
    accepted: boolean;
    estimatedError: number;
    suggestedNextTimeStepSec: number;
}

Collision Detection at Cosmological and Propulsion Scale

Even a cosmological engine needs collisions. The Dark Matter Drive branch requires substrate harvesting, particle-field interactions, intake flow modeling, and high-density compression inside the Ramscoop vortex.

The collision system should be split into broad-phase and narrow-phase passes.

Broad Phase

The broad phase eliminates pairs that cannot possibly collide. A dynamic bounding volume hierarchy is useful for sparse entities across large space. A spatial hash is useful in dense regions such as the compressed intake stream.

export interface BroadPhaseCandidate {
    firstEntityIndex: number;
    secondEntityIndex: number;
}

Narrow Phase

The narrow phase determines whether a collision actually occurs and extracts contact data.

• SAT handles 2D convex projections and cross sections.
• GJK detects 3D convex intersections.
• EPA extracts penetration depth and contact normal after GJK confirms intersection.

export interface ContactManifold {
    firstEntityIndex: number;
    secondEntityIndex: number;
    normalX: number;
    normalY: number;
    normalZ: number;
    penetrationDepth: number;
    contactPointX: number;
    contactPointY: number;
    contactPointZ: number;
}

This matters because a propulsion simulation cannot simply “collect fuel.” It must account for contact, drag, momentum transfer, and energy deposition.

The ConstantsManager: Controlled Mutation of Nature

In a normal physics engine, constants are constants. In an ArcSecs engine, some constants may be model-dependent functions of cosmic time.

That mutation cannot be scattered across the codebase. It belongs in one controlled module.

export type VariableSpeedOfLightModel =
    | "NONE"
    | "PIPINO_EXPONENTIAL"
    | "ALFONSO_FAUS_INVERSE_TIME"
    | "CUSTOM";

export interface ConstantsState {
    speedOfLight: number;
    gravitationalConstant: number;
    fineStructureConstant: number;
    elementaryCharge: number;
    reducedPlanckConstant: number;
    massMultiplier: number;
}

The ConstantsManager is responsible for calculating the physical constants at a given cosmic time.

export interface ConstantsManager {
    calculateConstants(cosmicTimeGy: number, config: SimulationConfig): ConstantsState;
}

The engine should not allow arbitrary systems to rewrite speedOfLight, massMultiplier, or fineStructureConstant. All changes must pass through the manager so they can be tested.

Variable Speed of Light Branch

The Variable Speed of Light branch allows the engine to test static-universe redshift alternatives without metric expansion.

In a Pipino-style exponential model, c decays as a function of cosmological time. In an Alfonso-Faus-style inverse-time model, c decreases according to a different curve.

export function calculateSpeedOfLight(
    cosmicTimeGy: number,
    model: VariableSpeedOfLightModel
): number {
    if (model === "NONE") {
        return PhysicalConstants.SpeedOfLightNow;
    }

    if (model === "PIPINO_EXPONENTIAL") {
        return calculatePipinoExponentialSpeedOfLight(cosmicTimeGy);
    }

    if (model === "ALFONSO_FAUS_INVERSE_TIME") {
        return calculateAlfonsoFausSpeedOfLight(cosmicTimeGy);
    }

    return calculateCustomSpeedOfLight(cosmicTimeGy);
}

The important editorial boundary is that this is not standard cosmology. It is a branch under test.

Assert.True(SpeedOfLightModelIsDeclared);
Assert.True(RedshiftMechanismIsExplicit);
Assert.True(ModelCanBeComparedAgainstObservation);

Covariant Mass Scaling

Changing the speed of light creates an immediate energy-accounting problem. If E = mc², then changing c without changing anything else can destroy rest-energy accounting.

The engine handles this with a covariant mass branch. In this branch, the particle system can scale mass to preserve the rest-energy ledger.

export function calculateMassMultiplier(currentSpeedOfLight: number): number {
    const presentSpeedOfLight: number = PhysicalConstants.SpeedOfLightNow;
    const speedRatio: number = presentSpeedOfLight / currentSpeedOfLight;

    return speedRatio * speedRatio;
}

This is not hidden. The mass multiplier is part of the state and must be graphed, tested, and reported.

Assert.True(Number.isFinite(massMultiplier));
Assert.True(massMultiplier > 0);
Assert.LessThan(Math.abs(restEnergyDelta), allowedEnergyTolerance);

Preserving the Fine-Structure Constant

The fine-structure constant is dimensionless. If it drifts carelessly in a speculative simulation, the model risks destroying atomic stability while pretending the universe is still recognizable.

The engine must enforce dimensionless stability when configured to do so.

export function calculateFineStructureConstant(
    elementaryCharge: number,
    reducedPlanckConstant: number,
    speedOfLight: number
): number {
    const denominator: number =
        4 * Math.PI *
        PhysicalConstants.VacuumPermittivity *
        reducedPlanckConstant *
        speedOfLight;

    return (elementaryCharge * elementaryCharge) / denominator;
}

Assert.LessThan(
    Math.abs(currentAlpha - PhysicalConstants.FineStructureConstant),
    allowedAlphaDrift
);

The rule is simple:

Dimensional constants may be branch variables. Dimensionless constants must be protected unless the model explicitly declares otherwise.

Tired Light as an Energy-Attenuation System

Tired light should not be represented as a vague visual fading effect. It must be an energy attenuation system.

The engine should support at least two branches:

• Continuous attenuation: smooth exponential decay over distance or travel time.
• Discrete scattering: probabilistic interactions with free electrons or intergalactic plasma.

export type TiredLightModel =
    | "NONE"
    | "CONTINUOUS_ATTENUATION"
    | "FREE_ELECTRON_COMPTON_SCATTERING";

export interface PhotonState {
    emittedEnergyJ: number;
    currentEnergyJ: number;
    emittedFrequencyHz: number;
    currentFrequencyHz: number;
    distanceTraveledM: number;
    redshift: number;
    phaseState: PhotonPhaseState;
}

The ledger question is non-negotiable:

Assert.True(photon.currentEnergyJ <= photon.emittedEnergyJ);
Assert.NotNull(energyReservoir);
Assert.LessThan(
    Math.abs(photon.emittedEnergyJ - photon.currentEnergyJ - energyReservoir.deltaEnergyJ),
    allowedEnergyTolerance
);

Proca Electrodynamics Branch

The Proca branch models photon-like entities with a tiny nonzero mass. In standard physics, ordinary photons are treated as massless, and photon mass is tightly constrained. The engine must label this as a speculative branch and force it through testable constraints.

export interface ProcaPhotonState {
    photonMassKg: number;
    frequencyHz: number;
    groupVelocity: number;
    phaseVelocity: number;
    massEnergyJ: number;
}

The group velocity becomes frequency-dependent. High-frequency photons remain close to the present-day speed of light. Low-frequency tired photons experience stronger dispersion and slow down.

export function calculateProcaGroupVelocity(
    frequencyHz: number,
    photonMassKg: number,
    speedOfLight: number
): number {
    const angularFrequency: number = 2 * Math.PI * frequencyHz;
    const massTerm: number =
        (photonMassKg * speedOfLight * speedOfLight) /
        PhysicalConstants.ReducedPlanckConstant;

    const ratio: number = massTerm / angularFrequency;
    const velocityFactor: number = Math.sqrt(Math.max(0, 1 - ratio * ratio));

    return speedOfLight * velocityFactor;
}

The branch must pass a basic dispersion test:

Assert.True(highFrequencyPhoton.groupVelocity > lowFrequencyPhoton.groupVelocity);

Relational Mechanics and Machian Inertia

The propulsion branch requires a non-standard interpretation of inertia. Instead of treating inertia as purely intrinsic, the engine can test a relational model where inertial resistance emerges from interaction with the surrounding mass distribution.

Directly calculating interactions with every body in the simulated universe would be computationally impossible. The engine therefore uses a cosmic background shell approximation.

export interface RelationalInertiaState {
    localMassDensity: number;
    farFieldMassDensity: number;
    cosmicShellCoupling: number;
    inertialResistanceMultiplier: number;
}

export function calculateInertialResistance(
    localMassDensity: number,
    farFieldMassDensity: number,
    cosmicShellCoupling: number
): number {
    return 1 + cosmicShellCoupling * (localMassDensity + farFieldMassDensity);
}

In dense regions, inertial resistance is high. In deep voids, the model can simulate reduced resistance, making voids favorable transit corridors in the Dark Matter Drive branch.

Again, this is not treated as established fact. It is a branch under test.

Dark Matter as a Tired-Photon Freeze-Out State

In the ArcSecs propulsion branch, dark matter is not modeled as WIMPs, axions, or sterile neutrinos. It is modeled as a speculative tired-photon substrate.

The simulation treats active photons as entities that can lose energy, slow through Proca dispersion, cross a threshold, and transition into a cold, low-kinetic, gravitationally relevant state.

export type PhotonPhaseState =
    | "ACTIVE_LIGHT"
    | "REDSHIFTED_LIGHT"
    | "LOW_ENERGY_PROCA_PHOTON"
    | "TIRED_LIGHT_CONDENSATE"
    | "DARK_MATTER_SUBSTRATE";

export function updatePhotonPhaseState(photon: PhotonState): PhotonPhaseState {
    if (photon.currentEnergyJ <= SimulationThresholds.DarkMatterSubstrateEnergyJ) {
        return "DARK_MATTER_SUBSTRATE";
    }

    if (photon.currentEnergyJ <= SimulationThresholds.TiredLightCondensateEnergyJ) {
        return "TIRED_LIGHT_CONDENSATE";
    }

    if (photon.currentEnergyJ <= SimulationThresholds.LowEnergyProcaPhotonEnergyJ) {
        return "LOW_ENERGY_PROCA_PHOTON";
    }

    if (photon.redshift > 0) {
        return "REDSHIFTED_LIGHT";
    }

    return "ACTIVE_LIGHT";
}

The state machine is important. It turns vague tired-light language into a testable simulation transition.

Macroscopic EIT and the Ramscoop Vortex

The Dark Matter Drive simulation branch requires the spacecraft to harvest a sparse substrate. The proposed mechanism is a macroscopic EIT-style scoop field that changes local refractive behavior, slows the substrate, compresses it, and guides it into an intake stream.

export interface RamscoopState {
    scoopRadiusM: number;
    intakeRadiusM: number;
    compressionRatio: number;
    capturedSubstrateMassKg: number;
    vortexStability: number;
}

The conceptual sequence is:

1. Project a forward EIT scoop field.
2. Detect tired-light substrate within the collection volume.
3. Reduce the group velocity of the substrate.
4. Compress the substrate into a Ramscoop vortex.
5. Guide the compressed stream into the intake throat.
6. Pass the stream to the propulsion and reactor modules.

const capturedMassKg: number = calculateCapturedSubstrateMass(
    substrateDensityKgPerCubicMeter,
    scoopVolumeCubicMeters,
    captureEfficiency
);

const compressionRatio: number = scoopRadiusM / intakeRadiusM;

This is a speculative extrapolation from real quantum optics concepts. The engine’s job is not to assume it works. The engine’s job is to make the assumptions explicit enough to fail.

Stationary Light and Dark-State Polaritons

A stopped-light model must not destroy energy. If light is slowed or halted, its energy and momentum must be mapped into a reservoir.

The engine can represent this with a coupled light-matter state.

export interface DarkStatePolaritonState {
    electromagneticFraction: number;
    matterCoherenceFraction: number;
    storedEnergyJ: number;
    storedMomentumKgMeterPerSecond: number;
}

The conservation test is mandatory:

Assert.LessThan(
    Math.abs(
        incomingPhotonEnergyJ -
        polariton.storedEnergyJ -
        residualPhotonEnergyJ
    ),
    allowedEnergyTolerance
);

The key ArcSecs rule is:

“Stopped light” is not a magic state. It is a ledger requirement.

The TDD Physics Matrix

Because this engine crosses ordinary physics, speculative cosmology, numerical methods, and advanced propulsion concepts, normal unit tests are not enough. The engine needs a TDD Physics matrix.

Example Test Structure

The engine should include ordinary software tests and physics-invariant tests. A simplified Jest-style example:

describe("Dimensionless Stability", () => {
    test("fine structure constant remains stable during VSL simulation", () => {
        const config: SimulationConfig = createVslSimulationConfig();
        const result: SimulationResult = runSimulation(config);

        const maximumAlphaDrift: number = result.diagnostics.maximumAlphaDrift;

        expect(maximumAlphaDrift).toBeLessThan(1e-12);
    });
});

describe("Proca Frequency Drag", () => {
    test("high frequency photon outruns low frequency photon", () => {
        const photonMassKg: number = 1e-54;

        const highFrequencyVelocity: number = calculateProcaGroupVelocity(
            1e18,
            photonMassKg,
            PhysicalConstants.SpeedOfLightNow
        );

        const lowFrequencyVelocity: number = calculateProcaGroupVelocity(
            1e6,
            photonMassKg,
            PhysicalConstants.SpeedOfLightNow
        );

        expect(highFrequencyVelocity).toBeGreaterThan(lowFrequencyVelocity);
    });
});

These tests make the model accountable. They do not prove the model is true. They prove whether the engine is honestly implementing the branch it claims to test.

Visualization Layer

The visualization layer should show the physical ledger, not just pretty particles.

Useful graph outputs include:

• speed of light over cosmic time,
• mass multiplier over cosmic time,
• fine-structure constant drift,
• photon energy attenuation,
• Proca group velocity by frequency,
• tired-light condensate fraction,
• Ramscoop capture efficiency,
• vortex stability,
• simulation integration error,
• and pass/fail status for every TDD Physics test.

The rendering layer can use WebGL or Three.js for spatial visualization, but the diagnostic charts are just as important as the visual scene. A dramatic simulation without a ledger is not ArcSecs.

Why TypeScript Is a Good Fit

TypeScript is not the fastest possible language for scientific computing, but it has strong advantages for this particular ArcSecs use case:

• It runs directly in the browser.
• It supports strict interfaces for simulation state.
• It works with typed arrays and Web Workers.
• It can power interactive visualizations without a separate desktop application.
• It makes speculative models easier to publish, inspect, and share.

The key is to avoid writing TypeScript like a small object-heavy UI app. The engine should use explicit interfaces, typed buffers, isolated systems, and deterministic tests.

Engineering Rules

The engine should follow these rules:

• No physics mutation inside rendering code.
• No hidden energy loss.
• No hidden momentum loss.
• No untracked changes to fundamental constants.
• No object-heavy inner loops.
• No frame-rate-driven physics.
• No speculative branch without a test suite.
• No visualization that smooths away the failure signal.

In short:

Engine the hypothesis. Test the ledger.

Editorial Boundary

This article describes a simulation architecture for speculative physics. It does not claim that tired light, variable speed of light cosmology, Proca ordinary photons, relational inertia, or dark matter drive propulsion are established scientific conclusions.

The value is methodological. A custom engine can convert speculative ideas into modules, state transitions, tests, graphs, failure modes, and falsification targets.

That is the difference between an idea and an ArcSecs test branch.

Conclusion: Build the Engine That Can Prove You Wrong

A TypeScript physics engine for ArcSecs should not be designed to protect a theory. It should be designed to expose weak assumptions.

If tired light loses energy, the engine must track where it goes. If the speed of light varies, the engine must protect thermodynamic and dimensionless invariants. If photons carry mass in a branch, the engine must expose frequency-dependent behavior and compare it against constraints. If a spacecraft harvests dark matter, the engine must account for intake momentum, compression, reactor energy, and exhaust thrust.

The result is not merely a simulation. It is a truth machine for speculative models.

In ArcSecs, a model earns trust only when the ledger closes.

References and Further Reading

1. GitHub Topics, “physics-engine” TypeScript repositories.
   GitHub topic page
2. Matter.js, JavaScript 2D rigid body physics engine.
   Matter.js website
3. Planck.js, JavaScript rewrite of Box2D.
   Planck.js website
4. Rapier, fast 2D and 3D physics engine with JavaScript support through WebAssembly.
   Rapier website
5. MDN Web Docs, “Float64Array.”
   MDN reference
6. MDN Web Docs, “Web Workers API.”
   MDN reference
7. MDN Web Docs, “SharedArrayBuffer.”
   MDN reference
8. IBM Developer, “Build a simple 2D physics engine for JavaScript games.”
   IBM Developer tutorial
9. Gino van den Bergen, “A Fast and Robust GJK Implementation for Collision Detection of Convex Objects.”
   PDF
10. dyn4j, “EPA: Expanding Polytope Algorithm.”
    Article
11. dyn4j, “GJK: Gilbert-Johnson-Keerthi.”
    Article
12. Giuseppe Pipino, “Variable Speed of Light with Time and General Relativity.”
    SCIRP article
13. Alfonso-Faus, “Fractal Universe and the Speed of Light: Revision of the Universal Constants.”
    arXiv PDF
14. Rajendra Gupta, “Testing CCC+TL Cosmology with Observed Baryon Acoustic Oscillation Features.”
    The Astrophysical Journal article
15. Dark Energy Survey Supernova Program, “Slow supernovae show cosmological time dilation out to z ~ 1.”
    Monthly Notices of the Royal Astronomical Society article
16. L.-C. Tu, J. Luo, and G. T. Gillies, “The mass of the photon.”
    Reports on Progress in Physics article
17. A. S. Goldhaber and M. M. Nieto, “Photon and Graviton Mass Limits.”
    Reviews of Modern Physics article
18. A. Proca, “Sur la théorie ondulatoire des électrons positifs et négatifs.”
    OSTI record
19. H. Ruegg and M. Ruiz-Altaba, “The Stueckelberg field.”
    arXiv record
20. 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 article
21. M. Fleischhauer and M. D. Lukin, “Dark-State Polaritons in Electromagnetically Induced Transparency.”
    Physical Review Letters article
22. M. Bajcsy, A. S. Zibrov, and M. D. Lukin, “Stationary pulses of light in an atomic medium.”
    Nature article
23. André Koch Torres Assis, “Axioms for Mach’s Mechanics.”
    arXiv PDF
24. André Koch Torres Assis, Relational Mechanics.
    ResearchGate record

Editorial Note

This post describes a speculative simulation architecture for ArcSecs and TDD Physics. It does not present tired light, variable speed of light cosmology, Proca ordinary photons, relational inertia, or dark matter drive propulsion as established scientific conclusions. The purpose is to define a testable computational framework where speculative claims can be implemented, measured, falsified, refined, or rejected.