Skip to content
zensation
🔬

Research overview

Three tracks, architecture and agenda

📐

Methodology

Operational standards and validation

📄

Publications

Preprints, software, identifiers

⚖️

Research ethics

Fundamental-rights nexus and compliance

🏛️

Public sector & funding

Collaborations in the public sector

🧰

Resources

Code, data, citation, open science

AboutOpen SourceDevelopersBlog
Contact
zensation
🔬Research overview📐Methodology📄Publications⚖️Research ethics🏛️Public sector & funding🧰Resources
AboutOpen SourceDevelopersBlogContact
Blog→Engineering
Engineering

Research as Documentation: Pre-Registration and Replication

Alexander Bering
Alexander Bering
August 19, 2025 · 3 min read

The point at which a project needs a method

By mid-2025 there was enough working code that the risk shifted. The danger was no longer "will any of this run" but "will we be able to trust, and later defend, what it tells us." An independent effort has no institutional review board looking over its shoulder. That absence has to be replaced with method, deliberately, or the results are worth very little.

So we made documentation a research output in its own right, on the same footing as the code. Three practices carried most of the weight.

Pre-registration, with a timestamp

Before running the experiments that mattered, we wrote down what we expected and how we would measure it — and anchored those documents in time using OpenTimestamps, which records a cryptographic proof of a file's existence on a given date.

The reason is simple and slightly uncomfortable: it is very easy, after seeing results, to convince yourself you predicted them. A timestamp removes the temptation. A decision recorded before the data cannot be quietly rewritten after it. For a single-investigator effort this is one of the cheapest available defences against self-deception.

Replication as the default

Every result we care about ships with the material needed to reproduce it — the data, the configuration, the procedure — rather than as a number in a slide. This is partly principle and partly self-interest: code that cannot be re-run is code whose results you will eventually be unable to explain, including to yourself six months later.

It also changes how a claim reads to an outside reader. "We observed X" is an assertion. "We observed X, here is how to obtain it" is an invitation to check. Only the second belongs in research.

Negative results are results

The last practice is the hardest to keep: writing down what did not work. Approaches that looked promising and underperformed, parameters that turned out not to matter, mechanisms we expected to help and that did not. These rarely make it into public writeups, which is exactly why public writeups tend to overstate how clean the path was.

We keep the record because the failures carry information — they mark the boundaries of where the method actually holds — and because a research programme that only ever reports its wins is not one a serious reader should trust.

What this is for

None of this is glamorous and none of it is novel; these are ordinary norms of careful science. Stating them is the point. An independent lab earns the right to be taken seriously not by asserting rigour but by leaving behind the artefacts of it — timestamps, reproducible runs, a complete ledger of dead ends — for anyone who cares to look.

Enjoying this article? Get more like it.

Share on XShare on LinkedIn
Try ZenAI

AI assistant with 7-layer memory — get started for free.

Get Started Free

Related Articles

Why We Wrote 11,589 Tests for a Solo Project

11,589 tests. 24 intentionally skipped. 0 failures. Here's why a solo developer wrote more tests than most funded teams — and why it was the best decision of the project.

How We Built A-RAG: When Retrieval Learns to Think Before Searching

Standard RAG does one thing: embed, search, return. A-RAG plans the retrieval strategy before executing — here's how we built it and why it matters.

How We Built a Memory System That Thinks Like a Brain

145 development phases, 11,589 tests, and one question: can software remember like a human? A technical journey from vector store to cognitive architecture.

Stay in the loop

Get notified about new posts on AI memory, self-hosting, and building intelligent systems.

No spam. Unsubscribe anytime. GDPR-compliant.

Newsletter

No spam. GDPR-compliant.

© 2026 Alexander Bering / ZenSation Enterprise Solutions

HomeResearchMethodologyResearch ethicsPublic sectorPublicationsResourcesZenAIOpen SourceDevelopersTechnologyAboutBlogChangelogPrivacy PolicyLegal Notice
Download on theApp Store
GitHubLinkedInarXivZenodoORCIDScholarSemantic ScholarHuggingFacenpmDiscord