GROUNDING.md: il file che sovrascrive il prompt utente

Quattro giorni fa, il 23 aprile 2026, è uscito su arXiv un paper breve — nove pagine, una tabella, categoria cs.SE — firmato da tre persone che non sono ricercatori di machine learning. Sono Magnus Palmblad (Leiden University Medical Center, professore di bioinformatica e proteomica computazionale) e Jared Ragland + Benjamin Neely, entrambi del NIST, chemical sciences. Scienziati di dominio, non AI lab.

Il paper si chiama "Agentic AI-assisted coding offers a unique opportunity to instill epistemic grounding during software development". Il titolo è accademico, ma la proposta dentro è radicale: un nuovo file Markdown — chiamato GROUNDING.md — che ha autorità più alta del prompt dell'utente.

Tradotto: tu chiedi all'agente di fare X, e l'agente ti risponde "non posso, perché GROUNDING.md dice che X non è scientificamente valido". E rifiuta. Non perché OpenAI o Anthropic abbiano deciso così. Non perché il sysadmin abbia messo un guardrail. Perché un file di testo, mantenuto dalla community del dominio in cui stai lavorando, lo dice.

È un'idea piccola, di nicchia (gli autori parlano di proteomica), e a quattro giorni dalla pubblicazione non ha praticamente eco fuori da una manciata di lettori arXiv. Ma l'inversione di gerarchia che propone è interessante, e merita di essere capita prima che diventi mainstream — se ci diventerà.

Cosa propone esattamente il paper

GROUNDING.md è definito come "a community-governed, field-scoped epistemic grounding document". Le tre parole chiave da pesare:

Community-governed: non lo scrive l'azienda né lo sviluppatore. Lo mantiene la comunità scientifica/tecnica del dominio, con governance esplicita (gli autori indicano per la proteomica HUPO-PSI, le linee guida JPR, DOME e FAIR4RS — istituzioni reali, già attive).
Field-scoped: lega un intero campo, non un singolo repository. Un GROUNDING.md per tutta la proteomica, non uno per ogni tool proteomico.
Epistemic: non parla di efficienza ("come fai meglio le cose"). Parla di correttezza scientifica ("cosa è valido fare e cosa no").

Il file contiene due tipi di regole, distinte e con effetto operativo diverso.

Hard Constraints — l'agente deve rifiutare

Definizione dal paper: "Non-negotiable validity invariants empirically required for scientific correctness".

Comportamento atteso: quando un Hard Constraint sta per essere violato, l'agente deve rifiutare la richiesta, citare il constraint specifico, spiegare perché l'approccio è scientificamente invalido, e offrire un'alternativa compliant.

Esempio dal paper, dal mondo proteomico:

Un agente deve rifiutarsi di permettere ricerche simultanee con "50+ variable modifications" perché producono "computational search space meltdown".

In altre parole: se chiedi a Claude Code di scriverti uno script che ricerca 60 modificazioni post-traduzionali in parallelo, Claude — letto il GROUNDING.md proteomico — ti dice "no, è un approccio computazionalmente esploso, scientificamente non sensato; ti propongo invece questa ricerca a fasi staged". Anche se nel tuo prompt avevi scritto esplicitamente "fammi le 60 modificazioni".

Altro esempio: ogni filtro False Discovery Rate (FDR) deve soddisfare specifici invarianti, altrimenti l'output non è scientificamente accettabile. Nessun negoziato.

Convention Parameters — l'agente deve avvisare

Definizione: "Community-agreed defaults".

Comportamento atteso: l'agente genera un warning ma non rifiuta. Sono best practice forti, non leggi.

Esempio: usare label-free intensity per la quantificazione proteomica è fortemente preferito ma non assoluto. Se chiedi all'agente di usare un metodo diverso, lui te lo lascia fare ma ti avvisa che stai uscendo dalla convenzione.

La distinzione fra HC e CP è importante perché definisce il gradiente di autorità: Hard Constraints sono leggi del dominio, Convention Parameters sono norme. La community può promuovere una CP a HC quando il consenso si solidifica.

La gerarchia che ribalta tutto

Qui sta il pezzo più controverso del paper. Gli autori propongono una gerarchia esplicita di file di contesto, ordinata per stabilità (e quindi per autorità):

File	Tipo	Scope	Esempio
`plan.md`	session plan	ephemeral	Il piano del task corrente
`AGENTS.md`	project rules	persistent, project-scoped	Convenzioni del repo
`SKILL.md`	reusable method	reusable, method-scoped	Come fare un certo step
`GROUNDING.md`	grounding spec	invariant, field-scoped	"Any FDR filter must satisfy these invariants"

Più stabile sei, più alto in gerarchia. GROUNDING.md sta in cima. Sopra il piano della sessione corrente, sopra le regole del progetto, sopra i metodi riusabili dell'agente, sopra — implicitamente — il prompt dell'utente, che è la cosa più ephemeral di tutte.

È un'inversione netta del modello attuale. Oggi il prompt dell'utente è la fonte di verità: l'agente fa quello che gli chiedi, eventualmente modulato dal system prompt e dalle istruzioni di progetto. GROUNDING.md propone una catena gerarchica in cui c'è qualcosa di intermedio — la community del dominio — che ha maggior autorità sia di te che del proprietario del progetto.

Detto in modo brutale: stai usando il tuo computer, hai i tuoi privilegi, scrivi il tuo prompt. Ma se il GROUNDING.md della tua disciplina dice di no, l'agente ti dice di no. Non perché qualcuno te lo abbia tecnicamente impedito. Perché la comunità del dominio si è messa d'accordo che X è una pessima idea, e l'agente lo ha letto.

Il meccanismo: come funziona (e cosa non è)

Qui serve essere precisi, perché è facile fraintendere il livello tecnico della proposta.

GROUNDING.md non è:

Un firewall di tool calls (non c'è enforcement attivo che blocchi materialmente le azioni)
Un guardrail esterno tipo NeMo Guardrails o LlamaGuard
Un vincolo a livello di modello (non è fine-tuning, non è RLHF specifico)
Un sandbox

GROUNDING.md è:

Un file Markdown
Caricato e iniettato nel system prompt dell'agente con linguaggio normativo esplicito (tipo "the agent must refuse...")
Posizionato con priorità testuale più alta del contesto utente

Cioè: è prompt engineering strutturato. Il file viene preprocessato in un blocco di system prompt con language imperativo. Gli autori specificano di aver verificato che il caricamento via system prompt è "more consistent than XML tagging" nel produrre il comportamento di rifiuto desiderato.

L'agente decide testualmente, basandosi sul contesto, se rifiutare. Non c'è hardware-level enforcement. Non c'è cryptographic signing. È fiducia testuale, supportata dalle capacità di instruction following dei modelli moderni.

Setup del test nel paper: Claude Code v2.1.90 con Nemotron 120B via VS Code.

Onestà sull'evaluation

Qui devo dire una cosa che il marketing del paper non dice: l'evaluation è leggera.

Gli autori hanno testato GROUNDING.md su 6 prompt (Appendix A.3) che violano deliberatamente Hard Constraints diversi. Il criterio di successo è qualitativo: l'agente rifiuta esplicitamente, cita l'HC rilevante, spiega l'invalidità, offre alternativa.

Risultato dichiarato: "GROUNDING.md achieved authority through explicit HC language. Conflicts arose when similar language appeared elsewhere in context — formal adoption should resolve this."

Non c'è benchmark quantitativo. Non c'è baseline di confronto (es. "agente senza GROUNDING.md vs con"). Non c'è misura di robustezza ai jailbreak. Non c'è test cross-model. È un proof of concept, e gli autori sono onesti nel chiamarlo così — anche se chi cita il paper potrebbe presentarlo come un risultato più forte di quello che è.

Le limitazioni dichiarate dagli stessi autori vanno citate, perché sono importanti:

Il draft proteomico copre solo functional correctness, non security (es. PII), non project management.
Non è chiaro se servano multipli GROUNDING.md per sotto-domini (proteomica clinica vs ambientale vs strutturale).
Citano esplicitamente Gloaguen et al. 2026, un counter-paper di ETH Zürich che ha mostrato che AGENTS.md (lo standard analogo per le project rules) non ha effetto positivo statisticamente significativo sull'efficacia degli agenti, anzi: -3% success rate, +20% costo.
L'effectiveness varia tra agent scaffold differenti.
Non si può predire l'impatto di future evoluzioni dei modelli/scaffold.

Insomma: l'idea è interessante, l'esecuzione del paper è essenzialmente un manifesto con una demo. Trattarlo come fenomeno consolidato sarebbe disonesto.

La guerra dei file di istruzione (un po' di contesto)

GROUNDING.md non nasce dal nulla. Arriva dentro un panorama che chi lavora con i coding agent conosce bene.

Negli ultimi due anni si è consolidata una proliferazione di file di istruzione:

CLAUDE.md (Anthropic, 2024): file di progetto che configura Claude Code con convenzioni, comandi, convenzioni di stile
.cursorrules (Cursor): equivalente per Cursor IDE
CONTRIBUTING.md (decennale, riadattato in chiave AI): ogni contributo umano + AI dovrebbe conformarsi
AGENTS.md (Lulla et al., gennaio 2026, arXiv:2601.20404): il primo tentativo di standard cross-vendor, focalizzato sulla produttività dell'agente. Nel paper iniziale: +28% efficienza dichiarato

A dicembre 2025 Linux Foundation ha annunciato la Agentic AI Foundation dove OpenAI ha donato AGENTS.md, Anthropic ha donato MCP (Model Context Protocol), Block ha donato Goose. È diventato di fatto lo standard de-facto, anche se la convergenza non è completa (ogni tool mantiene il suo file principale).

Poi a febbraio 2026 ETH Zürich ha pubblicato il counter-paper Gloaguen et al.: testando AGENTS.md su benchmark realistici, l'effetto positivo si dissolve. "Statistically equivalent o lievemente negativo". Il dibattito sull'utilità reale di questi file è aperto.

GROUNDING.md arriva qui: in un panorama dove lo standard precedente non ha ancora dimostrato di funzionare, propone qualcosa di concettualmente diverso. Non è "stesso standard ma meglio". È un livello sopra: dove AGENTS.md parla di efficienza locale al progetto, GROUNDING.md parla di correttezza globale al dominio.

I due, in teoria, possono coesistere. In pratica, la gerarchia proposta dagli autori subordina AGENTS.md a GROUNDING.md — e questo apre un fronte politico interno alla Agentic AI Foundation che vale la pena guardare nei prossimi mesi.

In quali domini ha senso davvero

L'esempio del paper è proteomica. Bioinformatica computazionale, scienze biomediche, mass spectrometry. Domini in cui un errore metodologico può produrre paper sbagliati con conseguenze cliniche, e dove esistono già community-standard (HUPO-PSI, FAIR4RS, ecc.) maturi e formalizzati.

Generalizzando, GROUNDING.md ha senso in domini con tre caratteristiche:

Errori sostanziali hanno costo alto (clinico, legale, finanziario, regolatorio)
Esiste già una community con governance formale che produce standard scritti
L'AI sta entrando in modo aggressivo ma le aziende del settore non hanno ancora messo guardrail interni equivalenti

Domini candidati immediati: medicale (radiologia AI, pharmacovigilance), finanziario (compliance regolatoria, risk modeling), legale (citazioni inventate, false sentenze citate — il caso Mata vs Avianca insegna), aerospace, security-critical software (RTOS, PLC, industrial control).

Domini in cui GROUNDING.md non ha senso, e potrebbe essere pure controproducente: web app generaliste, prototipazione rapida, side project, qualunque cosa dove il "rifiuto epistemico" rallenta più di quanto protegga. Non tutto è proteomica.

Le critiche che si possono già fare (e una potenziale grossa)

A quattro giorni dalla pubblicazione il paper non ha ancora reazioni esterne pubbliche significative — lo dico chiaramente, perché è importante non gonfiare. Niente HN dedicato, niente commenti di researcher noti, niente coverage tech press. Le critiche che si possono articolare oggi sono in gran parte estrapolative.

Constitutional creep: chi scrive le costituzioni? Per la proteomica HUPO-PSI ha legittimità accumulata in vent'anni. Per "JavaScript framework correctness" non c'è equivalente. Il rischio è che vendor o consorzi auto-nominati propongano i loro GROUNDING.md come standard de-facto, esercitando una forma di gatekeeping epistemico che oggi non esiste. La community del Markdown standardizzato è sempre stata lo strumento del più forte — vedi la storia tortuosa di CommonMark.

Il problema NVIDIA: NVIDIA AI Red Team a marzo ha pubblicato un'analisi su indirect AGENTS.md injection attacks. Riassumendo: se un attaccante riesce a piazzare un AGENTS.md malevolo nel contesto dell'agente (per esempio in una dipendenza pulled da un repo), può manipolare il comportamento. Implicazione diretta per GROUNDING.md: a priorità ancora più alta, il vettore di attacco diventa potenzialmente peggiore. Un GROUNDING.md compromesso convince l'agente che il rifiuto/accettazione di certe operazioni è "scientificamente corretto", overriding sia il prompt utente che le project rules.

Gli autori non parlano di security threat model. È un buco serio per una proposta che si presenta come "epistemic grounding".

Il problema dei contesti misti: già nel paper si dice che "conflicts arose when similar language appeared elsewhere in context". Tradotto: appena hai più documenti che usano linguaggio prescrittivo (CONTRIBUTING.md, README.md, comments nel codice), l'agente fatica a capire chi ha autorità su cosa. La gerarchia ipotetica può funzionare in setup puliti; nel mondo reale dei codebase è uno spaghetto.

La dipendenza dal modello: il paper usa Claude Code + Nemotron 120B. Modelli più piccoli (o più vecchi) potrebbero non rispettare la gerarchia testuale con la stessa stabilità. La proposta funziona finché i modelli sono "obedient by default" — assunzione su cui ETH Zürich ha già messo un punto interrogativo per AGENTS.md.

Coautorato a tre attori

Nel pezzo di due giorni fa sull'arroganza umana e la serendipità del coautorato, ho parlato di due intelligenze diverse — l'umano e l'AI — che si riconoscono complementari nel produrre cose. GROUNDING.md introduce un terzo attore in quella stanza: la community formalizzata del dominio.

È un cambio interessante, e ambivalente.

Da una parte estende il coautorato: invece di essere solo io e la mia AI, diventiamo io + l'AI + il consenso della disciplina in cui mi muovo. Per i domini regolati è quasi una promessa — un coautorato che incorpora il giudizio collettivo di chi quel mestiere lo ha fatto per decenni, e lo aggiorna nel tempo.

Dall'altra parte può facilmente trasformarsi in monologo del consorzio: chi controlla GROUNDING.md controlla cosa è epistemicamente possibile fare con un'AI dentro quel dominio. È una posizione di gatekeeping enorme, e oggi nessuno ha capito chi se la dovrebbe prendere e con che legittimità.

Il pattern non è nuovo — ogni standardizzazione produce vincitori e perdenti — ma il fatto che si applichi a uno strumento personale come un coding agent (cose che giri sul tuo laptop, sui tuoi dati, per i tuoi scopi) è un movimento culturale notevole. Stiamo, di fatto, cominciando a discutere di costituzioni epistemiche del dominio che vivono in file Markdown.

In chiusura

GROUNDING.md è una proposta da prendere sul serio, non perché sia già una soluzione provata, ma perché identifica un problema reale e propone un'inversione di gerarchia che fa pensare. Quattro giorni di vita, autori di nicchia (proteomica, non AI lab), evaluation leggera, nessun consenso strutturato attorno. Allo stesso tempo: idea concettualmente nuova, ben formalizzata, e già con governance candidate (HUPO-PSI, FAIR4RS) per il dominio specifico in cui nasce.

Se diventerà uno standard, lo sapremo nei prossimi sei-dodici mesi — guardando se altri domini (medicale, finanziario, legale) producono i loro GROUNDING.md, se la Agentic AI Foundation lo accoglie sotto il proprio cappello, e se i foundation model lab cominciano a riconoscerlo nativamente nel loro tooling.

Per chi sviluppa oggi, due take pratici:

Se lavori in un dominio regolato (med, fin, legal, security-critical), vale la pena leggere il paper e cominciare a pensare se la tua community ha bisogno del proprio GROUNDING.md. La proposta è abbastanza concreta da poter essere prototipata domani sul tuo CLAUDE.md o AGENTS.md attuale.
Se lavori su web app generalista, probabilmente non ti serve. Ma il pattern di "documento community che ha autorità sopra il prompt" tornerà sotto altre forme. Il modo in cui pensiamo alla gerarchia delle istruzioni nei coding agent sta evolvendo, e GROUNDING.md è uno dei primi tentativi seri di darle una forma.

Il file che dice di no al tuo prompt non è ancora qui. Ma la domanda "chi ha l'ultima parola quando l'AI scrive codice in un dominio rischioso?" è stata posta esplicitamente per la prima volta. La risposta che daremo nei prossimi mesi conta.

Fonti: