Cognizione condivisa

Framework metodologico e osservatorio cross-repo per il cognitive artifact design: la progettazione di artefatti cognitivi che sostengono la cognizione condivisa tra umano e modelli di intelligenza artificiale lungo l'intero ciclo d'azione.

Questo repository ha due funzioni complementari. La prima è custodire il metodo portabile: KB riflessiva, strati input/output, membrana world, struttura di progetto, strumenti, principi guida e ciclo di lavoro. La seconda è osservare come il metodo viene applicato nei progetti adottanti, confrontando artefatti, componenti, strumenti, skill, nodi, task e segnali di salute.

Il metodo è portabile tra progetti di natura diversa. Il nucleo è universale — principi, anatomia dell'artefatto e ciclo operativo — mentre le personalizzazioni sono esplicite: ogni progetto estende il metodo con Goal, Mondo, fonti di verità, rappresentazioni e strumenti propri del dominio. Le differenze tra progetti non sono rumore: sono materiale di analisi per capire cosa generalizzare, cosa lasciare locale e cosa trasformare in task operativo.

Lo sviluppo alterna esigenze emerse dagli adottanti e cornici teoriche che aiutano a interpretarle. Il canone torna ai progetti come conoscenza e prescrizioni, mentre ciascun adottante governa la propria coda. Il criterio e i confini di questi movimenti vivono in method-development.

Il dominio in breve

Il dominio è il metodo stesso. Il suo Mondo runtime comprende i progetti adottanti e le fonti teoriche dichiarati in world.md; il Mondo di sviluppo è l'artefatto che custodisce il canone, con i nodi kb/ al centro.

Progettiamo l'artefatto persistente perché sostenga il sistema cognitivo che nasce nell'uso tra umano e LLM. Per questa distinzione e i fondamenti si parte dall'hub cognitive-artifact-design. Il modello illustrato vive nel deck presentation/presentation.md, i criteri progettuali in design-principles.

Il lessico ha due registri. Nella teoria (cognizione distribuita, Norman) «agente» è chiunque agisca con l'artefatto, umano o macchina, e umano e LLM sono le due categorie del sistema cognitivo (agent). Nel lessico operativo, chi fa cosa nel repository:

• agente è l'IA che opera nel repository; dove servono tutti e due si dice «i due agenti»;
• custode è il ruolo che decide: Goal, Mondo, criteri e autorizzazioni. Lo ricopre una persona, dichiarata nel register goal.md;
• umano resta la categoria, per esempio il lettore umano di una vista, chi che sia: non tutti i lettori sono il custode;
• utente è l'interlocutore della sessione con l'agente, di solito il custode ma non per forza; LLM e modello indicano la tecnologia sostituibile sotto l'agente.

Metodo

Questo è il repository canonico del metodo: non lo adotta, lo custodisce. I repo adottanti leggono i nodi canonici via il loro symlink method/; qui il territorio e le superfici sono dichiarati nel register world.md e la superficie Drive delle fonti vive come gdrive/ gitignorato, non come world/. L'hub d'ingresso è cognitive-artifact-design.md, il solo nome di nodo assunto stabile come punto d'aggancio. Questa è la sezione README canonica (readme) — comune agli otto repo: dichiara l'adozione e punta ai due poli, che vivono nei register di root — goal.md (il nord: obiettivi, segnali, lavoro corrente) e world.md (il territorio: i sette adottanti, le superfici della membrana, le fonti) — da cui la home ricava i poli Goal e World rendendone l'intro.

Orientarsi

La root rende visibile la struttura del progetto (project-structure). Le sei collezioni portano il codice del loro stadio; ogni item dichiara nel frontmatter la facet ciclo: dev|runtime, letta dal Mondo su cui insiste — artefatto → dev, adottanti → runtime — dentro la relazione tra runtime cycle e development meta-cycle (development-meta-cycle).

Collezioni del ciclo, ciascuna col proprio indice:

• i1/ — Perceive: i segnali catturati valenza-neutri (indice perceptions.md)
• i2/ — Interpret: le sintesi sorgente (indice interpretations.md)
• i3/ — Compare: un file per filo aperto, aggiornato in place (indice verdicts.md)
• o1/ — Plan: i task aperti, prioritizzati, con dipendenze e ciclo (plan.md)
• o2/ — Specify: i dettagli e il contesto dei task aperti (indice tasks.md)
• o3/ — Perform: i runbook di propagazione e gli esecutori deterministici, gli strumenti registrati nell'indice (prescriptions.md)

Componenti trasversali:

• kb/ — il nucleo di conoscenza formalizzata della system image; il catalogo è l'indice interno omonimo kb/kb.md
• presentation/ — il deck, racconto curato dell'artefatto, con le sue tavole
• view/ — le viste generate, non versionate: index.html (la home della system image), le pagine 1:1 di register e collezioni, il deck reso e gli asset. python3 o3/view/build.py le genera dal checkout come anteprima; deck le pubblica da commit pulito sulla porta 8001, alle sole reti private (servizio utente dichiarato nel repo nixos); python3 o3/view/serve.py serve l'anteprima a mano sulla 8000 da qualsiasi host

Register dei poli — puntano fuori dall'artefatto, ai due confini del ciclo:

• goal.md — il polo superiore: il nord declinato in obiettivi, ognuno coi segnali che lo misurano e il lavoro corrente che lo serve; custode umano (goal)
• world.md — il polo inferiore: il territorio (i sette adottanti), le superfici della membrana e la provenienza delle fonti-mondo autorevoli, base dei ## Riferimenti (i3) (world)

Il cruscotto di lavoro è la coppia o1/plan.md (lato esecuzione: i task aperti) e i3/ (lato valutazione: i verdetti aperti). L'ordine di bootstrap è README → CLAUDE → nodo.

Funzioni del repo

• Metodo portabile — il modello e la ricetta vivono nei nodi indicizzati da kb/kb.md.
• Osservatorio cross-repo — il protocollo vive in method-observatory; il verdetto corrente in i3/audit-adottanti.md.
• Strumenti comuni — esecutori e runbook sono registrati in o3/prescriptions.md; capacità e limiti in kb-tools e skill.
• Viste e presentazione — le viste generate vivono in view/, fuori da git, con la disciplina della derivazione in view; il deck curato in presentation/, con la sua disciplina in presentation.

Come collegare un nuovo progetto

I progetti adottanti sono il Mondo runtime, indicizzati nel register world.md. Il protocollo d'ingresso vive in method-observatory; la forma della sezione Metodo, dei due register e delle connessioni intenzionali vive in readme, goal-register, world-register e method-development.