Knowledge IR

Una regola non è un'unità di conoscenza. È un contenitore per un'unità di conoscenza.

Un singolo paragrafo scritto da una persona dice spesso più cose di natura diversa nello stesso momento: che qualcosa non deve mai succedere, che qualcos'altro va verificato, e perché tutto questo esiste. Consegnate come un blocco unico, queste cose si riducono a "ecco un po' di testo, tienilo presente". Tenute separate, restano tre cose distinte con tre pesi diversi.

Knowledge IR è il nome di questa forma strutturata: il tipo e l'autorità di ogni elemento di conoscenza, conservati accanto al testo scritto dal tuo team, non al suo posto.

Tipi di conoscenza

Ogni elemento di conoscenza che un agente riceve appartiene a uno di pochi tipi, ed è il tipo a decidere come viene presentato.

Ciò che non deve succedere. Un vincolo stabilito da una persona per un determinato ambito. Si applica ai percorsi a cui si riferisce e a nient'altro, ed è l'unico tipo di conoscenza su cui il runtime può agire, anziché limitarsi a menzionarlo.

Ciò che va verificato. Un controllo che deve avvenire prima che il lavoro possa considerarsi concluso.

Ciò che ha funzionato quando si è presentato questo problema. Una condizione e la correzione che l'ha risolta. È un consiglio: dice all'agente cosa ha funzionato, non cosa gli è vietato fare.

Ciò che è preferibile in una certa condizione. Una scelta preferita, insieme alle alternative rispetto alle quali è stata preferita. Esprime la preferenza e non vieta mai l'alternativa. Solo una regola può farlo.

Come va fatta una cosa. Una procedura ordinata, con i passaggi nel loro ordine originale, perché una procedura riordinata è una procedura diversa. Le skill sono il posto in cui vive la maggior parte delle procedure.

Ciò che qui è vero e utile. Un fatto descrittivo che cambia l'approccio corretto senza vietare nulla. Che il database dietro un modulo sia una replica in sola lettura è un fatto di questo tipo, ed è il motivo per cui un agente dovrebbe ricorrere alla coda anziché a un insert.

Perché una cosa funziona in questo modo. Il ragionamento dietro una decisione. Esiste perché un agente che conosce la regola ma non il motivo è a un refactoring "di cortesia" dal disfarla.

Livelli di autorità

I tipi non hanno lo stesso peso, e la consegna lo dichiara in modo esplicito invece di affidarsi all'ordine in cui le cose compaiono in un prompt.

Nessun punto del percorso di consegna può presentare un livello inferiore come capace di prevalere su uno superiore. Le regole arrivano in una sezione dedicata. Le conclusioni degli agenti arrivano presentate come consigli da verificare. Le tue preferenze personali arrivano sotto un'intestazione che dice all'agente che le regole e i controlli obbligatori del workspace vengono prima. Un paragrafo che si legge con la stessa forza di un requisito è un paragrafo che può essere seguito al suo posto, e la struttura esiste proprio per impedirlo.

Ecco cosa significa in pratica "l'autorità viene codificata, non appiattita", ed è la differenza tra una rappresentazione strutturata e un mucchio di frasi.

Documenti e atomi

Le tue memorie, regole e skill restano esattamente quello che sono: la superficie che una persona scrive, modifica e discute. La forma strutturata ne è una rappresentazione, non un sostituto.

Rule document
    |
    +-- what must not happen
    +-- what must be verified
    +-- why

Un solo documento può contenere più tipi di conoscenza. È normale, ed è il motivo per cui un contenitore e un'unità non sono la stessa cosa.

Ciò che conta di più è da dove provengono i tipi vincolanti. Un requisito deriva solo da una regola stabilita da una persona. Una regola può contenere anche un vincolo eseguibile; un vincolo proposto da un agente viene salvato come proposta e non viene applicato finché una persona non lo approva. Niente di ciò che un modello deduce diventa un requisito da solo. Vedi Proposed Knowledge.

Conflitti

Due consigli possono sembrare entrambi validi ed essere comunque in disaccordo. Pathrule non lascia all'agente il compito di risolvere questo disaccordo.

• Conclusioni. Quando due conclusioni registrate dagli agenti sul codice si contraddicono, vengono trattenute entrambe anziché sceglierne una a caso.
• Preferenze. Quando insegni una preferenza che contraddice una precedente sullo stesso tipo di lavoro, la più recente la sostituisce, e quella più vecchia viene ritirata con un riferimento a ciò che l'ha sostituita.
• Regole e preferenze. Una regola prevale sempre su una preferenza personale. Vedi User Intelligence.

Due consigli in contraddizione sono peggio di nessun consiglio, ed è la struttura a permettere a Pathrule di accorgersi quando succede.