Stories — Operating System for a Research Laboratory

The challenge

A research laboratory accumulates hypotheses, experiments, datasets, and software as separate, loosely connected artifacts — a notebook here, a spreadsheet there, a README in a forgotten repository. Stories treats the laboratory itself as a single knowledge object: every program, question, hypothesis, note, experiment, piece of software, publication, dataset, and presentation is a typed, versioned document under content/, validated against a shared frontmatter contract before it can be published.

The platform's own build is the proof of that contract. A deterministic pipeline reads every content file, resolves the relationships between entities (which experiment answers which question, which dataset backs which publication), and writes the result to a single generated artifact — a DuckDB file plus a manifest — that the public site reads at request or build time. Nothing in production depends on a live database: the generated artifact is the only thing that changes between one build and the next.

Architecture in brief

Content authoring happens through a single-admin Studio, backed by Supabase for session and draft persistence behind a generic persistence_records table. Publishing a draft renders it to MDX and commits it atomically to this repository through the GitHub API; Vercel then deploys the new build. During a build, a disposable in-memory graph (LadybugDB) resolves cross-entity relationships before the pipeline flattens the result into the DuckDB artifact — the graph itself is never persisted, since the generated database is the lab's only durable knowledge artifact.

The current experiment: migrating the backend to Python

As documented in ADR-004, the lab's own backend — the content pipeline, the authoring workflow, and the knowledge kernel — is being migrated from TypeScript to Python, phase by phase, each gated on independent verification rather than on the migrating agent's own report: real test runs, real builds, real .nft.json traces, and, for the authoring and persistence layer, a validation pass against a real Supabase project rather than a mocked one. This entry exists because that discipline applies to the lab's content tree as much as to its code: the Phase 7 cutover criteria call for real content under content/, not only synthetic fixtures and an empty tree, and this document is that first real entry — a laboratory describing its own instrument.