Skip to content
zensation

Research

🔬

Research overview

Three tracks, architecture and agenda

📐

Methodology

Operational standards and validation

📄

Publications

Preprints, software, identifiers

⚖️

Research ethics

Fundamental rights and compliance

🧰

Resources

Code, data, citation, open science

Collaboration & applications

🏛️

Public sector & funding

Collaborations in the public sector

🧭

Adopt AI

Neutral roadmap & interactive simulation

🛡️

Protecting public spaces

Track B — rights-preserving early warning

⚙️

Technology

ZenBrain — our open core

PublicationsAboutOpen SourceBlog
Contact
zensation

Research

🔬Research overview📐Methodology📄Publications⚖️Research ethics🧰Resources

Collaboration & applications

🏛️Public sector & funding🧭Adopt AI🛡️Protecting public spaces⚙️Technology
PublicationsAboutOpen SourceBlogContact
Blog
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.

What the discipline led to — checkable results instead of claims: 91% of the accuracy at 1% of the cost, the Cooperative Survival Network, and why 11,589 tests.

Share on XShare on LinkedIn

Related Articles

From AI Overview to a Real Demo: Turning a Blueprint into a ZenAi Instance — Autonomously

Most AI pilots don't fail on the technology — they fail at the jump from idea to a tangible, context-true application. Here's how a quick assessment turns autonomously into a lightweight, sector-accurate ZenAi instance — and why honesty (clearly labelled demo data) is the most important building block.

The Stress Test: Why We Ran Ten Security Sprints Before the First Customer

Between 'it runs on my machine' and 'a company entrusts it with its data' lies a gap many AI projects underestimate. How we bridged it with ten back-to-back hardening sprints.

91 % of the accuracy at 1 % of the tokens — the Pareto position for AI memory

On LongMemEval-500, ZenBrain reaches 91.3 % of a long-context oracle's accuracy at 1/106ᵗʰ the per-query token budget. The oracle wins by 4.5 percentage points, burns 106× more tokens, and has no memory architecture at all.

© 2026 Alexander Bering / ZenSation Enterprise Solutions

HomeResearchMethodologyResearch ethicsPublic sectorPublicationsResourcesAdopt AIOpen SourceTechnologySystem explorerAboutBlogRSSChangelogPrivacy PolicyLegal NoticeAccessibility
GitHubLinkedInarXivZenodoORCIDScholarSemantic ScholarHuggingFacenpmDiscord