Todellinen työ on vasta kehotteen jälkeen
Työpaja, joka alkoi liian myöhään
Työpaja oli varattu promptien parantamiseen. Näin se luki kalenterissa, iloisen pienen taikasauvan kuvakkeen kera, jota joku myöhemmin katui. Ryhmä esihenkilöitä, analyytikkoja, operaattoreita ja insinöörejä istui pöydän ääressä jaetun dokumentin kanssa. Nykyinen prompt oli näytöllä. Se pyysi kielimallia käymään läpi asiakaspyynnöt, tunnistamaan oikean käytännön, luonnostelemaan vastauksen ja merkitsemään riskit. Se oli kohtelias, jäsennelty ja paljon pidempi kuin kukaan halusi myöntää. Se ei kuitenkaan ollut pääongelma.
Ensimmäinen testitapaus oli asiakas, joka pyysi poikkeusta myöhästyneen toimituksen jälkeen. Malli tuotti kelvollisen vastauksen. Sitten joku operaatioista sanoi, että näytöllä oleva lähdekäytäntö ei ollut enää se, jota tiimi käytti perjantaisin, koska väliaikainen kuljettajasääntö oli jatkettu kahdesti, mutta sitä ei ollut koskaan yhdistetty pääkäytäntösivulle. Joku lakitiimistä sanoi, että tietyn summan ylittävät poikkeukset vaativat hyväksynnän, mutta raja riippui tuoteryhmästä. Talous kysyi, mihin hyvityslupaukset kirjataan. Tuki sanoi, että mallin sävy oli hyvä, mutta asiakas soittaisi uudelleen, koska vastauksessa ei mainittu puuttuvaa seurantatapahtumaa. Prompt istui siinä viattoman näköisenä.
Mikään näistä ongelmista ei ratkeaisi paremmalla ohjeistuskappaleella. Malli ei voinut päätellä, mikä käytäntösivu oli auktoritatiivinen. Se ei voinut tietää, että väliaikaisesta säännöstä oli tullut operatiivinen todellisuus. Se ei voinut päättää, kenellä oli hyväksyntävalta. Se ei nähnyt, että puuttuva seurantatapahtuma oli todellinen syy seuraavaan yhteydenottoon. Promptin odotettiin korvaavan epäselvän työn. Tämä on yleinen virhe. Ihmiset saapuvat promptin luo prosessin epäselvyyksien kori sylissään ja pyytävät mallia olemaan tyylikäs niiden kanssa.
Varsinainen työ tehdään ennen promptia. Se on työtä, jossa nimetään tehtävä, määritellään rajat, valitaan lähteet, sovitaan auktoriteetista, valmistellaan esimerkit, päätetään epäonnistumispolut, muotoillaan tuotos, mitataan laatu ja mahdollistetaan korjaaminen. Promptilla on merkitystä. Huono prompt voi tehdä hyvästä pohjasta kömpelön. Mutta kaunis prompt epäselvän toiminnan päällä on vain hyvin kirjoitettua sekasortoa. Malli voi kuulostaa paremmalta. Työ ei muutu turvallisemmaksi, halvemmaksi tai ymmärrettävämmäksi sattumalta.
Prompt ei ole prosessikartta
Prompt voi kertoa mallille, miten sen tulisi käyttäytyä tietyssä kontekstissa. Se ei voi luoda kontekstia, jos organisaatio ei ole sitä tehnyt. Se voi pyytää ytimekkyyttä, rakennetta, nöyryyttä ja lähdeviitteitä. Se voi kuvata roolin. Se voi määrittää muodon. Se voi varoittaa mallia arvailemasta. Nämä ovat hyödyllisiä. Ne ovat kuitenkin pieniä verrattuna prosessikysymyksiin, jotka ratkaisevat, auttaako tekoälyjärjestelmä vai puhuuko se vain itsevarmasti työn vieressä.
Mikä on tehtävä. Onko se luokittelua, poimintaa, tiivistämistä, luonnostelua, reititystä, suositusta, varmennusta vai toimintaa. Mikä osa on automatisoitu. Mikä osa jää ihmiselle. Mikä tila muuttuu, jos tulos hyväksytään. Keihin se vaikuttaa. Mihin tietueisiin kajotaan. Mikä käytäntö sovelletaan. Mikä näyttö on pakollista. Mitä tapahtuu, kun näyttö puuttuu. Mitkä virheet ovat siedettäviä. Mitkä virheet aiheuttavat haittaa. Nämä kysymykset ratkaisevat järjestelmän muodon. Prompt, joka ei lepää selkeiden vastausten päällä, on kohtelias arvaus nimikyltin kanssa.
Monet epäonnistuneet tekoälypilottihankkeet alkavat promptista, koska prompt on näkyvin kahva. Se tuntuu luovalta ja välittömältä. Sitä voi muokata palaverissa. Uuden version voi kokeilla ennen kuin kahvi ehtii jäähtyä. Prosessisuunnittelu on hitaampaa. Datan siivous on hitaampaa. Valtuuksien kartoitus on hitaampaa. Arviointiaineiston rakentaminen on hitaampaa. Valitettavasti hidas ei tarkoita samaa kuin valinnainen. Osat, jotka ohitetaan ennen promptia, palaavat myöhemmin hallusinaatioina, uusintatöinä, epäluottamuksena, käytäntöpoikkeuksina ja isona taulukkona nimeltä ongelmat.
Parempi järjestys ei ole glamourinen. Kirjoita työ ylös. Käy läpi oikeita tapauksia. Tunnista lähdejärjestelmät. Merkitse, mitkä kentät ratkaisevat lopputulokset. Erota säännöt harkinnasta. Päätä, missä ihmiset astuvat mukaan. Määritä tulostussopimukset. Rakenna esimerkkejä. Sovi kieltäytymisestä. Testaa niiden kanssa, jotka elävät tuloksen kanssa. Vasta sitten promptista tulee hyödyllinen vipu. Sitä ennen se on koristeellinen ohjauspyörä työpöydällä.
Tehtävän rajan on oltava riittävän terävä testattavaksi
Tekoälytyö alkaa usein verbeistä, jotka ovat liian suuria. Auta asiakaspalvelussa. Tue oikeudellista tarkastelua. Paranna suunnittelua. Avusta hankinnoissa. Tee raportoinnista älykkäämpää. Nämä ovat tavoitteita, eivät tehtäviä. Mallia ei voi arvioida tavoitetta vasten. Sitä voi arvioida tehtävää vasten, jolla on syötteet, tulokset, rajoitteet, onnistumiskriteerit ja epäonnistumispolut. Suppeampi kuvaus voi tuntua vähemmän jännittävältä. Se on myös ensimmäinen hetki, jolloin työstä tulee rakennettavaa.
Terävä tehtävän raja kertoo, mitä järjestelmä saa nähdä ja mitä se saa muuttaa. Se kertoo, lukeeko malli lähdemateriaalia, tuottaako se luonnoksen, poimiiko se jäsenneltyjä kenttiä, suositteleeko se toimintoa vai kutsuuko se työkalua. Se kertoo, mitkä tulokset ovat lopullisia, mitkä neuvoa-antavia ja mitkä on tarkistettava. Se kertoo, mistä järjestelmä kieltäytyy. Se kertoo, milloin mallin tulisi pyytää lisää näyttöä sen sijaan, että se täydentäisi vastauksen. Se kertoo, mikä on soveltamisalan ulkopuolella, koska soveltamisalan ulkopuoli on se paikka, jossa kunnianhimoisista pilottihankkeista tulee vaaratilanneraportteja.
Rajat tekevät arvioinnista mahdollista. Jos tehtävä on luonnostele vastaus näitä lähteitä ja tätä käytäntöä käyttäen, laatua voidaan testata. Jos tehtävä on paranna palvelun laatua tekoälyllä, jokainen tulos voidaan selittää edistykseksi jonkun toimesta, jolla on riittävästi kalvoja. Raja suojaa myös käyttäjiä tahattomalta eskalaatiolta. Työkalu, joka alkaa luonnostelulla, voi saada painikkeen, joka lähettää. Luokittelijasta voi tulla reititin. Reitittimestä voi tulla päätös. Ilman nimettyä rajaa tämä ajautuminen tuntuu käyttöönotolta. Rajan kanssa siitä tulee muutospyyntö.
Raja on kirjoitettava toiminnan kielellä, ei vain teknisellä kielellä. Tuen esihenkilön on ymmärrettävä se. Lakiosaston on ymmärrettävä se. Tietojen omistajan on ymmärrettävä se. Insinöörin on pystyttävä testaamaan se. Jos raja elää vain kehotteessa, se on hauras. Kehotteet ovat tärkeitä, mutta ne eivät ole kantavia politiikka-asiakirjoja. Ne ovat enemmän kuin ohjeet erittäin lahjakkaalle määräaikaiselle työntekijälle, joka ei ole koskaan nähnyt organisaatiokaaviota.
Lähteet eivät ole asiakirjapino
Monet tiimit huomaavat kehotteita laatiessaan, etteivät he tiedä, mitkä lähteet ovat auktoritatiivisia. Heillä on politiikkasivuja, PDF-tiedostoja, sähköpostiohjeita, koulutusmateriaalia, vanhoja käsikirjoja, chattiviestejä, lippumakroja, laskentataulukkoja ja muistissa olevan operaattorin tiedot, jota kaikki soittavat, koska hän tietää, miten asiat oikeasti toimivat. Mallia pyydetään sitten vastaamaan tietokannasta. Mikä tieto. Mikä kanta. Ilmaus voi tehdä valtavasti peittelytyötä.
Lähteiden valmistelu ei ole hohdokasta, minkä vuoksi se jää usein myöhään. Siihen kuuluu päättäminen siitä, mikä asiakirja voittaa, kun lähteet ovat ristiriidassa, miten ajantasaisuus tarkistetaan, miten väliaikaiset säännöt vanhenevat, miten poikkeukset esitetään, miten luottamuksellinen materiaali suljetaan pois, miten lähdeversiot säilytetään ja miten viittaus tunnisteet säilyvät mallin vastauksessa. Tämä ei ole paperityötä. Se on ero hakemisen ja penkomisen välillä.
Tekoäly tekee lähdedisplinistä tärkeämpää, koska malli voi saada heikot lähdekäytännöt näyttämään hyväksyttäviltä. Se voi ommella katkelmia sujuvaksi proosaksi. Se voi silottaa ristiriidat. Se voi tuottaa uskottavan vastauksen vanhentuneesta materiaalista. Hakutulos, jossa on näkyviä aukkoja, tuntuu keskeneräiseltä. Generoitu vastaus samoilla aukoilla voi tuntua täydelliseltä. Mitä parempi proosa, sitä tärkeämpi alkuperä on. Luottamuksen ei pitäisi antaa pestä heikkoa lähdeketjua.
Hyvä lähdevalmistelu vähentää myös kehotteen monimutkaisuutta. Kehote, joka on täynnä varoituksia ristiriitaisista politiikoista, vanhentuneista asiakirjoista, puuttuvista kentistä ja erityispoikkeuksista, on usein oire ylävirran laiminlyönnistä. Jos hakukerros suodattaa jo auktoriteetin ja ajantasaisuuden mukaan, kehote voi olla lyhyempi. Jos lähde sisältää jäsenneltyä metatietoa, mallin ei tarvitse päätellä sitä kappaleiden otsikoista. Jos poikkeukset esitetään sääntöinä, mallin ei tarvitse ryhtyä etsiväksi token-rajoitusten kanssa. Paras kehote parannus on joskus parempi hakemisto.
Esimerkit ovat pieniä hallinnon palasia
Esimerkkejä pidetään yleensä harjoitusmateriaalina, mutta ne ovat myös hallintaa. Hyvä esimerkki kertoo, mitä laatu tarkoittaa tietyssä tilanteessa. Se osoittaa, miten organisaatio käsittelee epävarmuutta, puuttuvaa näyttöä, ristiriitaisia ohjeita, arkaluonteista sävyä, eskalaatiota ja kieltäytymistä. Se kertoo mallille ja tiimille, miltä hyvä vastaus näyttää, mutta myös sen, miltä hyvä vastaamatta jättäminen näyttää. Tämä on tärkeää, koska monet vakavat järjestelmät epäonnistuvat vastaamalla silloin, kun niiden pitäisi pysähtyä.
Esimerkkien rakentaminen pakottaa tekemään päätöksiä, joita abstrakti keskustelu välttää. Ota kaksikymmentä oikeaa tapausta. Merkitse oikea lopputulos. Merkitse hyväksyttävät vaihtoehdot. Merkitse ei-hyväksyttävät oikotiet. Selitä miksi. Sisällytä reunatapauksia, jotka saivat kokeneen henkilökunnan epäröimään. Sisällytä myös tavallisia tapauksia, koska järjestelmät, jotka harjoittelevat vain draamalla, oppivat huonot tavat. Pyydä alan asiantuntijoita olemaan eri mieltä ja kirjaa erimielisyys ylös. Tämä on hitaampaa kuin pyytää mallia olemaan varovainen. Se tuottaa myös yhteisen kielen varovaisuudelle.
Esimerkkien tulisi sisältää kielteisiä tapauksia. Lähdettä ei löydy. Lähde on ristiriidassa. Käyttäjällä ei ole valtuuksia. Pyyntö on tarkoituksen ulkopuolella. Asiakas pyytää jotain, mikä kuulostaa yksinkertaiselta, mutta laukaisee käytännön. Mallin tulisi oppia, milloin kieltäytyä, eskaloida, kysyä tai palauttaa jäsenneltyä epävarmuutta. Jos esimerkit näyttävät vain onnistuneita vastauksia, kehote kallistuu suorittamiseen. Suorittaminen ei ole aina menestystä. Joskus paras vastaus on se, että näyttöä ei ole riittävästi, mitä on vaikea juhlia demossa, mutta mikä on hyödyllistä toimivassa järjestelmässä.
Esimerkit ovat myös arvioinnin alku. Niistä voi tulla testikiinnitteitä, regressiotapauksia, arvioijien koulutusmateriaalia ja seurannan näytteitä. Kun poikkeama tapahtuu, korjattu tapaus voi tulla uudeksi esimerkiksi. Tämä antaa järjestelmälle muistin. Ilman esimerkkejä kehotemuutoksista tulee mielialan muutoksia. Joku sanoo, että vastaus tuntuu paremmalta. Joku toinen sanoo, että se tuntuu huonommalta. Malli hymyilee keskellä, häiriintymättä näytöstä.
Lähteen muoto on operatiivinen päätös
Kehotekeskusteluissa käytetään usein liikaa aikaa sävyyn ja liian vähän lähteen muotoon. Sävy on tärkeä, erityisesti asiakas- ja julkisessa viestinnässä. Mutta lähteen muoto ratkaisee, voidaanko vastaus tarkistaa, reitittää, tallentaa, hyväksyä, haastaa tai käyttää toisessa järjestelmässä. Kappale voi olla miellyttävä. Jäsennelty lähtö voi olla käyttökelpoinen. Vakava tekoälytyö tarvitsee usein molempia: luettavaa proosaa ihmisille ja kenttiä, jotka koneet voivat varmistaa.
Lähtötietojen rakenne sisältää pakolliset kentät, lähdeviittaukset, luottamuksen tai epävarmuuden, kieltäytymisen syyt, eskalaatioliput, kohdistetut tietueet, ehdotetut toimenpiteet ja ihmisen hyväksynnän tilan. Se kertoo, saako malli jättää kentän tyhjäksi. Se kertoo, pitääkö sen lainata käytännön tunnistetta. Se kertoo, saako malli keksiä luokkia vai pitääkö sen valita kontrolloidusta luettelosta. Se kertoo, mitä tapahtuu, kun syöte on epäselvä. Nämä valinnat eivät ole kehotteen koristelua. Ne ovat työnkulun suunnittelua.
Rakenteinen tuloste pitää myös mallin omalla alueellaan. Jos järjestelmä edellyttää erillistä kenttää todisteille, perusteettomat väitteet tulevat näkyviin. Jos se edellyttää toimintotyyppiä sallitusta luettelosta, luova työkalujen käyttö vaikeutuu. Jos se edellyttää epävarmuuden ilmaisemista, arvioijat voivat tehdä lajittelua. Jos se edellyttää kieltäytymisen syytä, estetyt tapaukset voidaan analysoida. Kehote voi pyytää näitä asioita, mutta ympäröivän järjestelmän pitäisi vahvistaa ne. Kohtelias pyyntö ei ole valvontaa. Se on ehdotus muotoiluineen.
On myös inhimillinen puoli. Ihmiset tarvitsevat tulostetta, joka sopii heidän työrytmiinsä. Lakimies saattaa tarvita lähdekohtia ja riskimerkintöjä. Tukiedustaja saattaa tarvita asiakasvalmiin luonnoksen sekä sisäiset syykoodit. Suunnittelija saattaa tarvita reittisuosituksen ja sen rajoitteen, joka sen aiheutti. Esimies saattaa tarvita yhteenvetoja syistä, ei yksittäistä proosaa. Jos tulosteen rakenne ei huomioi käyttäjää, kehote voi olla teknisesti oikea ja toiminnallisesti ärsyttävä. Se on yleinen saavutus, mutta ei hyödyllinen.
Auktoriteettia ei voi johtaa avuliaisuudesta
Avulias malli herättää luottamusta. Se on hyvä asia, kunnes avuliaisuus sekoitetaan auktoriteettiin. Jos malli luonnostelee vastauksen, kuka saa lähettää sen. Jos se suosittelee hyvitystä, kuka saa hyväksyä sen. Jos se luokittelee riskin, kuka saa toimia luokituksen perusteella. Jos se poimii kentän, kuka korjaa sen. Jos se ei löydä todisteita, kuka päättää, jatketaanko. Näihin kysymyksiin on vastattava ennen kehotetta, koska kehote ei voi myöntää institutionaalista auktoriteettia.
Auktoriteetin suunnitteluun kuuluvat roolit, kynnykset, tarkastusjonot, ohitusoikeudet, eskalaatiopolut ja auditointitietueet. Se erottaa ehdotuksen päätöksestä. Se erottaa automatisoidun päätöksen ihmisen päätöksestä, jota automaatio tukee. Se kertoo, milloin ihmisen on nähtävä lähdemateriaali pelkän mallin tuottaman proosan sijaan. Se kertoo, milloin työkalujen kutsuminen on sallittua ja milloin se on estetty. Se kertoo, kuka vastaa haitasta, viiveestä, korjauksesta ja viestinnästä. Malli voi auttaa tämän suunnittelun puitteissa. Sen ei pitäisi olla itse suunnittelu.
Tämä on erityisen tärkeää, kun tekoäly lisätään olemassa oleviin työnkulkuihin. Olemassa oleva auktoriteetti voi olla epävirallista. Vanhempi henkilö hyväksyy poikkeukset, koska kaikki tietävät kysyä häneltä. Tiiminvetäjä tulkitsee käytäntöä, koska hän on nähnyt reunatapaukset. Taulukkolaskenta sisältää väliaikaisen säännön, koska järjestelmä ei pysty siihen. Kun tekoäly tulee mukaan, epävirallinen auktoriteetti haurastuu. Malli voi levittää vanhaa epäselvyyttä nopeammin kuin ihmiset ehtivät reagoida. Kehotetta edeltävä työ on tehdä auktoriteetista riittävän yksiselitteistä, jotta skaalautuminen ei yksinkertaisesti skaalaa hämmennystä.
On syytä todeta, että auktoriteetti ei ole nopeuden vihollinen. Selkeä auktoriteetti nopeuttaa usein työtä, koska ihmiset tietävät, mikä voi edetä ilman keskustelua, mikä on pysäytettävä ja kuka voi päättää. Epämääräinen auktoriteetti tuntuu joustavalta, kunnes se kohtaa volyymin. Sitten jokaisesta vaikeasta tapauksesta tulee pieni perustuslaillinen kriisi, ja keskusteluketjut toimivat oikeuskäytäntönä. Tämä ei ole suositeltava oikeusjärjestelmä.
Arviointi ei ole tunnelmamittaus
Monet prompt-iteraatiot arvioidaan fiilispohjalta. Tämä versio kuulostaa paremmalta. Tuo versio on ytimekkäämpi. Tämä on vähemmän käskevä. Tällaiset arviot voivat olla hyödyllisiä, mutta ne eivät riitä. Tekoälyoperaatiot tarvitsevat arviointia, joka seuraa tehtävää. Käyttikö malli oikeaa lähdettä. Jättikö se vaaditut kentät täyttämättä. Kieltäytyikö se, kun näyttöä ei ollut. Eskaloiko se korkean riskin tapaukset. Säilyttikö se politiikan tunnisteet. Ohittivatko ihmiset sen. Kysyivätkö asiakkaat vähemmän jatkokysymyksiä. Näkivätkö alavirran tiimit vähemmän uudelleentyötä.
Arvioinnin tulisi kattaa tavalliset tapaukset, reunatapaukset, vastakkaiset tapaukset, vanhentuneet lähteet, puuttuva data, ristiriitainen politiikka ja esimerkit hyväksyttävästä kieltäytymisestä. Sen tulisi olla toistettavaa. Sen tulisi erottaa mallin vika lähteen viasta, promptin viasta, käyttöliittymän viasta ja prosessin viasta. Muuten jokaisesta ongelmasta tulee prompt-ongelma, koska prompt on se osa, jonka kaikki näkevät. Näkyvä osa ei ole aina syyllinen osa. Tämä pätee ohjelmistossa ja kokouksissa.
Arviointi päättää myös, milloin lopetetaan. Ilman testijoukkoa ja julkaisukriteerejä promptityö voi jatkua loputtomiin, koska kieltä voi aina parantaa. Aina löytyy toinen adjektiivi, toinen ohje, toinen esimerkki, toinen muotoiluhienosäätö. Kysymys ei ole siitä, onko prompt täydellinen. Kysymys on siitä, suorittaako järjestelmä tehtävän sovittujen riski-, kustannus- ja laaturajojen puitteissa. Täydellisyys on huono julkaisupäällikkö. Sillä ei ole hälytyslaitetta mukanaan.
Promptin jälkeinen työ alkaa ennen julkaisua
Korjauspolut tulisi suunnitella ennen kuin ensimmäinen tuotantokäyttäjä raportoi ongelman. Miten käyttäjä merkitsee väärän vastauksen. Minne merkintä menee. Kuka sen tarkistaa. Muuttuuko lähde. Muuttuuko esimerkkipankki. Muuttuuko prompt. Muuttuuko sääntö. Muuttuuko kynnysarvo. Saako ihminen palautetta. Tuleeko korjatusta tapauksesta regressiotesti. Jos korjausta ei ole suunniteltu, palautteesta tulee kasa. Kasoissa oppiminen nukkuu pitkät päiväunet.
Seuranta tulisi myös päättää ennen julkaisua. Seuraa paitsi viivettä ja kustannuksia myös kieltäytymisasteita, lähteen puuttumisasteita, ohituksen syitä, eskalaatiokuormaa, alavirran uudelleentyötä, valitusteemoja, vanhentuneita viittauksia ja tehtäväjakauman muutoksia. Mallin vastausten laatu on vain yksi osa operatiivista laatua. Järjestelmä voi vastata hyvin ja silti ohjata liikaa työtä ihmisille. Se voi vastata nopeasti ja silti lisätä korjauksia. Se voi vähentää tikettejä ja silti luoda vaikeampia tikettejä. Seurannan tulisi nähdä työ, ei vain tokenit.
Esityön tekeminen ei lopu koskaan. Uusia käytäntöjä ilmestyy. Lähdejärjestelmät muuttuvat. Käyttäjät löytävät oikoteitä. Malli muuttuu. Liiketoiminta muuttuu. Kehote, joka toimi toukokuussa, voi olla väärä syyskuussa, koska työ on siirtynyt sen alla. Tämä ei tarkoita, että kaikki olisi haurasta. Se tarkoittaa, että tekoälytoiminta tarvitsee omistajuutta. Jonkun on ylläpidettävä tehtävän määrittelyä, lähteitä, esimerkkejä, arviointia, valtuuksia ja korjausta. Muuten kehotteesta tulee fossiili, jolla on erinomainen kielioppi.
Opetus
Varsinainen työ tehdään ennen kehotetta, koska kehote on näkyvä reuna suuremmalle toimintajärjestelmälle. Malli tarvitsee tehtävän, jonka se voi suorittaa, lähteet, joihin se voi luottaa, rajat, joita se ei voi ylittää, tulokset, jotka voidaan tarkistaa, esimerkit, jotka koodaavat harkintaa, valtuudet, jotka kertovat ihmisille ja työkaluille, mitä ne saavat tehdä, sekä arvioinnin, joka voi erottaa parannuksen kauniimmasta proosasta. Ilman tätä kehote kantaa vastuita, joita se ei voi täyttää.
Tämä näkemys ei vähennä kehotteiden merkitystä. Se tekee kehotteista arvokkaampia. Valmisteltuun toimintaan sijoitettu kehote voi olla lyhyt, selkeä, testattava ja ylläpidettävä. Se voi kohdistaa mallin huomion sen sijaan, että se kompensoisi epäselvyyttä. Se voi kehittyä esimerkkien ja todisteiden myötä. Sitä voi muuttaa luottavaisesti, koska tiimi tietää, mitä hyvä tarkoittaa. Se on parempi kuin kehote-mystiikka, joka tuottaa enimmäkseen pidempiä kehotteita ja hiljaisempia epäilyksiä.
Ennen kuin kysyt, miten mallia kehotetaan, kysy, mitä työtä organisaatio on jo tehnyt mallin hyväksi. Onko tehtävä nimetty. Ovatko lähteet auktoritatiivisia. Onko esimerkit merkitty. Onko tulos jäsennelty. Onko valtuudet ilmaistu. Onko epäonnistuminen turvallista. Onko arviointi todellista. Onko korjaus suunniteltu. Jos vastaukset ovat heikkoja, aloita sieltä. Hyödyllisin kehote huoneessa voi olla se, joka saa kaikki myöntämään, että kehote ei ole se paikka, josta työ alkaa.