GARS keeps each project's memory as plain files in the project's own folder, and a session that starts cold is handed a catch-up rendered from them, so it picks up where every project stopped: how far each assay got, which settings are complete, what each step produced, and the last entries of the project's history. (Since decision 0151, a project GARS treats as closed shows only its name, its class label and its pipeline status.)
The history is append-only, by written rule. After the first stage, each stage's contract tells the agent to append the tool's entry to the project's HISTORY.md, and the rule that no entry is rewritten or removed is written at the top of that file. It is a written rule, not a lock on the file.
The catch-up is a render, not a memory. It is derived from the files each time and writes nothing, so it cannot drift from them. GARS keeps no separate memory file for the agent to write freely: in its own words, “a memory the agent can write is a memory it can poison.”
The decision log answers by symptom. Most of GARS's design decisions carry the symptoms that should find them, so a recurring failure turns up its precedent, not only a file path. Across projects, that log is what carries over; there is no database and no embedding store.
That catch-up for the two demonstration projects described just below, rendered by the script GARS's session-start hook runs (project_state.py, at commit f0f4e44), without its two-line header and blank separator lines:
The two projects below were run by a deterministic driver on nf-core's public test data at GARS v0.10.0: no model and no agent in the loop, and no recording of them exists. They show the process, not a finding.
The pipelines are real and really executed. The inputs are each pipeline's public test dataset; the biological outputs are demonstration artifacts, not findings.
What the ↓ bytes check on each number settles, and what it does not
About that hash: the bytes behind ↓ are a copy committed to this repo, and the site will not serve one whose md5 is not the ETag shown. That check alone proved only that the artifact was intact — the number beside it was read from a different file, with nothing tying the two together — so every number whose bytes are served is now re-derived from those bytes on every request: a peak count from the non-empty lines of its own narrowPeak, a task count from the rows of its own execution trace, a cluster or cell count from the field in its own served summary. All 23 of them. If any disagreed with the artifact it points at, this page would refuse to render rather than print it. The 24th, the marker table row count, has no served artifact to check against — that file carries gene names and never travels — and its chip says so. What the hash still cannot confirm is that those bytes sat in S3 under that key, since the copy and the ETag both come from here; that half is owner-verifiable, like the marker table. Nothing on this page escapes that: the execution traces are served the same way, from a copy in the same repo, with job ids from the same file we wrote. They are not independent evidence — they are the richest owner-attested evidence here: 442 rows, each with its own AWS Batch job id, runtime and memory, and a fabrication would have to be coherent across all of them. Costly to fake is not the same as verifiable by you, and this page will not blur the two.
The receipts, read from memory
Each project answered from GARS's own memory surfaces when this page opened: what was done, what is left, and every number with the job and file it was read from.
How these two projects were made: a deterministic driver (tools/modality) called GARS's own stage tools inside the pinned images and submitted each pipeline to AWS Batch — no model and no agent in the loop, and no recording exists of it. All six legs ran registered GARS skills, so each of them passed the same doors and left its own registry record of the outputs it produced. The agent-driven runs are the recordings on this site (one assay, bulk RNA-seq).
The modalities are public test fixtures grouped for demonstration; no cross-modality integration is claimed. Two of them share their reads: nf-core's own chipseq test profile takes the same four yeast read pairs the atacseq profile uses (chipseq adds two input pairs), so epigenome-a is two assays over one public dataset. transcriptome-b's two are different organisms and different fixtures.
A known issue in epigenome-a's atacseq run on this page: its configuration names the yeast mitochondrial contig “Mito”, a name the test genome it ran on does not use, so that run most likely skipped the pipeline's mitochondrial-read filter. This is read from the run's own log and was not reproduced. Its chipseq and atacseq runs also gave the peak caller the yeast assembly's whole length as the genome size, rather than the effective size that GARS's genome registry records. The run's record is kept as it ran; the driver that makes these runs now writes the genome's own name for that contig and the registry's genome size.
The GARS runtime vendored here byte for byte under gars_runtime/ is commit f0f4e44, which is public and readable on GitHub: https://github.com/javrodriguez/genomics-agentic-research-system/commit/f0f4e44 . It is an ancestor of that repository's main, not necessarily its head: main moves, and a sentence claiming otherwise goes stale the next time anything lands there -- once within half an hour of being written. The pin moved to this commit on 5 September 2026, the day it was pushed, when the spatial cluster count became a registered GARS skill; transcriptome-b was re-run that day and its recorded run cites f0f4e44, while epigenome-a's recorded run still cites the previous pin d2d2745 (public since 4 September 2026, when its three commits were pushed; before that it was ahead of public main and unreadable by a stranger), and nothing epigenome-a executed changed between the two commits.