Five months into Hedegreen Research, the most useful thing I found was not another idea. It was a reason to distrust the things I had already built.
Hedegreen Research is five months old.
That is long enough for something slightly dangerous to happen.
It has started to look real.
There are articles, datasets, public tools, APIs, PDFs, archives, research packs, version numbers and an increasingly complicated internal system for producing more of them.
Some of it already looks institutional.
That matters because the appearance of trust can arrive much faster than the right to be trusted.
This essay can do that too. It is edited. It uses rhythm. It selects examples. It is trying to persuade you.
That is not evidence that it is right.
Rhetoric can make rigorous work easier to understand. It can also make weak work feel stronger than it is.
Those are different axes.
So this month I did something different.
I started attacking Hedegreen Research.
Not comprehensively. Windowsill received relatively deep inspection. Most other public tools received smaller breadth tests around one or a few central invariants. Some questions remain unresolved. Some things were not tested at all.
The objective was not to prove that the system works.
It was to begin finding out where it does not.
Does this number mean what the interface says it means?
Does missing data remain missing?
Does an unavailable signal become a reassuring one?
Does a warning survive when the result becomes a PDF?
Does the public description still match the underlying project?
And when I think I have found a bug, have I actually found one?
The audit had to correct itself
Eurovision Explorer gave me an early answer.
I found a code path where an individual year request could fail while the rest of the archive continued loading.
I initially treated that as a confirmed completeness problem.
That was too strong.
I had demonstrated a possible failure mode. I had not demonstrated that the public archive had actually omitted a year.
So the finding was reopened.
A few tools later, the reverse happened.
A generated 24 Doors PDF appeared to contain corrupted characters. The first evidence came from parsing the PDF.
That was not enough.
A parser producing mojibake does not prove that a human opening the artifact sees broken text.
Then the PDF itself was rendered.
The corruption was visible.
Now the stronger finding was justified.
That established a narrower fact than a general judgment about 24 Doors. The specific generated artifact was visibly broken. It did not prove that the number inside it was wrong, or that every later PDF would be broken. A different local final artifact now renders legibly. That does not erase the earlier failure. It only prevents the audit from turning one observed artifact into a permanent property of the whole tool.
Those two cases showed that the audit could move in both directions between uncertainty and confirmation.
They did not show something harder: whether a previous PASS can later collapse.
I did not systematically re-audit the things that passed this month.
So that test has not happened yet.
A PASS should therefore never become a permanent certificate. It means only that a defined invariant survived a defined test at a particular time.
Unknown is not quiet
One of the smallest confirmed failures came from the Space Weather tool.
It reads several public NOAA feeds and reduces them into a simpler public status.
There is a failure state where all of those feeds can be unavailable, yet the primary status can still fall through to:
Quiet signal.
That is wrong.
Not because a storm must therefore exist.
Because the system does not know.
A failed sensor is not evidence of calm.
That tiny software bug contains a surprisingly large research problem.
Systems constantly try to collapse missing information into something easier to display.
No measurement becomes zero.
No record becomes no event.
An unavailable signal becomes quiet.
An assumption becomes a default.
A provisional number acquires enough decimal places that it begins to look measured.
So one rule emerging from the audit is almost embarrassingly simple:
Unknown is not quiet. Missing is not zero. Unverified is not false.
The difficult part is not writing that sentence.
The difficult part is making the whole pipeline preserve it.
Windowsill was where the problem stopped being small
Windowsill became the deepest audit case because it sits across several layers at once.
There is a public API, a TID client, plant data, climate data, scoring logic, safety notes, reports and PDFs.
A recommendation can be wrong because a plant record is wrong.
It can be wrong because climate data was interpreted incorrectly.
It can be wrong because one scoring layer assumes the wrong hemisphere.
It can contain the right warning on screen and then lose that warning when the result becomes a PDF.
It can combine state from two different requests because an older response arrives after a newer one.
None of those failures requires a spectacular AI hallucination.
Most are ordinary software and data problems.
One confirmed problem concerned orientation. The system could correctly recognise hemisphere in one layer while another scoring layer still used a fixed northern-hemisphere mapping.
A south-facing window is not the same solar proposition in Copenhagen and Melbourne.
Another problem concerned hardiness: a USDA-style classification was being derived from the wrong kind of temperature statistic.
Then there was safety. Risk information could exist inside the knowledge structure without reliably surviving all the way to the final recommendation, and warnings visible in the browser did not always survive into more formal-looking outputs.
That particularly bothers me.
A warning disappearing when a result becomes a PDF is potentially worse than an ugly warning on a prototype interface.
The artifact gains authority at approximately the same moment the caveat disappears.
Windowsill forced another rule into the audit:
The truth boundary has to survive the pipeline.
It is not enough for the correct caveat to exist somewhere in a repository.
It has to survive:
data → model → API → client → report → PDF → reader
Real systems have seams.
Seams are where truth gets lost.
Almost nobody reads this
Hedegreen Research still has almost no audience.
That is obviously a distribution problem.
It is also a verification problem.
Established research communities have people looking for mistakes.
Someone notices the denominator.
Someone knows the dataset.
Someone sees that a definition moved.
Someone simply says:
No. That does not follow from the evidence.
I genuinely want that.
There is apparently an ocean of AI slop now.
Fine.
Find mine.
Show me the unsupported sentence.
Show me the denominator.
Show me the source that does not support the claim.
Show me the interface that turns uncertainty into confidence.
But an invitation is not an institution.
Writing criticise this does not create reliable external scrutiny.
At five months, Hedegreen Research does not have a functioning external review layer.
So the real question is not merely how to get more readers.
It is:
How does a very small research institution deliberately expose important claims to people capable of breaking them?
The first external-pressure experiment should be narrow.
Windowsill already has a candidate: its hardiness calculation.
Instead of asking someone to “review Windowsill,” the question can be reduced to one inspectable packet: the current calculation, the definition it is supposed to satisfy, the evidence, the proposed correction and one narrow question.
That is not peer review.
It is an experiment in whether external criticism can be made cheap enough to give and precise enough to change the system.
Who controls the control?
The audit machinery turned out to need auditing too.
An early category called NOT A BUG gave me too much power to dismiss criticism by explaining what I had intended.
Replacing it exposed another problem: a specification cannot constrain a later dispute if I can quietly write the specification after the product exists.
And even a dated internal document is not much of a clock if the same institution controls the date.
Those details now live in the accompanying Audit & Correction Record, where they can change without turning this essay into a manual.
The larger problem is simpler:
Who controls the control?
There is a failure mode on the other side too.
By the time this essay had been revised several times, many of its weaknesses had already been named inside the essay itself.
That sounds healthy.
It can also become another escape hatch.
If I identify the weakness before anybody else does, I can create the appearance of self-correction without changing anything outside the paragraph that admits it.
So another rule matters:
Naming a weakness is not a correction. A correction requires a consequence outside the sentence that names it.
That is why this essay now has a companion document.
The article is the argument.
The Audit & Correction Record is where the classification changes, criticism trace, unresolved tests and methodological revisions live.
Pressure should leave an artifact, not just a good sentence.
The AI problem is not simply that AI makes mistakes
Of course AI makes mistakes.
So do humans.
So do spreadsheets.
So do APIs.
So do academic papers.
The interesting question is what happens after a mistake enters a system.
Does it become a number in a dataset?
Does another model repeat it?
Does a PDF freeze it?
Does a polished interface remove the uncertainty surrounding it?
Or is there enough structure around the output to make the mistake inspectable?
That is why AI-generated is not, by itself, a useful diagnosis.
It identifies an origin mechanism.
It does not identify the defect.
If a sentence is wrong, tell me why.
If the source does not support it, show me.
If a citation was invented, that is a concrete failure.
If the calculation is invalid, that is a concrete failure.
If a generated tool contains a race condition, that is a concrete failure.
If the whole premise is nonsense, that is also concrete criticism.
“AI slop” may describe an ecosystem.
It is a terrible bug report.
The scarce resource seemed to be continuity
There is another constraint underneath these five months.
Compute access.
My level of model access changed materially during this period.
That gave me an accidental comparison, not a controlled experiment.
The projects changed. My experience changed. The workflows changed.
So I cannot cleanly attribute the difference to one variable.
But my experience suggests that the biggest loss when access falls is not simply raw output.
It is continuity.
More model capacity seemed to give more room to keep several contracts apart, inspect source without losing the original question, compare versions and return to earlier findings without reconstructing the entire surrounding state.
The line I first wanted to write was:
The scarce resource was not words. It was continuity.
That sounds like a finding.
It is not one.
The more accurate version is:
The scarce resource seemed to be continuity, not words.
That is currently a working hypothesis.
Compute is part of the laboratory.
Access therefore becomes part of the material conditions of the research.
And naturally, approximately when I returned to lower capacity, I decided to build the Tool Builder.
Tool Builder is not primarily about building faster
At first, Tool Builder sounded like an efficiency project.
I increasingly think that misses the important part.
Its real purpose is to stop every public instrument from becoming a new handcrafted accident.
A tool should enter a known pipeline.
Specification.
Truth boundary.
Dependencies.
Tests.
Version state.
Release state.
Corrections.
Migration.
If every tool invents its own missing-data semantics, missing data will eventually become zero somewhere.
If every tool invents its own PDF path, warnings will eventually disappear.
If every release depends on me remembering what happens next, something will eventually be forgotten.
Tool Builder is therefore an attempt to move institutional requirements out of working memory and into infrastructure.
If Hedegreen Research only works while one enormous conversational state holds the entire structure together, then I have not built an institution.
I have rented a very large working memory.
The system should survive the conversation.
The research also has to leave the screen
I do not want Day 1.0 defined entirely by software.
Research happens in the world.
Books exist.
Paper archives exist.
Places need to be visited.
Objects need to be inspected.
People need to be spoken to.
A physical source should be able to enter approximately the same provenance machinery as a digital source.
A book can be scanned.
Relevant pages retain title, edition and page references.
Field research should work the same way.
There will probably be a Hedegreen Research field bag.
Nothing glamorous.
Probably a used shirt with an HR mark before there is respectable merchandise.
But the important object will not be the equipment.
It will be the task attached to it.
Before leaving, the research system should be able to answer:
What are we trying to establish?
What evidence must we return with?
What can this trip not establish?
What must be recorded so another person can understand what happened?
The equipment changes.
The epistemic contract should not.
What Day 1.0 has to mean
If Day 0.5 is where Hedegreen Research begins testing whether it can correct itself, what would justify Day 1.0?
Not more output.
Not another hundred articles.
Not a larger TID index.
And not the arrival of a particular date.
I want 1.0 to mean that the basic institutional machinery exists.
A question should be able to enter Hedegreen Research and follow an existing path:
question → research → sources → workpack → review → publication → archive → distribution → correction
A tool should have an equivalent path.
A physical source should have a path.
A field observation should have a path.
Recurring publications should exist as institutional obligations rather than things I happen to remember.
The Operations Panel should know what is unfinished.
The archive should know what was released.
The correction system should know what changed.
Tool Builder should know how a public tool becomes a public tool.
I am aiming at that.
But the calendar does not get to award the version number.
If those systems are not ready when the neat monthly sequence reaches the date corresponding to Day 1.0, then it is not Day 1.0.
Maybe it becomes Day 0.65.
Maybe 0.83.
Maybe 0.97.
The number should describe the state of the institution, not flatter the calendar.
1.0 is earned, not scheduled.
Five months
Five months ago, the central problem was producing anything at all.
Now there is enough output that the system has begun to accumulate consequences.
A wrong assumption can propagate into a tool.
A warning can disappear between interface and PDF.
A speculative failure mode can be mistaken for an observed bug.
A polished artifact can look more certain than the evidence beneath it.
A PASS can become falsely reassuring.
And even a correction system can quietly contain its own escape hatch.
That is what Day 0.5 revealed.
Not that Hedegreen Research is reliable.
Not that it is unreliable.
Something more inconvenient:
Reliability itself has become an engineering problem.
There is enough here now that Hedegreen Research can begin to look convincing.
There is nowhere near enough here that I think you should simply believe it.
Some pieces work.
Some pieces failed.
Some findings were weaker than I first claimed.
Some became stronger after better evidence.
Criticism changed the method itself.
That is evidence of movement.
It is not validation of the institution.
So the instruction at Day 0.5 is not:
Trust Hedegreen Research.
And it is not:
Do not trust Hedegreen Research because AI was involved.
It is simpler.
Inspect it.
Challenge it.
Ask what the claim actually rests on.
And when the system says something passed, ask what was tested.
When it says something failed, ask what evidence established the failure.
When it rejects a criticism, ask whether the rule it invokes genuinely existed before the criticism arrived.
And when the writing sounds convincing, remember that convincing writing is still only writing.
I am trying to build reasons why Hedegreen Research might deserve trust one day.
At five months, whether that system will actually work remains unresolved.