1. Executive Summary

BOL (Beginning of Life) is a computational research platform that simulates the chemical and physical processes hypothesised to have driven the emergence of life on early Earth, approximately 3.8–4.1 billion years ago. The simulator operates as a self-contained Python application with a web-based dashboard, providing researchers and students with an interactive laboratory for exploring origin-of-life chemistry.

The platform models a three-dimensional hydrothermal environment where simple inorganic molecules (CO₂, H₂, NH₃, H₂S) undergo 27 abiotic reaction pathways to produce increasingly complex organic molecules—amino acids, nucleotides, sugars, and lipids. These building blocks spontaneously self-assemble into membrane-bound vesicles (protocells), within which RNA templates replicate with error-prone fidelity, driving Darwinian selection at the molecular level.

Key capabilities include:

• 27 prebiotic reactions spanning C1 fixation, formose chemistry, nitrogen chemistry, polymerisation, and photochemistry—each with thermodynamic gating and environmental modifiers.
• Four origin-of-life scenarios: Alkaline Hydrothermal Vent, Iron-Sulfur World, RNA World, and Warm Little Pond—configurable via JSON scenario files.
• Emergent self-assembly: amphiphilic molecules spontaneously form micelles that promote to vesicles, grow via lipid accretion, and divide with content inheritance.
• Template-directed replication on mineral surfaces and inside vesicles with point mutations, insertions, deletions, segment duplications, and recombination.
• 27 deterministic analysis functions across 8 scientific modules covering pathway analysis, autocatalytic set detection, membrane dynamics, and fitness landscapes.
• 50 REST API endpoints powering a real-time web dashboard with Chart.js time-series, Three.js 3D visualisation, and an 8-category training curriculum.

The system is designed for portability (pure Python + NumPy), security (PBKDF2 authentication, CSP headers, rate limiting), and scientific transparency (all reactions grounded in published literature).

2. Scientific Foundations

2.1 The Origin-of-Life Problem

The origin of life remains one of the deepest unsolved problems in science. The transition from geochemistry to biochemistry required the emergence of three capabilities that define all known life: (1) metabolism—the ability to harvest energy and catalyse chemical reactions; (2) compartmentalisation—membrane boundaries that create distinct chemical environments; and (3) replication—the capacity to copy information with heritable variation.

BOL models all three pillars simultaneously in a unified simulation, allowing researchers to observe whether and how they emerge from simple starting conditions.

2.2 Four Leading Hypotheses

The simulator supports four prebiotic scenarios, each representing a major scientific hypothesis. No single hypothesis is privileged; users select the starting conditions and observe the outcomes.

2.3 Computational Approach

BOL adopts a coarse-grained stochastic particle approach, intermediate between molecular dynamics (which tracks individual atoms) and systems-biology ODE models (which track concentrations). Each molecule is an object with aggregate physicochemical properties—type, mass, charge, hydrophobicity, sequence—moving through a continuous 3D volume. Reactions fire probabilistically based on proximity, thermodynamic feasibility, and local environmental conditions.

This design choice makes the simulation tractable (thousands of molecules in real time) while preserving spatial realism (concentration gradients, compartmentalisation, surface catalysis). Emergent behaviours—self-assembly, autocatalytic cycles, heritable selection—arise from the rules rather than being programmed explicitly.

3. System Architecture

3.1 Module Map

The application is organised into 11 Python modules plus a web layer. Module dependencies flow downward; no circular imports exist.

3.2 Simulation Step Pipeline

Each simulation tick executes a strict 7-phase pipeline. The ordering is critical: feedstock must be injected before chemistry can consume it; assembly must run after chemistry so that new products are available for encapsulation; replication runs last because it operates on assembled structures.

3.3 Threading & Concurrency Model

The simulation runs in a background thread while the Flask web server handles HTTP requests on the main thread. Three threading locks protect shared state:

• _sim_lock — guards all simulation object access (molecules, vesicles, metrics)
• _project_lock — guards project JSON file I/O
• _bug_lock — guards bug tracker JSON file I/O

API endpoints acquire the simulation lock for read access, ensuring consistent snapshots are returned to the browser. The simulation thread acquires the lock at step boundaries to prevent mid-step reads.

3.4 Deployment Topology

4. The 3D World Model

The simulation world is a continuous three-dimensional volume (default 20×20×20 units) representing a cross-section of a hydrothermal vent environment. The vertical axis (Y) maps to depth: Y=0 is the vent floor (hot, alkaline, mineral-rich) and Y=20 is the ocean surface (cold, neutral, mineral-poor).

4.1 Spatial Hashing

Efficient neighbour lookups are critical for reaction sampling. BOL uses a uniform spatial hash grid with cell size equal to the reaction radius (default 3.0 units). Each molecule is assigned to a cell based on its position, and neighbour queries return all particles in the same cell plus the 26 surrounding cells (3×3×3 neighbourhood).

The hash grid is rebuilt from scratch at the start of each chemistry step via World.clear() and World.insert(id, pos). This approach is simpler and more cache-friendly than incremental updates, given that all molecules move each tick.

4.2 Environmental Gradients

Three spatially varying fields are pre-computed on a coarse 10×10×10 grid and queried via trilinear index lookup:

4.3 Periodic Boundary Conditions

Horizontal boundaries (X, Z) use periodic wrapping: molecules exiting the right edge reappear on the left. This simulates an effectively infinite ocean floor without edge effects. Vertical boundaries (Y) are also periodic but are coupled with ocean loss at the top to simulate dilution into the open ocean.

5. Energy System

The EnergySystem module models four geologically plausible energy sources available on early Earth. Energy availability is spatially localised: thermal energy is strongest near the vent, UV penetrates only the top 25% of the water column, and lightning strikes are rare stochastic events. The total energy available at any position is queried during reaction evaluation to determine whether endergonic reactions can proceed.

5.1 Thermal Gradients

Thermal energy is derived from the temperature field. Higher temperatures near the vent floor provide continuous energy for mineral-surface catalysis.

At a vent temperature of 400 K, thermal energy ≈ 0.67. At ambient ocean temperature (275 K), thermal energy is zero. This models the thermodynamic reality that vent-associated reactions benefit from elevated temperatures.

5.2 Redox Chemistry

Redox energy is proportional to local mineral density, modelling the electron transfer capacity of iron-sulfide (FeS) and pyrite (FeS₂) surfaces near the vent.

Maximum redox energy of 0.5 occurs at the vent floor; it drops to zero above the mineral-bearing zone.

5.3 UV Radiation

Ultraviolet radiation follows Beer–Lambert attenuation from the ocean surface. UV provides energy for photochemical reactions (water photolysis, HCN polymerisation) but only penetrates the top fraction of the water column.

Where penetration_depth = world_height × uv_depth_frac (default 25%). UV energy is zero below 3× the penetration depth. This must be explicitly enabled in the scenario configuration (uv_radiation: true), as it is not present in deep-sea vent scenarios.

5.4 Lightning Discharge

Lightning strikes are modelled as rare stochastic events with spatial and temporal extent:

• Probability: 2% chance per step of a new strike (configurable)
• Location: random position in the top 15% of the world (near surface)
• Blast radius: 25% of world width
• Duration: 3 simulation steps with linear decay

Lightning provides high-energy input for Miller–Urey type reactions (amino acid synthesis from CH₄ + NH₃) and HCN synthesis from N₂ + CH₄. The brief, intense energy bursts model the atmospheric electrical discharges hypothesised by Miller and Urey (1953) as a driver of prebiotic synthesis.

6. Prebiotic Chemistry Engine

The chemistry engine is the heart of BOL. It implements 27 abiotic reaction rules operating on 26 molecular species, with reaction probabilities governed by thermodynamics, local environment, and catalytic context. The engine uses encounter-based stochastic sampling rather than concentration-based kinetics, preserving spatial resolution.

6.1 Molecular Species Catalogue

BOL tracks 26 distinct molecule types, ranging from simple inorganic gases to complex biopolymers. Each type is defined by a template specifying mass, charge, hydrophobicity, and amphiphilicity.

6.2 The 27 Reaction Rules

Each reaction is defined by a ReactionRule specifying reactants, products, thermodynamic barrier (ΔG in kJ/mol), base rate, and environmental requirements. Reactions are grouped into seven categories reflecting the major synthetic pathways of prebiotic chemistry.

C1 Fixation & Small Molecules

Formose & Sugar Chemistry

Nitrogen & HCN Chemistry

Metabolic Intermediates

Macromolecule Assembly

Lipid & Membrane Chemistry

Photochemistry & Discharge Reactions

6.3 Reaction Algorithm

The chemistry step follows an encounter-based sampling approach rather than deterministic mass-action kinetics. This preserves spatial locality—only molecules that are physically near each other can react.

Encounter Sampling

1. Build spatial hash — Insert all alive molecules into the grid.
2. Compute encounter budget — max_encounters = min(n_reactive × 5, 5000).
3. For each encounter:
   1. Select a random alive, reactive molecule m1.
   2. Pick a random neighbouring cell from the 27-cell neighbourhood.
   3. Pick a random molecule m2 from that cell.
   4. Check the pre-computed _type_partners dictionary to see if any reaction exists for the pair (m1.type, m2.type).
   5. Verify distance ≤ reaction_radius.
   6. For 2-body reactions: attempt _evaluate_and_fire(rule, [m1, m2]).
   7. For 3-body reactions: search m2’s neighbours for a matching third reactant.

6.4 Rate Computation

When a candidate reaction pair is identified, the effective reaction rate is computed by multiplying the base rate with a series of environmental and catalytic modifiers:

Where each factor is computed as follows:

The final rate is hard-capped at 0.95 to prevent deterministic firing. A uniform random number is drawn; if random() < rate, the reaction fires: reactants are consumed (marked dead) and products are created at the reaction centre.

6.5 Thermodynamic Gating

Reactions with positive ΔG (endergonic) require energy coupling. The algorithm computes a driving force from the available energy sources and compares it against the thermodynamic difficulty:

If coupling ≤ 0, the reaction is rejected regardless of other factors. The weighted coefficients reflect the relative thermodynamic potency of each energy source: lightning and UV provide the most concentrated energy, while thermal gradients provide the weakest per-event drive.

6.6 Polymer Sequence Construction

When polymerisation reactions fire, sequence strings are constructed:

• Peptide bond (reaction 13) — two amino acid sequences are concatenated. Initial amino acids carry a random single letter from GAVLIPFMWSTYQNDEKHRC (20 standard amino acids).
• Peptide elongation (reaction 14) — the existing peptide sequence is extended by one random amino acid letter.
• RNA polymerisation (reaction 15) — two nucleotide bases are joined. Each nucleotide carries a random base from AUGC.
• RNA elongation (reaction 16) — the existing RNA sequence gains one random base.

RNA strands gain catalytic status when their sequence meets two criteria: (1) length ≥ catalytic_threshold (default 8) and (2) the sequence contains a ribozyme motif from the set {GUC, GAA, CCA, GCCA, GUCC, GAAC}. These motifs are loosely inspired by real ribozyme active sites (hammerhead, HDV, hairpin ribozymes).

7. Self-Assembly Engine

The AssemblyEngine models the spontaneous organisation of amphiphilic molecules into membrane-bound compartments. This process follows a lifecycle: free amphiphiles cluster into micelles, which grow and promote to vesicles (closed bilayer shells), which then undergo fitness-driven growth and division. Vesicles that lose too many lipids dissolve.

7.1 Micelle Formation

Free-floating amphiphilic molecules (fatty acids and lipids) that are not already part of any structure are clustered using a proximity-based algorithm:

1. Identify all free amphiphiles (not in micelles or vesicles).
2. For each amphiphile, find all other free amphiphiles within reaction_radius × 3 units.
3. If the cluster size reaches the critical micelle concentration (default micelle_threshold = 8 lipids), form a new Micelle object.
4. The micelle centre is the geometric mean of its member positions.

7.2 Vesicle Promotion

Micelles that accumulate enough amphiphilic molecules are promoted to vesicles—closed bilayer shells that can encapsulate molecules:

• When a micelle reaches vesicle_threshold (default 15) lipids, it is promoted to a Vesicle.
• The vesicle inherits the micelle’s position and membrane molecules.
• Non-amphiphilic molecules within a radius of the new vesicle are encapsulated as initial contents.
• The vesicle starts with generation 0, fitness 0.0, and age 0.

7.3 Membrane Permeability

Vesicle membranes are selectively permeable, following a three-tier model:

This permeability model ensures that polymers and information molecules are retained inside vesicles once synthesised, while small feedstock molecules can enter to fuel internal chemistry.

7.4 Fitness Scoring

Each vesicle receives a fitness score based on the functional molecules it contains. This score drives differential growth (fitter vesicles grow faster via osmotic influx and lipid accretion).

Total fitness is capped at 2.0. Vesicles with catalytic RNA strands enjoy the strongest fitness advantage, reflecting the RNA World hypothesis that ribozymes were the primary drivers of early protocell fitness.

7.5 Osmotic Growth & Lipid Accretion

Fitter vesicles grow preferentially through two mechanisms:

Osmotic Growth

Small permeable molecules within a fitness-modulated attraction radius are absorbed into the vesicle. Higher fitness increases the effective absorption radius, modelling the biophysical reality that metabolically active protocells create local concentration gradients.

Lipid Accretion

Free-floating amphiphilic molecules within an attraction zone are recruited to the vesicle membrane:

This creates a positive feedback loop: fitter vesicles attract more lipids, growing larger, which provides more surface area for lipid accretion. This models the osmotic coupling between internal activity and membrane growth observed in synthetic protocell experiments (Szostak lab, 2004–2014).

7.6 Vesicle Division

Vesicles whose membrane lipid count exceeds division_size (default 50) undergo binary fission:

1. Membrane lipids are randomly shuffled and split 50/50 into two daughters.
2. Enclosed contents are randomly partitioned (each molecule has 50% chance to go to either daughter).
3. Daughters are offset by a random vector × 2.0 units from the parent centre.
4. Each daughter inherits generation = parent.generation + 1 and parent_id = parent.id.
5. The parent vesicle is removed.

This division mechanism produces lineages (multi-generational chains) that can be tracked through the lineage viewer. Combined with differential fitness, this creates a minimal Darwinian selection system: fitter protocells grow faster, divide sooner, and propagate their contents to daughters.

7.7 Dissolution

Vesicles that lose membrane lipids below micelle_threshold / 2 (default 4) dissolve: all contents are released as free molecules and the vesicle is removed from the simulation. This models the thermodynamic instability of undersized bilayer structures.

8. Replication Engine

The ReplicationEngine models template-directed synthesis of RNA strands—the process by which information molecules make copies of themselves. Two distinct copying environments are modelled, reflecting different experimental and theoretical proposals.

8.1 Mineral-Surface Template Copying

Inspired by the Ferris (1996) and Orgel (2004) experiments on montmorillonite-catalysed RNA polymerisation, this mode operates on free-floating RNA strands near mineral-rich surfaces:

• Eligibility: RNA strand must be free (not in a vesicle) and at a position with mineral density ≥ 0.1.
• Nucleotide requirement: At least len(sequence) free nucleotides must be within reaction_radius of the template.
• Rate: 0.03 × mineral_density / max(1, needed/4)—longer templates copy more slowly, reflecting the difficulty of long-range template-directed synthesis.
• Products: Watson–Crick complement (A↔U, G↔C) with error-prone copying (Section 8.3). Product positioned ±0.3 units from template.

8.2 Vesicle-Interior Copying

RNA templates inside vesicles can replicate using encapsulated nucleotides. This mode is faster because the confined volume concentrates reactants:

• Rate (with ribozyme catalyst): 0.05 per step
• Rate (without catalyst): 0.02 per step
• Recombination: 8% chance of single-point crossover with another RNA strand in the same vesicle (see Section 8.4).
• Inheritance: Products inherit the parent’s vesicle_id, remaining inside the protocell.

8.3 Error Model

Template copying is error-prone, generating heritable variation that drives selection. Four types of errors are modelled, each with probability derived from the base error rate (default 0.02):

8.4 Recombination

When two RNA strands coexist inside the same vesicle, there is an 8% chance of single-point crossover during replication:

The crossover point is chosen uniformly at random along the shorter sequence. Recombination allows beneficial motifs from different strands to combine, accelerating the exploration of functional sequence space—analogous to sexual recombination in modern organisms.

9. Simulation Orchestrator

The Simulation class in simulation.py coordinates all subsystems. It initialises the world, populates it with starting molecules according to the scenario configuration, and runs the step pipeline in a loop.

9.1 Feedstock Injection

At each step, new molecules representing vent gases are injected into the bottom 15% of the world, modelling continuous geochemical input from a hydrothermal vent:

Rates are multiplied by the feedstock_rate configuration parameter (default 1.0). Fractional molecules are handled by probabilistic rounding: for rate 1.5, there is a 50% chance of spawning 1 or 2 molecules per step.

9.2 Brownian Diffusion

All molecules undergo temperature-dependent Brownian motion, fully vectorised for performance:

Where noise is drawn from a standard normal distribution. Heavier molecules diffuse more slowly (inversely proportional to mass). Higher temperatures increase diffusion, naturally concentrating fast-moving light molecules near the hot vent while heavy polymers settle. All positions are wrapped periodically after displacement.

9.3 Ocean Loss

Molecules in the top 20% of the world height (above 80% of Y) have a per-step probability of ocean_loss_frac (default 5%) of being removed from the simulation. This models dilution of molecules into the open ocean—a sink that balances the feedstock source and prevents unbounded population growth.

9.4 Garbage Collection

Every 100 steps, dead molecules (consumed by reactions or ocean loss) are purged from the molecule list to free memory and maintain iteration performance. Python’s garbage collector handles the underlying memory reclamation.

10. Metrics & Complexity Scoring

10.1 Per-Step Metrics

The Metrics module records 24 measurements at every simulation step, providing a comprehensive time-series view of emergent dynamics:

10.2 The Complexity Score

The complexity score is a weighted composite metric (0–100) that quantifies how far the simulation has progressed toward life-like organisation. It captures seven dimensions of emergent complexity:

A score of 100 represents optimal simultaneous performance across all seven dimensions—a state rarely achieved, since it requires sustained polymer synthesis, vesicle populations with multi-generational fitness selection, active ribozyme catalysis, and high-fidelity replication all operating concurrently.

10.3 Export Formats

Simulation results can be exported in three formats:

• CSV — one row per step, all 24 metrics as columns. Human-readable and importable into spreadsheet or statistics software.
• JSON — final step summary with configuration and aggregate statistics. Machine-readable for automated analysis pipelines.
• Matplotlib PNG — 6-panel dashboard with time-series plots for population, diversity, vesicles, fitness, RNA length, and complexity score.

11. Configuration System

11.1 Parameter Reference

The Config dataclass provides approximately 30 parameters with sensible defaults. All parameters can be overridden by scenario files, project settings, or CLI arguments.

11.2 Scenario Overlay

The configuration system uses a layered override architecture:

Each layer only specifies the parameters it needs to change; unspecified parameters inherit from the layer below. This design allows scenarios to define minimal overrides while inheriting robust defaults, and allows CLI arguments to override everything for ad-hoc experimentation.

11.3 The Four Preset Scenarios

12. Parameter Sweep Engine

The sweep.py module enables systematic exploration of the parameter space through three sweep modes:

Ten parameters are declared as sweepable: error_rate, reaction_radius, base_rate, catalyst_multiplier, diffusion_scale, feedstock_rate, ocean_loss_frac, division_size, vesicle_threshold, and temperature_max. Each sweep run produces per-run CSV files and a summary JSON for downstream analysis.

13. AI Analysis Laboratory

The AI Analysis Laboratory provides 27 deterministic analysis functions organised into 8 scientific modules. Each function operates on the current simulation state (molecules, reactions, vesicles, metrics history) and returns structured JSON results rendered by dedicated JavaScript visualisers.

13.1 Eight Modules, 27 Functions

13.2 Analysis Methodology

Pathway Analysis (prebiotic.pathway)

Uses breadth-first search backward from 9 target molecules (amino acid, nucleotide, ribose, etc.) through the reaction graph to find all synthesis paths from the food set (11 simple inorganic molecules). Results include the shortest path, intermediate molecules, and which reactions are on the critical path.

RAF Set Detection (autocatalysis.raf)

Implements the Reflexively Autocatalytic Food-generated set algorithm: starting from the food set, iteratively closes the set by identifying reactions whose products are catalysts for other reactions in the set. A non-empty RAF set indicates self-sustaining autocatalytic chemistry—a key milestone toward metabolism.

Fitness Landscape (selection.landscape)

Maps the genotype-to-fitness function by binning vesicles by their RNA sequence composition and correlating with fitness scores. Identifies local optima, fitness valleys, and evolutionary trajectories.

Major Transitions (selection.transitions)

Evaluates progress along the key evolutionary transitions framework (Szathmáry & Maynard Smith, 1995): replicating molecules → molecular populations → compartmentalised molecules → RNA-catalysed systems → protocells with heritable variation.

14. Data Model

BOL uses a file-based JSON storage strategy with no external database dependencies. This design eliminates database administration, simplifies deployment, and keeps the system fully self-contained.

15. Web Application

15.1 Frontend Architecture

The web frontend uses a server-rendered architecture with Jinja2 templates and vanilla JavaScript for interactivity. This approach avoids framework dependencies while delivering a rich, responsive user experience.

The design system features a dark background (#0a0a0a) with card surfaces (#1a1a2e) and accent colours—blue (#4cc9f0), pink (#f72585), gold (#fca311)—inspired by Splunk’s enterprise dashboard aesthetic. Mobile responsiveness is achieved through breakpoints at 768px and 480px, with a hamburger menu replacing the top navbar on small screens.

15.2 REST API Reference

The Flask server exposes approximately 50 REST API endpoints organised into 8 categories:

15.3 Real-Time Update Strategy

The dashboard uses a polling-based approach for real-time updates, chosen for simplicity and compatibility over WebSockets:

Chart.js instances update in-place using chart.data.datasets[n].data = newData with smooth animation transitions. This avoids chart recreation overhead and provides a fluid visual experience.

16. Security Architecture

BOL implements defence-in-depth security aligned with NIST SP 800-53 controls and CISA binding operational directives.

16.1 Authentication

16.2 Authorisation

• Resource ownership — Projects are scoped to their creator. All project API endpoints enforce owner check before read/write access.
• Admin role — Administrative endpoints (/api/users, user deletion) require admin privileges configured via the BOL_ADMIN_USERS environment variable.
• Public endpoints — Simulation data APIs are publicly accessible (no auth required) to enable shared observation of running simulations.

16.3 Transport & Headers

16.4 Input Validation

• Server-side: Usernames validated against [a-zA-Z0-9_-] allowlist. Project IDs, lesson IDs, and filenames are sanitised before filesystem access.
• Template engine: Jinja2 auto-escaping enabled globally; no |safe filter usage.
• Client-side: escHtml() and textContent for safe DOM updates.
• Command injection: shlex.split() with shell=False for subprocess calls.
• SSRF prevention: URL scheme validation (HTTP/HTTPS only) for any outbound requests.

17. Deployment & Operations

BOL supports two deployment modes: local development and production deployment on a cloud server.

Production Deployment Pipeline

1. Provision server — setup_server.sh creates a bol user, installs Python 3.12, Nginx, and certbot on Ubuntu 24.04 LTS.
2. Deploy code — deploy_to_server.ps1 rsyncs the project to /opt/bol and creates a Python virtual environment with all dependencies.
3. Configure services — finish_setup.sh creates a systemd unit file, Nginx virtual host configurations, and obtains SSL certificates.
4. Harden headers — fix_nginx_headers.sh applies CSP, HSTS, and X-Frame-Options headers to the Nginx configuration.

Operational Procedures

Infrastructure

• Platform: GCP Compute Engine e2-small (2 vCPU, 2 GB RAM)
• OS: Ubuntu 24.04 LTS
• WSGI: Gunicorn with 3 workers, 120-second timeout
• Reverse proxy: Nginx with SSL termination
• Process manager: systemd with RestartSec=5
• SSL: Let’s Encrypt with auto-renewal
• Firewall: ufw allowing ports 22 (SSH), 80→443 (redirect), 443 (HTTPS)

18. Design Principles & Non-Functional Requirements

Core Design Principles

1. Coarse-Grained Particles — Molecules are objects with aggregate properties rather than individual atom simulations. This makes the simulation tractable at thousands of molecules while preserving meaningful chemistry.
2. Stochastic Reactions — No reaction is deterministic. Probability-based firing creates realistic variation between runs and enables statistical analysis via sweeps.
3. Spatial Realism — The continuous 3D volume with spatial hashing creates microenvironments where local conditions (temperature, pH, mineral density) drive different chemistries in different regions.
4. Pluggable Scenarios — JSON configuration files allow new hypotheses to be explored without modifying source code.
5. Observable Emergence — Self-assembly, replication, and selection are emergent phenomena, not hard-coded transitions. The simulation provides conditions; outcomes are observed.
6. Real-Time Interactivity — Live dashboard updates enable scientists to observe and interact with running simulations.

Non-Functional Requirements

19. Prompt-Driven Development

19.1 Development Methodology

BOL was designed and constructed through a prompt-driven development process: a series of carefully sequenced natural-language design prompts, each specifying a major subsystem to build. The methodology mirrors an iterative engineering workflow where each prompt defines requirements, the implementation is executed, and validation is performed against all four origin-of-life scenarios before advancing to the next prompt.

This approach yielded several advantages:

• Traceable design decisions — every feature maps to a numbered prompt with a timestamp, rationale, and recorded validation results.
• Incremental complexity — the system grows layer by layer (chemistry → energy → assembly → polymers → selection → visualisation → web → deployment), each layer building on proven foundations.
• Scenario-gated quality — no prompt is considered complete until all four scenarios (alkaline vent, RNA world, warm little pond, iron–sulfur) produce scientifically plausible outputs.
• Full audit trail — the prompt log (docs/PROMPTS.md) and progress log (docs/PROGRESS_LOG.md) provide a complete record of every design decision, code change, and validation result.

19.2 The 24 Build Prompts

The application was constructed through 24 sequential prompts, beginning with project inception and culminating in a fully deployed web platform with PDF documentation, training curriculum, and algorithmic audit. The first 10 prompts were planned at inception; 14 additional prompts were added during development as the scope naturally expanded.

19.3 Build Tracking & Release Management

BOL includes a dedicated Build History page (/builds) that provides a versioned release record of the platform. The build system serves as both documentation and an auditable record of every iteration.

Build Page Features

• Release summary panel — KPI grid displaying release date, build iteration count, test count with pass/fail status, and target platform.
• Release highlights — bullet-point summary of major features delivered in each release.
• Dependency manifest — table listing all third-party packages (numpy, scipy, matplotlib, flask, vispy) with versions and purposes.
• Collapsible build log — complete timeline of all 24 prompts with dates, titles, and descriptions. Each entry shows a completion marker, prompt number tag, datestamp, and a concise summary of deliverables.

The build page is rendered as static content in the builds.html template, served via the /builds route. It is accessible to all authenticated users and provides a single-page view of the complete development history.

Release Metadata (v1.0.0)

19.4 Bug Tracker & Quality Assurance

BOL includes a built-in Bug Tracker (/bugs) that provides full lifecycle bug management without requiring external issue-tracking tools. The tracker was designed to keep quality assurance tightly coupled with the application itself.

Bug Lifecycle & Workflow

Each bug progresses through a defined state machine with six possible statuses:

  open  →  in_progress  →  fixed  →  verified
    ↓                          ↑          ↓
    ↓        reopened  ←———————+
    ↓
  wont_fix

Data Model

Bugs are stored as JSON in a file-based storage layer (bugs/bugs.json) with thread-safe access via a threading lock. Each bug record contains:

REST API

The bug tracker exposes a full CRUD API with filtering and automated testing:

Automated Test Runner

The bug tracker includes a built-in automated test runner that can verify fixes without leaving the application. Each bug can specify a test_command in one of three formats:

1. HTTP health check — GET https://url [expected_status]. Validates that the endpoint returns either the specified status code or any 2xx response.
2. URL check — a plain URL is fetched and validated for a 2xx response.
3. Shell command — arbitrary shell commands executed via subprocess.run(shell=False) with a 30-second timeout and output capped at 2,000 characters. Commands are parsed with shlex.split() to prevent shell injection (NIST SI-10).

When a bug in fixed status passes its automated test, the tracker automatically promotes it to verified. The “Test All” function runs tests on every open, in-progress, or fixed bug that has a test command defined, returning a summary of total, passed, and failed counts.

User Interface

The bug tracker UI provides:

• Status statistics row — clickable pill-shaped counters showing the number of bugs in each status, doubling as quick filters.
• Multi-criteria filter bar — text search, status dropdown, severity dropdown, and environment dropdown for narrowing the bug list.
• Sortable bug table — columns for ID, title with environment badge, severity badge (colour-coded: green/amber/orange/red), status badge (colour-coded by state), test result indicator (pass/fail/pending), tags as chips, last updated timestamp, and action buttons (edit, delete).
• Add/Edit modal — comprehensive form with all bug fields including steps to reproduce, expected/actual behaviour, fix description, automated test command, and fix verified checkbox.
• Test result modal — displays automated test output in a monospace panel with pass/fail colour coding.
• Security — all mutating operations (create, update, delete) require authentication. Test execution is also authenticated to prevent abuse.

20. Glossary

21. References

1. Gilbert, W. (1986). “The RNA World.” Nature, 319, 618.
2. Wächtershäuser, G. (1988). “Before enzymes and templates: theory of surface metabolism.” Microbiol. Rev., 52(4), 452–484.
3. Russell, M. J. & Hall, A. J. (1997). “The emergence of life from iron monosulphide bubbles at a submarine hydrothermal redox and pH front.” J. Geol. Soc., 154, 377–402.
4. Miller, S. L. (1953). “A production of amino acids under possible primitive Earth conditions.” Science, 117(3046), 528–529.
5. Ferris, J. P. et al. (1996). “Synthesis of long prebiotic oligomers on mineral surfaces.” Nature, 381, 59–61.
6. Orgel, L. E. (2004). “Prebiotic chemistry and the origin of the RNA world.” Crit. Rev. Biochem. Mol. Biol., 39(2), 99–123.
7. Damer, B. & Deamer, D. (2015). “Coupled phases and combinatorial selection in fluctuating hydrothermal pools.” Life, 5(1), 872–887.
8. Szostak, J. W. et al. (2001). “Synthesizing life.” Nature, 409, 387–390.
9. Szathmáry, E. & Maynard Smith, J. (1995). “The major evolutionary transitions.” Nature, 374, 227–232.
10. Hordijk, W. & Steel, M. (2004). “Detecting autocatalytic, self-sustaining sets in chemical reaction systems.” J. Theor. Biol., 227(4), 451–461.
11. Martin, W. & Russell, M. J. (2003). “On the origin of cells: a hypothesis for the evolutionary transitions from abiotic geochemistry to chemoautotrophic prokaryotes.” Phil. Trans. R. Soc. B, 358, 59–85.
12. NIST Special Publication 800-53 Revision 5. “Security and Privacy Controls for Information Systems and Organizations.”
13. NIST Special Publication 800-63B. “Digital Identity Guidelines: Authentication and Lifecycle Management.”
14. CISA Binding Operational Directive 18-01. “Enhance Email and Web Security.”

BOL — Beginning of Life Simulator • Technical White Paper • Version 1.0.0 • March 2026

© 2026 DREL Solutions. All rights reserved.