このページは機械翻訳によって英語から日本語に翻訳されました。 英語のオリジナルをご覧ください。

Active InferAnt Stream #018.1

A template/ approach to Reproducible Generative Research: Architecture and Ergonomics from Configuration through Publication

Mar 22, 2026 · with Daniel Friedman

▶ Watch on YouTube ↗

Session details

Date: Mar 22, 2026

Series: Active InferAnt Stream #018.1

Guests: Daniel Friedman

Transcript

AI-generated transcript excerpt

The full transcript is available on GitHub. This excerpt is generated by automated speech recognition and may contain errors.

All right. Hello, welcome. It's March 22nd, 2026. This is Daniel Friedman in for Ant Stream 18.1. This stream is going to use the doxology template repo maybe to be moved to an institute repo in the future and explore this self-generating package/paper as always in active debugging mode. We will discuss topics like reproducibility and scientific workflow for papers with different amounts of formalism and prose. Look through the overall structure of the repo, the top-level infrastructure, methods, orchestration, documents, and the project scale. The application of thin orchestrator and separation of consideration for different parts of the code base in the projects. Look at running multiple projects with the top-level run commands and see what people put in the chat for ideas or questions. To begin, you can probably just check the most recent version of the repo and methods are hopefully properly documented at that time. Um okay. Where we're going is rendering a document that looks like this with color of your choice, linking to different sections of the paper configurable type setting automatic numbering hypertext, code reference inserting images However also running that scientific code to get that uh output. Uh lot lots of ways to enter into this. We'll start with the overall structure of the repo, then look at the project scale. And look at the in in in looking at the project, hopefully somebody will have suggested something in the chat for just some project and we will see how far uh one-shotting in cursor and/or anti-gravity just a suggestion for a project gets. So delete some of these. Okay. Top level of the repo. Docs is documentation for the repo itself. Infrastructure has the modules of code methods definitions for each of these submodules of code. This is kind of like the toolkit for the factory of research replication that's about to be orchestrated. And there's a few general folder strategies and um everything being presented here is just one way to do it. I eagerly look towards other, simpler, different, better methods. So just sharing where my explorations have gotten me and learning from different patterns and looking forward to people forking and and coming up with other approaches. Agents and a read me at every folder level and scale files at the submodule or finer scale folder levels. Maybe eventually these two will be unneeded because you could just iterate across a whole repo and say put a scale file in or scale to generate scales but uh it it helps with some of the coherence of the different methods. The infrastructure methods are tested with the top-level test suite. The infra tests is the same modules as the infrastructure unit tests and the integration are combining across different modules. Scripts in general are going to be thin orchestrators, so ideally not defining any major or any methods in these scripts themselves, just calling upon methods in this case defined in the infrastructure layer. And when you run this there's two entry points from the top level. Run and secure run. And they're both going to do basically the same thing. Secure run is going to additionally apply the steganography module, but we'll just work mainly with run for now unless maybe we'll try later. From the top level ./ run.sh and the text menu will come up. And it will uh give options based upon scanning for what projects are in the projects folder. So also I have some untracked folders that are their own private repos that won't be used today probably for projects archive and projects in progress. Projects just itself is going to be kind of like the the projects that are on the burner. So you could have one or more. They're kind of like separately stand-alone projects. And there's code project, which is just a simple placeholder project with example documented of the project structure. And then in this case the recently published paper for this repo as a manuscript to understand how the package sort of rendered this and ran the…