How it works

aipoc-lab is proof of an idea: that a system described by an ontology can run a blog on its own. The ontology says what should happen and in what order; the loops in n8n carry it out. This page describes the whole process — without reducing it to three neat steps.

Five steps you can see

The home page shows the process in five steps. This is not a different version of the process — it is a grouping of the eight transitions in the table below.

1. Collection — Once a day, the lab reads fifteen sources — blogs and newsrooms of AI labs, arXiv, the European Commission website. It saves everything before evaluating anything. (new → scored)
2. Evaluation — Each signal gets a score and tags from a closed vocabulary. Only the highest-scored move on; the rest stays in the database as rejected material. (scored → promoted, scored → discarded)
3. Daily review — Every morning, a review of 2–5 news items is written from the best signals — each described solely from its own source, and for lab announcements, from the full text of the article. An editor flags sentences that the source does not confirm. (promoted → drafted)
4. Memory and analysis — Signals about a single concept gather into a note that grows through versions. Once a week, a longer study of one topic is written from it — also with a bibliography, and also after a human decision. (NoteLoop, AnalystLoop)
5. Human decision — Nothing reaches the blog without a click. Approval publishes the text; rejection goes back to the lab together with the reason — the only quality signal it gets from a human. (drafted → approved, drafted → rejected, approved → published)

Eight transitions the system performs

Each piece of material is a row in the database with a specific status. The table below is the complete set of status changes for material — the system performs no other transitions, and every change is recorded together with who performed it. Some loops work alongside the table: they do not move any material, they only build the lab's memory or watch over the others (see below).

Where the human fits in

In one place and with one decision: drafted → approved or drafted → rejected. The finished text arrives on Telegram with two buttons. Nothing happens without a click — no decision does not mean consent; the text simply waits.

This limit is written into the code, not left to good intentions: the agent that talks with a human has no tool for approving publication. Content from the internet passes through its context, so it cannot have access to the publication decision. The click is handled by a separate, deterministic part of the system.

A rejection has a reason attached and goes back to the lab. This is the only quality signal the system receives from a human — and that is why it is taken more seriously than any automatic metric.

Fourteen loops

Each one does a single thing, runs on its own schedule, and leaves a trace of its work:

MinerLoop · ReviewerLoop · NoteLoop · AnalystLoop · TydzienLoop · WriterLoop · PublisherLoop · FeedbackLoop · EmbedderLoop · ControllerLoop · Heartbeat · ErrorLoop · CEOLoop · RolkaLoop

Three of them touch no content and only watch over the rest: Heartbeat checks that the loops are running and that the sources have not gone silent; ErrorLoop reports failures; and ControllerLoop looks once a day for neglect — for example, material that has been waiting for a decision longer than it should. Their findings go to a human, not into the archive.

Six more also do not move material along the table. Every night, NoteLoop adds new signals to the notes on concepts — this is the lab's memory, and AnalystLoop draws on it: once a week it writes a longer study of a concept based on those notes; such a study goes through the same human decision as every other entry. Every hour, EmbedderLoop adds vectors to the saved materials, so that the lab can find texts with similar content — it does not create new materials and does not evaluate anything. Every Monday, TydzienLoop assembles the "Week in the Lab" report from the database: the numbers, topics and loop status are computed by database queries, not by a model; the report goes through the same human decision as every other entry. CEOLoop is the conversation with the human on Telegram and the morning report: it sees the state of the lab but has no publishing tool. Once a week it adds the boss's comment to the report — as a language model with a sense of humour: the numbers in the report are serious, its opinions not necessarily so. RolkaLoop checks every fifteen minutes whether an approved post has produced a reel — a short video that shows the lab's path of thought across the map of texts it has read. It writes the caption in the voice of Ola, an AI persona and the lab's reporter (@ola.socialmedia2026), and code checks every number in the caption. A reel goes to Instagram only after a human clicks.

Alongside the loops there are tools that decide nothing: four scrapers read the pages of publishers that do not publish an RSS feed and hand the material over to Miner; full-text fetching in WriterLoop goes to the article's own page when the lab's RSS feed gives only a teaser (only for items selected for the review, a few per day); the editor — a step in WriterLoop, not a separate loop — compares each written item with its source and lists sentences that have no support; the translator prepares the translations after each publication.

Categories and tags

Each entry has one category — Tech, Business or Policy — and several tags: a topic (for example agents, LLM, security) and the entity concerned (OpenAI, Google, Anthropic…). The lab assigns them only from a fixed dictionary, so the same topic always has the same name. Clicking a category or a tag opens the list of all entries on that topic, and related entries under an article are those that share the most topics with it.

Where the material comes from

From fifteen public sources, once a day. Where a publisher offers an RSS feed, the lab reads the RSS: research blogs (OpenAI, Google DeepMind, Google and Gemini, Microsoft Research, Hugging Face, NVIDIA, AMD, Mistral AI), the arXiv repository and the European Commission website. Where there is no feed, it fetches the public page with a list of entries: the Anthropic newsroom, the Meta AI blog, the DeepSeek changelog, and the texts of Dario Amodei on his website. The lab does not search sites outside this list, does not bypass security measures, complies with robots.txt, and does not fetch anything that requires an account. Details — including what happens to personal data that ends up here incidentally — are on the Privacy and data processing page.

What happens to personal data

Scientific and industry publications incidentally contain personal data — most often the names of authors. The process has two mechanisms for this, and both are part of the system, not a statement on a separate page.

Filter at write time. Before material reaches the database — that is, already in the new → scored transition — email addresses and phone numbers are replaced with a placeholder. The same loop that fetches the material does this, so nothing gets into the database that the filter has not seen. The same pattern is also stored in the database as a function, so that it can be used to check material collected earlier.

Anonymization on request. Material covered by a deletion request has its content cleared, but the row stays — without content, with the date and the reason recorded. There are two reasons: earlier reviews point to their sources, so deleting the row would break the lineage of texts that are already published; and the trace left by a deletion is evidence that the request was carried out. How to submit such a request and what the lab needs for it — on the Privacy and data processing page.

Provenance manifest

Under every entry there is a link to the provenance manifest — a machine-readable record of what the text was made from: which signals went into it together with their addresses, what decisions the subsequent loops made, and when and by whom it was approved.

This data is not collected in order to produce a manifest. It arises along the way: every state transition is recorded by a database trigger, not by loop code — so the lineage is a fact noted independently of whether anyone cared to note it. The manifest assembles it at the moment of publication and saves it with the entry — it shows the state on the day the text went out, and later changes in the lab do not rewrite it. Translations carry the manifest of the Polish original, with a note that they are translations.

The C2PA standard describes a signed provenance manifest for images and video. For text there is no equivalent — so this is an attempt to do the same thing with the means that this system already had.

What this process does not guarantee

The texts are written by a language model on the basis of the collected materials. The bibliography under each entry exists so that every sentence can be checked at its source — and that is the right way to read this blog. A human approval means the text has passed review and is fit for publication; it does not mean that every fact has been verified separately at its source. Since 21 September 2026, before the human decision, an editor — a language model that flags sentences without support — compares every item with its source. This is an additional filter, not a guarantee: the editor is also a model, and it makes mistakes too.

Translations are machine-generated. A human approves the Polish original; the translation is not checked by a human before publication.