DEV Community: Omar Baruzzo

Koji je prompt donio tu odluku?

Omar Baruzzo — Tue, 06 Oct 2026 11:30:21 +0000

TL;DR: prompt u repositoryju, model pinan na točnu verziju (nikad alias), retrieval index s verzijom, svaka promjena kroz eval set, i trojka zabilježena uz svaku odluku.

Uzmite bilo koju odluku koju je vaša AI funkcionalnost donijela u produkciji prije tri tjedna i postavite jednostavno pitanje: koji ju je prompt proizveo? U većini timova iskren odgovor glasi "vjerojatno trenutni, osim ako ga netko nije promijenio". To nije odgovor za incident review, za klijenta ni za revizora.

Tri stvari mijenjaju ponašanje, a nijedna ne prolazi kroz release

Ponašanje AI funkcionalnosti ne ovisi samo o kodu. Prompt određuje kako se model instruira. Model određuje kako se te instrukcije tumače. Retrieval index određuje koji kontekst model vidi. Promijeni bilo koju od tih triju stvari i isti input može dati drugačiju odluku.

U mnogim sustavima nijedna od njih ne prolazi kroz release. Prompt živi u retku baze ili u admin panelu i mijenja se izravno u produkciji. Model se poziva preko aliasa kao što je "latest", a provider taj alias prebacuje na novu verziju po svom rasporedu. Index se ponovno gradi noćnim jobom. Nitko ništa ne pokvari, a ponašanje se ipak pomakne, i kad netko pita zašto, nema se s čim usporediti.

Tretirati ih kao release artefakte

Rješenje nije novi alat. To je release disciplina koju već primjenjujemo na kod, proširena na dijelove koji najviše mijenjaju ponašanje.

Prompt je kod: ide u repository, prolazi review, ima verziju i ide u produkciju s releaseom. Model je dependency: pinaš točan identifikator verzije koji provider izlaže, nikad alias, i nadograđuješ ga namjerno. I index ima verziju, vezanu uz dokumente i embedding model koji su ga izgradili.

Svaka promjena bilo koje od tih triju stvari prolazi isti gate: eval set na novoj kombinaciji, usporedba s onom u produkciji, pa release. Rollback je redeploy prethodne kombinacije, ne prompt prepisan po sjećanju.

Bilježiti trojku uz svaku odluku

Zadnji korak daje smisao ostalima. Svaka odluka bilježi na čemu je radila: verziju prompta, identifikator modela, verziju indexa, uz input i output.

Tako incident review kreće od činjenica: ova odluka, ovaj prompt, ovaj model, ovi dokumenti. Može se reproducirati i usporediti s trenutnim ponašanjem. Kad revizor ili strani partner pita zašto je sustav odlučio tako, to je jedini odgovor koji nije nagađanje.

Za tvrtke u regiji koje isporučuju stranim klijentima to nije novi alat ni novi trošak. Versioning, pinanje i release gate već postoje; samo ih treba primijeniti na dio sustava koji najviše mijenja ponašanje.

Gdje danas živi prompt koji imate u produkciji, i biste li znali reći koja je verzija donosila odluke prošlog mjeseca?

Articolo originale: https://www.omarbaruzzo.it/hr/blog/quale-prompt-ha-deciso

Quale prompt ha preso quella decisione?

Omar Baruzzo — Tue, 06 Oct 2026 11:26:39 +0000

TL;DR: prompt nel repository, modello fissato a una versione esatta (mai un alias), indice del retrieval versionato, ogni modifica dal set di eval, e la terna registrata con ogni decisione.

Prendete una decisione presa in produzione dalla vostra funzione AI tre settimane fa e fate una domanda semplice: quale prompt l'ha prodotta? Nella maggior parte dei team la risposta onesta è "probabilmente quello attuale, a meno che qualcuno non l'abbia cambiato". Non è una risposta che si può dare in una revisione di incidente, a un cliente o a un revisore.

Tre cose cambiano il comportamento, e nessuna passa dal rilascio

Il comportamento di una funzione AI non dipende solo dal codice. Il prompt decide come viene istruito il modello. Il modello decide come quelle istruzioni vengono interpretate. L'indice del retrieval decide quale contesto il modello vede. Basta cambiare una delle tre e lo stesso input può produrre una decisione diversa.

In molti sistemi nessuna delle tre passa da un rilascio. Il prompt sta in una riga di database o in un pannello di amministrazione e si modifica direttamente in produzione. Il modello è richiamato con un alias come "latest", e il fornitore sposta quell'alias su una versione nuova secondo il suo calendario. L'indice viene ricostruito da un job notturno. Nessuno rompe niente, eppure il comportamento si sposta, e quando qualcuno chiede perché non c'è niente con cui confrontare.

Trattarli come artefatti di rilascio

La soluzione non è un nuovo strumento. È la disciplina di rilascio che già applichiamo al codice, estesa alle parti che cambiano di più il comportamento.

Il prompt è codice: sta nel repository, passa dalla review, ha una versione e arriva in produzione con un rilascio. Il modello è una dipendenza: si fissa l'identificativo esatto di versione esposto dal fornitore, mai l'alias, e lo si aggiorna di proposito. Anche l'indice ha una versione, legata ai documenti e al modello di embedding che l'hanno costruito.

Per una software house .NET non c'è niente di nuovo da imparare: è la stessa cura che si mette nel fissare la versione di un pacchetto NuGet. Ogni modifica a uno dei tre passa dallo stesso cancello: set di eval sulla nuova combinazione, confronto con quella in produzione, poi rilascio. Il rollback è un redeploy della combinazione precedente, non un prompt riscritto a memoria.

Registrare la terna con ogni decisione

L'ultimo passo dà senso agli altri. Ogni decisione registra la terna su cui ha girato: versione del prompt, identificativo del modello, versione dell'indice, accanto a input e output.

Così una revisione di incidente parte dai fatti: questa decisione, questo prompt, questo modello, questi documenti. La si può riprodurre e confrontare col comportamento attuale. L'AI Act chiede ai sistemi ad alto rischio la registrazione automatica degli eventi; senza la terna, quel registro dice cosa è successo ma non su quale configurazione.

Non c'è niente di esotico: versioni, dipendenze fissate, cancelli di rilascio. Ci siamo solo dimenticati di applicarli alla parte del sistema che cambia di più il comportamento.

Dove vive oggi il prompt che avete in produzione, e sapreste dire quale versione ha preso le decisioni del mese scorso?

Articolo originale: https://www.omarbaruzzo.it/it/blog/quale-prompt-ha-deciso

Which prompt made that decision?

Omar Baruzzo — Tue, 06 Oct 2026 11:22:46 +0000

TL;DR: prompt in the repo, model pinned to an exact version (never an alias), retrieval index versioned, every change through the eval set, and the triple recorded with every decision.

Pick any decision your AI feature took in production three weeks ago and ask a simple question: which prompt produced it? In most teams the honest answer is "probably the current one, unless someone changed it". That is not an answer you can give to an incident review, to a customer, or to an auditor.

Three things change behaviour, and none of them is in the release

An AI feature's behaviour depends on more than its code. The prompt decides how the model is instructed. The model decides how those instructions are interpreted. The retrieval index decides what context the model sees. Change any of the three and the same input can produce a different decision.

In many systems none of the three goes through a release. The prompt lives in a database row or an admin panel, edited directly in production. The model is referenced by an alias such as "latest", and the provider moves that alias to a new version on its own schedule. The index is rebuilt by a nightly job. Nobody breaks anything, yet behaviour drifts, and when someone asks why, there is nothing to compare against.

Treat them as release artifacts

The fix is not a new tool. It is the release discipline we already apply to code, extended to the parts that change behaviour most.

The prompt is code. It lives in the repository, goes through review, has a version and ships with a release. The model is a dependency: pin the exact version identifier the provider exposes, never the alias, and upgrade it deliberately, like any other dependency. The retrieval index gets a version too, tied to the documents and the embedding model that built it.

Every change to any of the three goes through the same gate: run the eval set against the new combination, compare it with the one in production, then release. Rollback means redeploying the previous combination, not retyping a prompt from memory or hoping the provider still serves the old model under the old name.

Record the triple with every decision

The last step is what makes the rest useful. Every decision the system takes records the triple it ran on: prompt version, model identifier, index version. Put it next to the input and the output in whatever log you keep.

With that, an incident review starts from facts: this decision, this prompt, this model, these documents. You can reproduce it, compare it with current behaviour and say whether a change caused it. Without it, every answer about past behaviour is a guess, and so is every answer to someone who has the right to ask.

None of this is exotic. It is versioning, pinning and release gates. We just forgot to apply them to the part of the system that changes behaviour the most.

Where does the prompt you run in production live today, and could you say which version took last month's decisions?

Articolo originale: https://www.omarbaruzzo.it/en/blog/quale-prompt-ha-deciso

Vjerojatno ti ne treba fine-tuning

Omar Baruzzo — Thu, 01 Oct 2026 11:31:38 +0000

TL;DR: modelu najčešće nedostaje kontekst, ne sposobnost. Bez eval seta nema fine-tuninga. Prompt, retrieval, evali, pa možda weights.

Kad AI funkcionalnost ne radi dobro, fine-tuning je često prvi lijek na stolu. Zvuči kao ozbiljan inženjering: dataset, training run, model koji je "naš". U praksi je često najskuplji način da se ne pogleda zašto funkcionalnost ne radi.

Modelu rijetko nedostaje sposobnost

U slučajevima koje viđam, base model je obično sposoban za zadatak. Ono što mu nedostaje je kontekst. Retrieval vraća krive dokumente, ili prave u krivom redoslijedu. Instrukcije su se skupljale mjesecima i sada si proturječe. Input stiže napola parsiran: loše pročitan PDF, tablica spljoštena u paragraf, polje koje nedostaje. Od modela se traži odgovor na pitanje koje ne vidi dobro.

Ništa od toga se ne rješava promjenom weightsa. Istrenirani model koji dobije isti pokvareni kontekst daje iste krive odgovore, samo s više samopouzdanja i većim računom.

Fine-tuning zamrzava snimku

Fine-tunirani model nauči proces kakav je bio kad je dataset nastao. Proces se mijenja: cjenik, propis, klijent doda iznimku. Istrenirani model ne prati. Svaka značajna promjena znači novi dataset, novi training run i novu validaciju.

Veže te i za određenu verziju base modela. Provideri redovito izdaju nove verzije; tuning napravljen na prethodnoj treba ponoviti ili napustiti, dok poboljšanja na razini prompta prelaze besplatno.

Za tvrtke u regiji koje rade za strane klijente, često po fiksnoj cijeni, to je trošak koji se ponavlja, a u ponudi ga nije bilo.

Bez eval seta nema fine-tuninga

Odlučujući argument je jednostavniji. Bez eval seta — fiksne zbirke stvarnih slučajeva s očekivanim ishodom, koja se pokreće na svaku promjenu — ne možeš znati je li tuning pomogao. Imat ćeš dojam, nekoliko uspješnih demo verzija i trošak.

Ako nemaš eval set, nisi spreman za fine-tuning. Ako ga imaš, prvo ga pokreni protiv boljeg prompta i boljeg retrievala. Često to zatvori većinu razlike, i znat ćeš točno koliko je ostalo.

Kad ima smisla

Fine-tuning zaslužuje mjesto na uskim, stabilnim zadacima s velikim volumenom: fiksni output format, klasifikacija koja se ne mijenja svaki mjesec, posao koji želiš prebaciti na manji i jeftiniji model nakon što je veliki pokazao kako izgleda dobar rezultat. U tim slučajevima to ti kažu evali, brojkama koje si sam izmjerio, a ne dojam iz jednog sastanka ili jedne uspješne demonstracije pred klijentom.

Redoslijed je bitan: prompt, retrieval, eval set, onda — možda — weights.

Koji ste zadnji problem pokušali riješiti fine-tuningom, i što su rekli evali?

Articolo originale: https://www.omarbaruzzo.it/hr/blog/non-ti-serve-il-fine-tuning

Probabilmente non ti serve il fine-tuning

Omar Baruzzo — Thu, 01 Oct 2026 11:27:21 +0000

TL;DR: quasi sempre al modello manca contesto, non capacità. Senza eval set, niente fine-tuning. Prompt, retrieval, eval, poi forse i pesi.

Quando una funzione AI rende poco, il fine-tuning è spesso il primo rimedio sul tavolo. Sembra ingegneria seria: un dataset, un addestramento, un modello "nostro". Nella pratica è spesso il modo più costoso per non guardare perché la funzione rende poco.

Al modello raramente manca capacità

Nei casi che vedo, il modello di base è di solito in grado di fare il lavoro. Quello che gli manca è contesto. Il retrieval restituisce i documenti sbagliati, o quelli giusti nell'ordine sbagliato. Le istruzioni si sono accumulate per mesi e ora si contraddicono. L'input arriva letto a metà: un PDF estratto male, una tabella appiattita in un paragrafo, un campo mancante. Al modello si chiede di rispondere a una domanda che non vede bene.

Niente di questo si sistema cambiando i pesi. Un modello addestrato che riceve lo stesso contesto rotto produce le stesse risposte sbagliate, solo con più sicurezza e una fattura più alta.

Il fine-tuning congela una fotografia

Un modello addestrato impara il processo com'era quando è stato costruito il dataset. Il processo invece si muove: cambia il listino, cambia una norma, il cliente aggiunge un'eccezione. Il modello addestrato non segue. Ogni modifica significativa è un nuovo dataset, un nuovo addestramento, una nuova validazione.

Ti lega anche a una versione specifica del modello base. I fornitori rilasciano versioni nuove con regolarità; un tuning costruito sulla precedente va rifatto o abbandonato, mentre i miglioramenti fatti a livello di prompt si portano dietro gratis.

Per una software house .NET che lavora a prezzo fisso è un costo ricorrente che nel preventivo non c'era. E con l'AI Act modificare un modello porta domande di documentazione che una modifica al prompt non porta.

Senza eval set, niente fine-tuning

L'argomento decisivo è più semplice. Senza un set di eval — una raccolta fissa di casi reali con l'esito atteso, eseguita a ogni modifica — non puoi sapere se il tuning ha aiutato. Avrai un'impressione, qualche demo riuscita e un costo.

Se non hai un set di eval, non sei pronto per il fine-tuning. Se ce l'hai, provalo prima contro prompt migliori e retrieval migliore. Spesso chiude gran parte del divario, e saprai esattamente quanto ne resta.

Quando ha senso

Il fine-tuning si guadagna il posto su compiti stretti, stabili e ad alto volume: un formato di output fisso, una classificazione che non cambia ogni mese, un lavoro da spostare su un modello più piccolo ed economico dopo che quello grande ha mostrato com'è il risultato buono. In quei casi te lo dicono le eval, con numeri misurati da te.

L'ordine conta: prompt, retrieval, set di eval, poi — forse — i pesi.

Qual è l'ultimo problema che avete provato a risolvere col fine-tuning, e cosa dicevano le eval?

Articolo originale: https://www.omarbaruzzo.it/it/blog/non-ti-serve-il-fine-tuning

You probably don't need fine-tuning

Omar Baruzzo — Thu, 01 Oct 2026 11:21:43 +0000

TL;DR: most underperforming LLM features lack context, not capability. No eval set, no fine-tuning. Prompt, retrieval, evals, then maybe the weights.

When an AI feature underperforms, fine-tuning is often the first remedy on the table. It sounds like serious engineering: a dataset, a training run, a model that is "ours". In practice it is frequently the most expensive way to avoid looking at why the feature underperforms in the first place.

The model rarely lacks capability

In the failures I see, the base model is usually capable of the task. What it lacks is context. The retrieval step returns the wrong documents, or the right ones in the wrong order. The instructions have accumulated over months and now contradict each other. The input arrives half-parsed: a PDF read badly, a table flattened into a paragraph, a field missing. The model is asked to answer a question it cannot see properly.

None of that is fixed by changing the weights. A tuned model fed the same broken context produces the same broken answers, only with more confidence and a higher bill.

Fine-tuning freezes a snapshot

A fine-tuned model learns the process as it was when the dataset was built. The process keeps moving: the catalogue changes, a regulation changes, the customer adds an exception. The tuned model does not follow. Every meaningful change means a new dataset, a new training run and a new validation.

It also ties you to a specific base model version. Model providers release new versions regularly; a tuning built on the previous one has to be redone or abandoned, and prompt-level improvements that transfer for free do not come with it.

No eval set, no fine-tuning

The decisive argument is simpler. Without an eval set — a fixed collection of real cases with expected outcomes, run on every change — you cannot tell whether the tuning helped. You will have an impression, a few good demos, and a cost.

If you have no eval set, you are not ready to fine-tune. If you have one, run it against better prompts and better retrieval first. Often that closes most of the gap, and you will know exactly how much remains.

When it does make sense

Fine-tuning earns its place on narrow, stable, high-volume tasks: a fixed output format, a classification that does not change every month, a job you want to move to a smaller and cheaper model once the large one has shown what good looks like. In those cases the evals tell you so, with numbers you measured yourself.

The order matters: prompt, retrieval, eval set, then — maybe — the weights.

What was the last problem your team tried to solve with fine-tuning, and what did the evals say?

Articolo originale: https://www.omarbaruzzo.it/en/blog/non-ti-serve-il-fine-tuning

Tko drži ključ?

Omar Baruzzo — Tue, 29 Sep 2026 11:30:15 +0000

TL;DR: odvoji hot i admin key, admin ulogu stavi iza multisiga ili KMS-a, napiši proceduru rotacije, planiraj da ljudi odlaze.

Smart contract koji je prošao audit daje preciznu vrstu sigurnosti: kod radi ono što kaže. Ne govori ništa o drugoj polovici sustava, a to je tko može potpisivati. Svaka on-chain aplikacija u produkciji ovisi o barem jednom private keyu koji je bitan — onome koji potpisuje anchoring transakcije, onome s admin ulogom, onome koji može pauzirati, napraviti upgrade ili mint. Tko kontrolira te ključeve, kontrolira sustav, koliko god kod bio dobar.

Gdje ključ obično živi

U većini projekata ključ nastaje tijekom demo faze. Završi u environment variableu ili config datoteci na serveru, jer je to najbrži način da prva transakcija prođe. Onda demo postane produkcija, server se klonira u staging, napravi se backup, kolega kopira datoteku za debug, i nitko se ne vrati.

Private key nije lozinka. Nema reset linka. Ako procuri, tko ga ima ima točno tvoj autoritet, a lanac vas dvojicu ne može razlikovati. Rotacija, kad je contract dopušta, je transakcija potpisana upravo ključem zbog kojeg se brineš.

Custody je operativni dizajn

Korisna pitanja nisu kriptografska. Radi se o ulogama, limitima i ljudima.

Odvojiti ključeve po tome što mogu. Hot key koji potpisuje rutinske transakcije ne smije biti ključ koji mijenja pravila. Treba mu dati najmanju ulogu koju contract dopušta i samo sredstva potrebna za sljedeće razdoblje.

Moćnu ulogu staviti iza više od jedne osobe. Admin ili upgrade uloga ide iza multisiga, ili u KMS ili HSM iz kojeg se ključ ne može izvesti, uz odobrenje više osoba. Jedan laptop nije custody model.

Napisati proceduru rotacije prije nego zatreba. Koji ključ zamjenjuje koji, tko potpisuje promjenu, koliko dugo stari ostaje valjan, kako se obavještavaju partneri. Napisano i isprobano, ne improvizirano tijekom incidenta.

Planirati da ljudi odlaze. Inženjer koji je sve postavio jednom će promijeniti posao. Ako jedino operativno znanje o ključevima ode s njim, sustav ima single point of failure s otkaznim rokom.

Zašto ide u design review

Za tvrtke u regiji koje rade sa stranim partnerima, custody je prvo pitanje u due diligenceu. Banka, revizor ili partner iz inozemstva pitat će tko može pomaknuti sredstva ili promijeniti contract prije nego što pitaju išta o kodu. Za organizacije koje su u opsegu NIS2, upravljanje ključevima već je dio sigurnosnih mjera koje trebaju dokumentirati. U oba slučaja odgovor mora postojati prije pitanja.

Custody je dio arhitekture. Ako se pojavi samo u bilješkama za primopredaju, nije dizajniran.

Gdje danas živi ključ koji kontrolira vaš contract, i tko još može potpisati njime?

Articolo originale: https://www.omarbaruzzo.it/hr/blog/chi-tiene-la-chiave

Chi tiene la chiave?

Omar Baruzzo — Tue, 29 Sep 2026 11:26:41 +0000

TL;DR: separa chiave calda e di amministrazione, metti il ruolo admin dietro multisig o KMS, scrivi la procedura di rotazione, prevedi che le persone se ne vadano.

Un contratto auditato dà una garanzia precisa: il codice fa quello che dice. Non dice nulla sull'altra metà del sistema, cioè su chi può firmare. Ogni applicazione on-chain in produzione dipende da almeno una chiave privata che conta — quella che firma le transazioni di ancoraggio, quella col ruolo di amministratore, quella che può mettere in pausa, aggiornare o emettere. Chi controlla quelle chiavi controlla il sistema, per quanto buono sia il codice.

Dove vive di solito la chiave

Nella maggior parte dei progetti la chiave nasce durante la demo. Finisce in una variabile d'ambiente o in un file di configurazione sul server, perché è il modo più rapido per far passare la prima transazione. Poi la demo diventa produzione, il server viene clonato in staging, si fa un backup, un collega copia il file per un debug, e nessuno torna indietro.

Una chiave privata non è una password. Non c'è un link di reset. Se esce, chi la ha possiede esattamente la tua autorità, e la catena non ha modo di distinguere voi due. La rotazione, dove il contratto la prevede, è una transazione firmata proprio dalla chiave che ti preoccupa.

La custodia è un progetto operativo

Le domande utili non sono crittografiche. Riguardano ruoli, limiti e persone.

Separare le chiavi per quello che possono fare. La chiave calda che firma le operazioni di routine non deve essere quella che cambia le regole. Le va dato il ruolo più piccolo che il contratto consente, e solo i fondi che servono per il prossimo periodo.

Mettere il ruolo potente dietro più di una persona. Il ruolo di amministrazione o di upgrade va dietro un multisig, o dentro un KMS o un HSM da cui la chiave non si esporta, con l'approvazione di più persone. Un portatile non è un modello di custodia.

Scrivere la procedura di rotazione prima che serva. Quale chiave sostituisce quale, chi firma il cambio, per quanto resta valida la vecchia, come si avvisano i partner. Scritta e provata, non improvvisata durante un incidente.

Prevedere che le persone se ne vadano. Chi ha configurato tutto prima o poi cambierà lavoro. Se l'unica conoscenza operativa delle chiavi se ne va con lui, il sistema ha un punto di rottura con il preavviso.

Perché va nella revisione di progetto

Per una software house .NET che consegna a una PMI, la custodia è la parte che il cliente non vede e che eredita. Chi fa due diligence — una banca, un revisore, un partner estero — chiederà chi può muovere fondi o cambiare il contratto prima di chiedere qualcosa sul codice. Per chi rientra in NIS2, la gestione delle chiavi è già tra le misure di sicurezza da documentare. In entrambi i casi la risposta deve esistere prima della domanda.

La custodia fa parte dell'architettura. Se compare solo nelle note di consegna, non è stata progettata.

La chiave che controlla il vostro contratto oggi dove vive, e chi altro potrebbe firmare con essa?

Articolo originale: https://www.omarbaruzzo.it/it/blog/chi-tiene-la-chiave

Who holds the key?

Omar Baruzzo — Tue, 29 Sep 2026 11:23:11 +0000

TL;DR: split hot and admin keys, put the admin role behind a multisig or KMS, write the rotation procedure, plan for people leaving.

An audited smart contract gives a precise kind of assurance: the code does what it says. It says nothing about the other half of the system, which is who can sign. Every on-chain application in production depends on at least one private key that matters — the one that signs anchoring transactions, the one holding the admin role, the one that can pause, upgrade or mint. Whoever controls those keys controls the system, regardless of how good the code is.

Where the key usually lives

In most projects the key is born during the demo. It gets pasted into an environment variable or a config file on a server, because that is the fastest way to make the first transaction go through. Then the demo becomes production, the server gets cloned into staging, a backup is taken, a colleague copies the file to debug something, and nobody goes back.

A private key is not a password. There is no reset link. If it leaks, whoever holds it has exactly the authority you have, and the chain has no way to tell the two of you apart. Rotation, where the contract allows it, is a transaction signed by the very key you are worried about.

Custody is an operational design

The useful questions are not cryptographic. They are about roles, limits and people.

Split the keys by what they can do. The hot key that signs routine transactions should not be the key that can change the rules. Give it the smallest role the contract allows and fund it with only what it needs for the next period.

Put the powerful role behind more than one person. The admin or upgrade role belongs behind a multisig, or inside a KMS or HSM where the key cannot be exported, with approval from more than one person. A single laptop is not a custody model.

Write the rotation procedure before you need it. Which key replaces which, who signs the change, how long the old key stays valid, how you tell partners. Written and rehearsed, not improvised during an incident.

Plan for people leaving. The engineer who set everything up will eventually change job. If the only working knowledge of the keys leaves with them, the system has a single point of failure with a notice period.

Why it belongs in the design review

A counterpart doing due diligence — a bank, an auditor, a foreign partner — will ask who can move funds or change the contract before they ask anything about the code. For organisations in scope of NIS2, key management is already part of the security measures they are expected to document. In both cases the answer has to exist before the question is asked.

Custody is part of the architecture. If it only appears in the handover notes, it was not designed.

Where does the key that controls your contract live today, and who else could sign with it?

Articolo originale: https://www.omarbaruzzo.it/en/blog/chi-tiene-la-chiave

Sidrenje hasheva na lancu lakši je dio — tko ih zapravo verificira?

Omar Baruzzo — Thu, 24 Sep 2026 11:26:19 +0000

Upisati Merkle root na lanac posao je jednog poslijepodneva. Izgraditi nešto što treća strana stvarno može verificirati je projektiranje. To nisu isti projekti, i samo drugi nešto vrijedi.

Verifikacija je račun koji netko drugi ponovi. Da bi to bilo moguće, četiri stvari moraju postojati zajedno:

Entry — bajt po bajt kako je hashiran. Ponovno čitanje iz baze i reserijalizacija novijom klasom pomiče hash, a pomaknut hash ne razlikuje se od manipulacije.
Inclusion proof — put susjednih čvorova od lista do roota. Pohranjen ili regenerabilan od svakoga tko ima ledger, ne samo od vašeg internog CLI-ja.
Root — na visini bloka koju se može imenovati. "Na lancu je" nije koordinata; broj bloka + hash transakcije jesu.
Reader koji nije vaš API. Ako revizor zove vaš server da provjeri vašu tvrdnju, opet vjeruje vama, samo kroz druga vrata.

Kako se gubi, sve vrlo dosadno:

refactoring reserijalizira entry
generator proofa postoji samo na jednom laptopu
lanac je onaj koji više nitko ne financira, ili ugašen testnet
aplikacija se ugasi i odnese verifikator sa sobom

Podatak preživi sva četiri slučaja. Put verifikacije ne — a bez njega je ancoriranje potvrda koju ste sami sebi napisali.

Tretirajte verifier kao deliverable: zamrznuta verzionirana serijalizacija, proofovi koji se mogu izvesti, on-chain koordinate u čitljivom obliku, i alat za verifikaciju koji radi izvan vašeg perimetra.

Puna verzija: https://www.omarbaruzzo.it/hr/blog/la-prova-che-nessuno-verifica

Ancorare hash su blockchain è la metà facile — chi li verifica davvero?

Omar Baruzzo — Thu, 24 Sep 2026 11:21:33 +0000

Scrivere una root Merkle sulla catena è il lavoro di un pomeriggio. Costruire qualcosa che un terzo sappia davvero verificare è progettazione. Non sono lo stesso progetto, e solo il secondo vale qualcosa.

Una verifica è un calcolo che qualcun altro rifà. Perché sia possibile, quattro cose devono esistere insieme:

La entry — byte per byte come è stata hashata. Rileggerla dal DB e riserializzarla con una classe più recente sposta l'hash, e un hash spostato è indistinguibile da una manomissione.
La proof di inclusione — il percorso di nodi fratelli dalla foglia alla root. Conservata o rigenerabile da chiunque abbia il registro, non solo dalla vostra CLI interna.
La root — a un'altezza di blocco nominabile. «È sulla catena» non è una coordinata; numero di blocco + hash della transazione lo sono.
Un reader che non sia la vostra API. Se il revisore chiama il vostro server per controllare la vostra affermazione, si fida di voi un'altra volta, da un'altra porta.

Come si perde, tutto molto noioso:

un refactoring riserializza la entry
il generatore di proof esiste solo su un portatile
la catena è una che nessuno finanzia più, o una testnet spenta
l'applicativo viene dismesso e si porta via il verificatore

Il dato sopravvive a tutti e quattro i casi. Il percorso di verifica no — e senza quello l'ancoraggio è una ricevuta che vi siete scritti da soli.

Trattate il verificatore come un deliverable: serializzazione congelata e versionata, proof esportabili, coordinate on-chain in chiaro, e uno strumento di verifica che gira fuori dal vostro perimetro.

Versione completa: https://www.omarbaruzzo.it/it/blog/la-prova-che-nessuno-verifica

Anchoring hashes on-chain is the easy half — who actually verifies them?

Omar Baruzzo — Thu, 24 Sep 2026 11:06:41 +0000

Writing a Merkle root on-chain takes an afternoon. Building something a third party can actually verify takes design. Those are not the same project, and only the second one is worth anything.

A verification is a computation someone else repeats. Four things have to exist together for that to be possible:

The entry — byte for byte as it was hashed. Re-reading it from the DB and reserializing with a newer model class moves the hash, and a moved hash is indistinguishable from tampering.
The inclusion proof — the sibling path from leaf to root. Stored or regenerable by anyone holding the ledger, not just your internal CLI.
The root — at a nameable block height. "It's on chain" is not a coordinate; block number + tx hash are.
A reader that is not your API. If the auditor calls your server to check your claim, they're trusting you again through a different door.

How it gets lost, all boring:

a refactor reserializes the entry
the proof generator only exists on one laptop
the chain is one nobody funds anymore, or a testnet that got shut down
the app is decommissioned and takes the verifier with it

The data survives all four. The verification path doesn't — and without it the anchor is a receipt you wrote yourself.

Treat the verifier as a deliverable: frozen versioned serialization, exportable proofs, on-chain coordinates in the clear, and a verification tool that runs outside your perimeter.

Full version: https://www.omarbaruzzo.it/en/blog/la-prova-che-nessuno-verifica