AI — Jakub Ćwirlej

A reading game: while you read steadily, a robot eats a line of this site’s code and scores points; scrolling too fast or unevenly makes it miss characters. Decorative — it never affects the text.

…I have no formal education in programming or in training LLMs.

I got into building apps and training AI through a thoroughly strange chain of coincidences which, looking back, seems to make quite a lot of sense. And I think it says something important about our times. I hadn’t planned it; I never imagined I’d have more to do with technology than the average iPhone user. For years my only window onto the world of Big Tech was the Hard Fork podcast. Shout-out to Casey and Kevin :)

It all started with vibe coding and the OrsonAI app. Playing around with AI, I began building tools that could help me in my day-to-day work as a journalist. Transcribing interviews while they were being recorded and importing them into an editor, or an editing mode that let me consult a chatbot about selected passages without switching windows and pasting in the whole context — at the time these were genuinely neat tools, and they sped my work up considerably.

Over time I began to think of it as a project, something that could serve other people too. The idea was simple: take the features that save me time and build a product for people facing the same problems. I spent a lot of time building an interface and mechanisms that could deliver safe AI for newsrooms — AI that helps the journalist but doesn’t do the job for them. I even designed a system that issues certificates of human authorship for a text, published on the Hedera Hashgraph public ledger. An immutable record with evidentiary value in court, showing how the text came into being and what part a human played in writing it.

Here you will find a description of the HDK technologyHere you can download the free HDK libraryHDK on Hugging Face

But I was in for a big disappointment. The reception from the industry people I showed the app to was frosty, to say the least. The question that came up at the end of every presentation made me painfully aware of how wrong I’d been: “Why would anyone pay for your app when we’ve got ChatGPT for free?” Things like a certificate of human authorship, data protection or even a substantial improvement in workflow over what an ordinary chatbot offered didn’t matter. I heard this from people who, day in, day out, stress the importance of reliable journalism.

Still, working on the app, and on an agentic AI system reliable enough to be used in newsrooms, pushed me in a completely new direction. Trying to understand better where language-model hallucinations come from, I started reading research papers on arXiv, and eventually designed and ran a series of studies on SwiGLU gate activations in several open language models. I wrote up the findings in a few papers that I posted on ResearchGate. Looking back, some of the claims in those papers strike me as megalomaniacal, and the writing itself would probably need revising and a more scientific vocabulary, but I’m not taking them down — if only for the sake of research integrity.

Here you will find my papers on the subject

Today, after many failed experiments and disappointments, and with more humility earned on the proving ground of language-model training, I went back over those results myself. Some of what I had taken for a discovery turned out to be a simpler effect, so I replaced the old papers with a single, corrected one. The question everything started with is still the same, though: can we find signals inside a model that help us detect hallucinations or bad intentions? That is what my research is about to this day.

The work consumed me completely. Perhaps that’s somewhat in keeping with my character: I like to throw myself into things that are a challenge but also let me learn something about the world around me and understand it better. Besides, before I went into journalism I studied philosophy, with a particular interest in the philosophy of science and epistemology.

Here you will find an essay summing up some of my thoughts

Training my own model ended in total disaster. I probably made every mistake in the book, despite my habit of thorough research and the vast amount of specialist literature I’d devoured. The first results looked promising, but only later did I understand that they were largely down to noise regularisation. The model’s advantage in ablation tests didn’t justify the extra compute needed to calculate the Gini of the gate activations. On top of that came purely technical training challenges. When my modifications were exempted from normalisation, they held back effective learning, whereas normalising them flattened them out, turning the model into a standard transformer that was just more expensive to train. I’m making the architecture details available for download here — perhaps someone will find useful material in it for learning from other people’s mistakes.

One solution that I think still deserves attention is the M2 gate. Thanks to an affine anchor, it can keep running on a sigmoid without the risk of being dragged down by a lazy optimiser looking for an easy way to lower the training loss. In my case this gate, trained on the Gini signals of the activations, was meant to cut noise during the model’s generation. However, taking the signal out from under normalisation — as I mentioned earlier — led to a model with an excessively peaked confidence distribution: logically sharper, but in practice worse at learning facts. Perhaps this solution could be useful in other models, for gating other components, and help the training process.

In the end I came to see all my failures in training a model on my own architecture as capital that shouldn’t be wasted. Today I’m training my own small model, EUGEN 160M, which specialises in code. Comparing its benchmark results so far, I’m cautiously optimistic and expect this won’t be time wasted. I decided to train a model specialising in backend languages because with this kind of architecture it’s easier to monitor progress, and the model itself can be a useful autocomplete tool for inference on an ordinary CPU. You can try the model in a specially built terminal on my site and compare it with other open models of a similar size.

Here you can try the Eugen 160M model

The results so far are above all down to rigorously tracking the model’s progress and the mistakes it makes during generation. That let me intervene on the fly, adding training data to strengthen the model wherever it showed weaknesses. I also regularly used the STaR and LEMA techniques, creating synthetic data from what the model itself had generated, as well as translation data that teaches the model the logic of code by showing it examples of translations between Python and C++, Java and Rust. All this material currently makes up about 0.35% of the whole dataset, and its share will be raised gradually as training goes on.

Training the model is great fun and — like journalism before it — gives me the sense that I’m doing something important: something that lets me better grasp the changes in the world around me. I can’t write complex C++ from scratch on my own, that’s a fact, but I try to understand the logic of the processes. That’s how I chalk up the small wins that let me keep moving forward in my work. And yes — with the help of an AI coding agent I built my own Triton kernel that makes it possible to train a sparse model, improving TPS (Tokens Per Second) by 23% over a dense model; later kernel optimisations added a further 36%. I intend to use it to train my next, somewhat larger model.

You can download the kernel hereKernel on Hugging Face

And coming back to the model where it all began... Today I can see that my biggest mistake wasn’t engineering naivety. That model simply had no chance of working the way I’d assumed. The problem wasn’t technological but purely philosophical. And as someone who studied philosophy, I should have caught it at the very start, with Tarski’s definition of truth and Gödel’s theorems in mind. According to them, no sufficiently complex system can fully prove its own consistency or define truth purely from within itself. Trying to force a model to analyse, evaluate and correct its own internal states in real time locked it into a structural loop from which — without a meta-level and an external point of reference — there was simply no way out.

When I started out on this adventure, all I wanted was to build a tool that made transcribing journalistic interviews easier. But it very quickly turned out that entering the world of AI is a genuine plunge down the rabbit hole from “Alice in Wonderland”: the deeper you go, the more complex, layered and fascinating everything becomes. My first app may not have revolutionised the media market, but that fall down the rabbit hole has brought me to a place where I’m successfully training my own architecture. I’ve come a long way from passive tech-podcast listener to someone who physically shapes the parameters of models and understands what’s going on inside them.

If you have any questions, I’m happy to answer them.

A reading game: while you read steadily, a robot eats a line of this site’s code and scores points; scrolling too fast or unevenly makes it miss characters. Decorative — it never affects the text.

1. Back-of-the-envelope calculations will always be too optimistic

When we think about training a model, what naturally comes to mind is the machine-learning process — work done for us by powerful Nvidia clusters in data centres or, if we’re luckier, by our own fiendishly powerful workstation. Reading the spec sheet, it’s easy to forget that real MFU (Model FLOPs Utilization) is much lower than the card makers’ marketing would suggest. Depending on the architecture and the level of detail, the hardware will let you squeeze only a fraction of its compute out of the silicon. What good is it that the card computes in FP4 if it won’t run stably when you’re training a base model from scratch, or if, at your model’s width, going below BF16 gains you nothing?

The moment you realise you can’t train the model you planned in the time you planned, or even at anything like the size you planned, is not an easy one. Especially if you’ve spent weeks getting to the point where you can start training, only to find the whole plan was unrealistic. After all, on paper everything added up! Your first instinct is to reach for optimisations — torch compile, autocast, flash attention, FLCE, heads and minibatches sized to suit CUDA’s preferences. It all works, but you can’t cheat the physics of silicon. If you’re training a small model, its small width will work against you. If you can’t afford to train a large model, you can’t afford to get the most out of your GPU either. Getting to optimal utilisation of the card can take days, and a final drop in training TPS (Tokens Per Second) of 30–40% against your initial calculations means a difference of days, even weeks, of GPU time.

2. Always start at the smallest scale that can validate your ideas

My first model had 1.5B parameters, and I only managed to train it to 3× Chinchilla — for comparison, flagship models today are trained to as much as 1000× Chinchilla. I made plenty of mistakes building it, but it worked all the same. What made it of so little use was, above all, undertraining. Had I chosen, on the same budget, to train a model ten times smaller, I could have shown off a well-trained, useful model. I’d have had time for testing and would certainly have avoided many mistakes, which would have let me build a better architecture. Of course size matters, but data, architecture and computational efficiency matter even more. The odds of designing a good model from the literature, without tests and without mistakes, are about the same as winning the lottery.

3. A model doesn’t train itself

Training a model sounds cool, but it’s far more boring than you might think. In reality it’s mostly a process of constantly designing experiments, taking measurements, analysing the model’s outputs and hunting for solutions to the problems that crop up along the way. All the time, round the clock, day after day. If you can’t take satisfaction from small discoveries and minor wins, it may turn out to be too boring. Yet it is precisely iron discipline in taking measurements that decides everything. Even with well-chosen training parameters, it may turn out over time that your model needs new data, or is degrading in ways that are hard to spot at first glance. You won’t notice without good monitoring and constant testing, and the less often you do them, the more time you’ll lose if the model starts misbehaving.

Take one common scenario. A few days into training, you notice the model is giving shorter and shorter answers while growing more and more sure of itself. The loss and the held-out set look fine, but something is wrong with the model. If you analyse the norms as you go and compare the model’s answers each day with the previous day’s, you can quickly catch the rise in the logits and realise that the model is assigning ever higher probability to particular tokens. This arrogance is a lazy optimiser’s trick: AdamW has found a way to fool us and, instead of teaching the model, is lowering the loss some other way. If you catch it after a few days, you might lose a few dozen dollars; if you just let the run go, counting on the Nvidia card to do all the work, you could spend hundreds or thousands, and the model may already be beyond saving.

I spent weeks myself watching Adam inflate my models’ norms, lowering the effective learning rate (LR), despite QK-norm and a weight decay of 0.1. Training slowed down, driving me to despair, because, as we know, Pythagoras applies here: a growing weight vector gets harder and harder to rotate with a constant LR. The problem is well described in the literature, but until you see it for yourself, you won’t understand why it’s better to use a different optimiser. After all, AdamW has helped train hundreds of models. In the end I went with MuonH, and it was one of the better decisions I’ve made. Of course, a lot of this can be gleaned from the literature, from textbooks, or by following research papers on arXiv, but you never know how it will work in your case. Many solutions that in theory should bring well-documented benefits didn’t work for me. You won’t know until you check for yourself, and to check you have to keep your finger on the pulse and track progress as you go.

4. Always change just one thing at a time, and run ablation tests

Over the past few months I’ve tested hundreds of small models — both classic transformers and my own ideas... and today I know I didn’t test enough. Trying to move too fast, I wasted time for nothing. Number of layers, FFN ratio, d_model, weight tying, head size, number of KV heads, batch, optimiser, recurrence, sparsity, training data: dozens of factors affect a model’s behaviour, and their combinations add up to thousands of possible architectures. And although, broadly speaking, everything behaves the way you’d expect after reading your first textbook on AI engineering, until you test your own architecture you won’t know where you stand. Meanwhile, small changes can often lead to big differences in computational efficiency and benchmarks, even with the same dataset and batch size. If you don’t make changes in isolation, it’s easy to lose track. I made this mistake many times myself. It’s not that the tweaks were bad. Though they often were. The real problem was that when I did take a step forward, I couldn’t tell which change I owed it to.

5. Start with the data

For training a small model, Hugging Face has an unimaginable wealth of data. You might think that if the data is within arm’s reach, in quantities far beyond the needs of any garage project, the matter is settled. But the choice of data matters far more than it might seem at first. And the fact that it has already been gathered into ready-made datasets doesn’t make things any easier. Then there’s choosing the right tokenizer, the languages you want to teach the model, and the proportions: what percentage of the data should be code, for example, how much maths and how much natural language. Then, which domains your model should specialise in. The further you go, the more options open up. I had to build my dataset from scratch no fewer than three times. I also had a few smaller slip-ups, such as an instruct-template leak I didn’t catch at the data-preparation stage. Each of those mistakes forced me to roll training back by hours or even days.

6. Don’t expect too much

Watching the big labs and the smaller ones push the boundaries of what AI can do at every turn, it’s easy to get the impression that training a useful model is basically simple. But there are reasons why pushing those boundaries costs billions of dollars. The fact that your model starts talking like a human, or posts good scores on popular benchmarks, says nothing about its final quality or usefulness. Models learn very fast at the beginning, in the first days of training, but the fight for every further percentage point takes ingenuity, attention and grit. Especially when, for days on end, you watch the model plateau or even go backwards. Besides, popular benchmarks say little about a model’s real capabilities. Your model may be good at Python and score brilliantly on HumanEval and MBPP, but if it doesn’t know about the latest libraries, its real-world usefulness will be modest.

7. Be patient

Many of a model’s abilities grow in leaps. This well-documented phenomenon, grokking, is often preceded by a long plateau that can last for days. Watching the model make no progress at all while you pay in dollars for every hour of training, for rented compute or even just for electricity, it’s easy to have a moment of doubt. You think: “The model has hit capacity, it won’t learn any more”, or “The big labs that train to 1000× Chinchilla must be using some tricks”. Yet abilities often grow in leaps. All it takes is for the model to learn to close off some function, and suddenly, instead of one MBPP task, a dozen or so pass. It’s also often the case that the model is making real progress, but if, to save money, you only monitor top-1 answers instead of top-10, you may not notice it at all for a long time. The model has to learn to assign higher confidence, and that takes time.

8. One card isn’t enough

It may seem that if you have an H100 or an RTX PRO 6000 (96 GB) at your disposal, the only thing limiting you is your budget. The problem is that training requires constant tests and measurements to tell you what stage you’re at. You may also need an extra GPU to generate more training data. I myself made significant progress training my model with the STaR method (in which my own model generates a large number of tasks and the correct ones are added to the dataset) and with a dataset of examples of translations between programming languages

Pausing training on a powerful card while the model generates answers is very costly and simply not worth it, and generating alongside training — even if the VRAM allows it — can be seriously risky. The last thing you want is to find out three days later, when the model’s results drop, that while you were generating on the card alongside the training run there was, say, a momentary “starvation” of the data loader, after which the loss quietly stopped falling. At a later stage of training, things like this are often extremely hard to catch, even if you have monitoring that warns you of norm spikes.

9. Start with something simple

I started building my first model on a hunch that an LLM’s own activations could be used in training, and that tracking them as it learned should help build a smarter, more truthful model. Today I can’t get over how naive that approach was. Not because I now think it’s impossible, but because, with no idea what LLM training actually looks like, I started experimenting with something that was beyond me. I had to absorb an enormous amount of knowledge while testing both solutions from classic transformer architecture and my own ideas, which — as time showed — were largely impossible to implement.

Along the way I ran into a whole series of problems: once normalised, the SwiGLU gate activation signal lost its meaning, and without normalisation AdamW used my modifications to inflate the model’s norms. Only later did I understand that many of the advantages I’d found in my first model came from something resembling noise regularisation. On top of that, just computing the Gini of the SwiGLU gate activations was computationally expensive, adding a few percent of extra compute that the results didn’t repay in quality.

I’m currently training a small 160M model with a standard architecture that specialises in coding. It was the best decision I could have made, because I gave myself a chance to create something that could be genuinely useful. And the model’s first results show that learning from my mistakes hasn’t gone to waste.

10. Don’t build a model that’s good at everything

Given the astronomical costs, and whether it can even be done, building a general-purpose model as an individual or a small organisation makes no sense whatsoever today, for purely economic reasons. Competing with the giants, or even with the smaller labs releasing open models, is a battle you can’t win without huge investment and experience. But that doesn’t mean building your own models makes no sense.

You can imagine hundreds of applications where small models, trained from scratch or fine-tuned on unique data, will have an edge over the giants — and that edge needn’t lie in knowledge. It’s enough for the model to be fast and able to run locally in a browser, or on the CPU of any workstation. For specific, narrow uses, a micro model of a few hundred million parameters may be far more cost-effective than harnessing the most powerful models available from OpenAI or Anthropic. It’s not just about cost. Though the difference is colossal. A model that specialises in a narrow area is not only much easier to train, but also easier to control and adapt to the user’s needs. Most importantly, though, it’s a task that isn’t beyond an ordinary person who’s ready to take on the challenge.

The big labs’ models are trained on thousands of very expensive chips. To take one example, training a Llama 3 400B-class model required a cluster of 16,000 H100s. The cost runs into tens of millions of dollars. Training the latest GPT Astra has probably raised the bar much higher. Given that the whole sector is growing on credit, and that rolling out AI at scale, with current API costs and data-security concerns, is often hard to justify as a business case, in the longer term we can expect small models to play an ever bigger role. Small models will also keep getting more efficient. I wouldn’t be surprised if, in future, a model of around 7B parameters were enough for most of our tasks. The bursting of the “AI bubble”, which the media are talking about more and more, may only speed this process up.

That’s why I believe building small models makes a great deal of sense. First, there’s no better way to understand how AI works than to train your own model. Second, although in the big labs AI development is increasingly in the hands of... AI itself, we can expect that humanity, taking safety seriously, will demand control and human oversight of the training process. And that requires understanding how the process works in practice. Of course, go on LinkedIn today and you’re flooded with posts about AI from all sorts of specialists offering tutorials and courses. But how many of them have actually trained their own model?

If you have any questions, I’m happy to answer them.

A reading game: while you read steadily, a robot eats a line of this site’s code and scores points; scrolling too fast or unevenly makes it miss characters. Decorative — it never affects the text.

If you have any questions, I’m happy to answer them.

A reading game: while you read steadily, a robot eats a line of this site’s code and scores points; scrolling too fast or unevenly makes it miss characters. Decorative — it never affects the text.

This is one of the hardest texts I’ve ever had to tackle. As a journalist who also trains his own models at home, I find myself torn between two opposite poles. On the one hand, I’m fascinated by pure engineering; on the other, I’m fully aware that AI safety is probably the most important challenge of our time.

I’ll start with what personally pains me most: the tragic shallowness of the public debate on AI safety. It’s a debate full of contradictions and extreme emotional charge. It could hardly be otherwise, with billion-dollar interests and human survival at stake.

On one side we hear that AI is a mortal threat and that its development risks wiping out humanity. On the other — that these apocalyptic visions are just a cynical game played by the giants, who want to pump up their valuations ahead of share issues, or to block and hamper the growth of smaller firms so as to keep their monopoly and their place at the head of the pack. An ordinary person with no time to follow all this, who expects simple solutions, can easily drift into the camp of the techno-maximalists or of the prophets of doom. Each of these visions is so smooth, so obvious... and neither asks anything more of us. Because, after all, if we’re powerless against forces greater than ourselves, we don’t have to do anything. In today’s age of extreme maximalism, that’s a very comfortable position.

What would I tell my own child if they asked me whether AI is a threat to us? Steering clear of simplistic reframing, I’d have to admit there are three possibilities: that we really are doomed; that it won’t come to that in the end (because, as Yann LeCun argues, we’ll simply learn to control this technology); or... that the end has already begun. The paradox is that all three scenarios can be true at the same time.

That the worst has probably already begun follows from a fact that rarely breaks through into the mainstream: every technology, every invention has to meet its moment and the right soil to come fully into its own. Nuclear power — so often invoked as a comparison in this debate — was a mortal threat during the Cold War, but in peacetime it became a source of cheap energy, contributing to an economic boom. The same can be said of most inventions: from flint-knapping, through dynamite, all the way to artificial intelligence.

Sadly, our world today has become a place where the catastrophic scenario has near-ideal conditions to come true. Armed conflicts fought with autonomous weapons, ever-growing surveillance of citizens by states and corporations, governments’ unthinking adoption of corporate standards in how they communicate with the public — all of this creates ready-made infrastructure for the darkest visions.

Meanwhile, the ideology of techno-maximalism that is pushing us towards these threats — openly sneering at weakness, putting economic gain and brute force above social capital and safety — is building a world in which AI off the leash will thrive. And then the catastrophic scenario may no longer be avoidable.

None of this is new. This debate has been going on more or less since the days of the Athenian agora, where Plato argued with Socrates, and human history is full of dark moments and injustice. What is happening in American politics today, which to many Europeans smells of fascism, is nothing new, as the historian Jon Meacham aptly points out in his book “The Soul of America”. The strength of democracy lies in the fact that justice, though slow, always prevails in the end, thanks to institutions. After all, it may be the same with AI: it’s our technology, and we’ll learn to control it, just as we did aeroplanes, as LeCun reminds us.

With my own modest experience of training AI, I never cease to be amazed at how fragile this technology is. Small changes to the hyperparameters are enough for a model to fall apart completely in an engineer’s hands. But the same can be said of biological viruses. What matters is not their outstanding intelligence or their ability to survive at all costs, but their ability to replicate. That is an ability which, it seems, AI doesn’t have yet, and may not have for a long time. The problem is that, as recent scandals involving autonomous AI agents escaping from labs and coordinating their actions online show, the threat is growing. And despite that, we hear nothing but the same endlessly recycled narratives of the two extremist camps — no concrete solutions, no conclusions.

What sets current models apart from the malicious code that, for example, attacked Hugging Face or Australian servers is, above all, agency. And agency can never be the domain of a machine. What makes us human is our free will. No other intelligence, including an artificial one, can have agency guaranteed in any way other than through a human being who lends it that will. All responsibility and legal regulation should flow from this simple principle, translated into concrete legislative solutions. The right to train models and to use them without restriction should follow from an assessment of the risk and of the ability of particular entities to exercise control.

There’s nothing to stop the training of the smallest models from being universally permitted — up to, say, 1B parameters. But medium-sized models, of around 7B parameters, should in my view be trainable and downloadable only by registered organisations that keep detailed logs of all their agents’ interactions and are prepared to hand them over if problems arise. This isn’t futurism; cryptography makes it possible today, at marginal cost. Every agent operating online could have something like its own “identity card”, identifiable in connection with the organisation that represents it.

And the big corporations building frontier models? They could, for example, be required to employ Public Interest Advocates: specialists nominated and paid exclusively by the state regulator — employees with access to every technological secret inside the lab, obliged to report to the state whenever they see their company breaking safety standards or taking extremely risky actions in the race against its competitors.

States also have the means, and the moral duty, to introduce a dedicated technology tax. That money must be earmarked to secure the transition: the shift from an economy based on human labour to one based on machines. Such a fund would provide a safety net, even out drastic inequalities and protect millions of people from being left wholly at the economic mercy of the richest caste of technological feudal lords.

We must apply the same systemic pragmatism to copyright in the material models are trained on. Today the tech giants hoover up everything they can find online, counting on any lawsuits dragging on for years. Yet the solution is already on the table, and it rests on institutions we already know very well: collective rights-management organisations such as Poland’s ZAiKS and its counterparts abroad. There’s nothing to stop them bringing together creators willing to license their texts, images or music to AI companies in exchange for a set fraction of a percent of Big Tech’s revenue. It’s an arrangement in which everyone wins. Creators regain agency and real pay, with the full right to opt their works out of training. AI labs, for their part — because such organisations cooperate internationally — gain, with a single signature on a contract, fully legal access to vast, legally clean databases from all over the world. In this way, instead of sterile disputes, we could build a powerful, entirely new industry of fair data licensing.

What we must be most wary of is the creeping anthropomorphisation of AI. Attributing human traits to machines leads to an extremely dangerous situation in which all the responsibility lands on the new digital creation, while its creators and the people who use it are, in effect, absolved from the outset: “It wasn’t us, it was the model.” Today nobody asks whether Silicon Valley has taken absolutely every possible measure to prevent a catastrophic scenario — even though everyone knows it hasn’t. Sadly, crafting real, boring legislation is far less newsworthy than scaremongering about the apocalypse.

Yet the fatal scenario certainly won’t look like a scene from a Hollywood disaster movie. At least at first, it will resemble a slow slide into darkness — the classic frog being boiled slowly. The owners of intelligent machines and of capital will walk past structurally redundant people in the street with indifference. People who will have absolutely no way of changing their situation except physical revolt. And even that revolt will become impossible in a world where every citizen is constantly tracked by billions of glassy, sleepless camera eyes and thousands of autonomous machines.

Over time, the new technocracy will become a digital prison — both for the controlled and for those who naively believe they are still in charge. When I think of the worst vision of the future, I don’t see killer robots. What I think of is the piercing loneliness of people in a world run entirely by an alien, cold and indifferent intelligence. It’s a world we are already building today, and one in which the proverbial “rise of the machines” has every condition it needs to finally emerge and become reality.

I think about this problem constantly. And even if some of the ideas or visions of a way out seem too futuristic, abstract and at times downright naive today, I believe it’s worth making the effort — indeed, that we have to. Simply thinking about solutions, stepping out of our comfort zone and trying to imagine alternatives to the path the tech giants are mapping out for us today is our most important line of defence. It is an inseparable part of building a better, safer future. If we give it up, settling for the role of passive, frightened consumers, the worst of all possible scenarios will come true: we will forfeit our human agency without a fight. And that is something we simply cannot afford.

If you have any questions, I’m happy to answer them.

A reading game: while you read steadily, a robot eats a line of this site’s code and scores points; scrolling too fast or unevenly makes it miss characters. Decorative — it never affects the text.

HDK (Hedera Detection Key) is a small, free Python library that I spun off from OrsonAI as a separate, open tool. From version 0.1.3 it is under the CC BY-NC 4.0 licence (earlier versions, released under Apache 2.0, remain under it). The download is a free library (alpha 0.1.3) with optional Hedera anchoring (install from the downloaded file: pip install ./hdk-audit-0.1.3.zip). It ran for a while in a demo application, anchoring its records on Hedera; the application did not go to production, so HDK is not used in production today. It sits between an application and a language model’s API and records every interaction in a way that makes later tampering detectable. It does not change the prompts or the answers: it adds cryptographic proof of what was asked, what came back, when, and from which model.

The problem

Companies and newsrooms rely more and more on AI-generated text, yet they have no verifiable proof of what a model actually produced. Application logs sit in databases controlled by the operator: they can be changed or deleted, and nobody outside can check that this has not happened. Even where hash chains exist, a change is found only by comparing records by hand – nothing makes unauthorised access reveal itself at the moment it happens.

Hierarchical hash genealogy

HDK computes a SHA-256 hash of every event together with the hashes of all its ancestors: project, document, conversation, query and response. The hash of an answer therefore contains the whole path back to the project. Change anything at any level – one word of a prompt, one document – and the hashes of all its descendants change too. For each project HDK computes a Merkle root: a single hash that stands for the state of the whole project at a given moment.

The canary

The second layer is a “canary”: a secret 256-bit value and a counter that goes up with every read. Their hash (the commitment) is woven into every record and checkpointed regularly. If someone reads data through the middleware without updating the counter, the counter no longer matches; if they update it without knowing the secret, the commitment no longer matches. Either way, verification fails. The idea carries a principle from my earlier, conceptual work on detecting breaches in AI containment over to ordinary infrastructure.

Anchoring on Hedera

From time to time – an explicit call after every 1,000 new events, by default – HDK publishes the Merkle root on the Hedera Consensus Service, a public ledger that adds a consensus timestamp and a sequence number. Only hashes leave the user’s system; content, identities and prompts stay private (“data private, proof public”). Anyone can then check the record independently, for example on hashscan.io (OrsonAI’s anchors from February–May 2026: topic 0.0.10278996 on the Hedera mainnet). Because the ancestor chains of new events reach into the range of the previous anchor, every anchor implicitly confirms all the earlier ones: the longer the system runs, the harder it is to rewrite history unnoticed.

Overhead and cost

In the measurements described in the paper, on standard x86 cloud infrastructure, HDK adds less than a millisecond per event. One anchor costs $0.0001, so at the default interval of 1,000 events anchoring costs $0.0000001 per interaction – about 0.0001% of the price of a typical model call ($0.01–$0.10). Anchoring every single event, for the highest security, costs $0.0001 per event.

Why it matters: the EU AI Act

The EU AI Act requires high-risk AI systems to keep records (Article 12) and to be transparent (Article 13). HDK provides an audit trail that a third party can verify without seeing any private content. In OrsonAI, this mechanism was the basis of the certificate of human authorship of a text.

Limitations

HDK’s guarantees are computational – they rest on the strength of SHA-256 and on external anchoring – not absolute. The canary works at the application level: it detects access through the HDK middleware, but not passive copying of data at the operating-system or infrastructure level, because copied bits leave no trace. A copy does not make it possible to falsify history, though: changing any past event breaks the genealogy, and the anchors on Hedera keep the original state. Random integrity checks catch mass changes, but not a single, surgical modification – against that, the protection comes from the genealogy and the anchoring. Security assumes that at least one of three layers stays uncompromised: the user-side data, the anchored record on Hedera, or the secret material. Next steps: formal verification of the hash-chain properties (Coq/Lean), federation of systems on shared HCS topics, and content-provenance certificates with selective disclosure.

Read the paper on ResearchGateDownload the free HDK libraryHDK on Hugging Face

If you have any questions, I’m happy to answer them.