Svaret er riktig. Veien dit er feil.

Tallet 420 kan være riktig av to uforenlige grunner. I dette tenkte eksempelet returnerer to agenter samme kontaktsegment, begge med 420 kunder. Den ene brukte butikkens godkjente målgruppe og sjekket samtykke. Den andre kopierte en gammel eksport fra et annet arbeidsområde og fikk tilfeldigvis samme antall.

En vurdering som bare ser på resultatet, gir begge agentene full score. Det er feil vurdering.

En diskusjon om kontroll i agentmiljøer skiller mellom sluttresultatet og veien som førte dit. I regnearkeksempelet er det riktige tallet bare en del av oppgaven. Formler, kildehenvisninger og påkrevd formatering betyr også noe. For integrasjoner er skillet enda skarpere: Hvor et resultat kommer fra, kan avgjøre om det i det hele tatt var tillatt.

En sluttverdi kan ikke bevise sitt eget opphav

Anta at en agent foreslår en feltmapping fra et kundeobjekt i en butikk til et markedsføringssystem. Den kobler email til e-post, firstName til fornavn og et samtykkefelt til målsystemets markedsføringsstatus. Forhåndsvisningen ser rimelig ut.

Hva leste agenten før den valgte dette? Det gjeldende skjemaet, et gammelt datautvalg eller et dokument fra en annen konto? Sjekket den hva samtykkefeltet betyr, eller gjettet den ut fra navnet? Tolket den null som «ikke abonnert» eller som «ukjent»?

Hvert svar endrer om den samme mappingen er til å stole på. Mappingen er et resultat. Sporet av kilder og handlinger er begrunnelsen for å bruke den.

Sporet må vise hvilken versjon av hver kilde som var tilgjengelig da beslutningen ble tatt. Et senere skjermbilde av et rettet skjema forklarer ikke en mapping som ble foreslått i går. Lagre den relevante skjema- eller dokumentversjonen sammen med beslutningen, og behold koblingen mellom versjonen og den godkjente regelen. Målet er å kunne rekonstruere beslutningen, ikke å lagre hver side agenten så.

Derfor kan et spor av verktøykall bety mer enn en selvsikker forklaring. Sporet registrerer konkrete kall og identifikatorer agenten brukte. Et skriftlig sammendrag kan være nyttig, men beviser ikke at en kilde ble lest. I en integrasjon bør dokumentasjonen peke på kildeobjektet, målsystemets kontrakt og den konkrete regelen som skal flytte dataene.

Guiden til å integrere bedriftsverktøy begynner med eierskap til feltene, fordi like navn på to sider sjelden avgjør hvem som har myndighet. En kontroll av fremgangsmåten spør om agenten faktisk brukte beslutningen om eierskap før den foreslo en oppdatering.

Skriv den tillatte veien inn i oppgaven

En god testsak har to deler. Beskriv først hva målsystemet skal inneholde. Beskriv så hvilke kilder og handlinger som er tillatt på veien dit.

For det tenkte segmentet kan forventet resultat være 420 kontakter. Den godkjente veien kan i tillegg kreve en forespørsel avgrenset til butikken, den gjeldende samtykkemappingen og en forhåndsvisning som viser utelatte poster. Den kan forby lesing på tvers av arbeidsområder og direkte utsending av kampanjer.

Da blir kontrollen konkret. Den kan avvise en identifikator fra et annet arbeidsområde med kode. Den kan sjekke at en forhåndsvisning ble kjørt før aktivering. Den kan bekrefte at datakilden som er oppgitt i resultatet, er den samme som i handlingssporet. Dette er regler, ikke modellmeninger.

Et spørsmål som gjenstår, kan kreve vurdering: Betyr det valgte samtykkefeltet faktisk tillatelse til denne kampanjen? Her bør en person eller en modell for en avgrenset beslutning undersøke feltdefinisjonen og den planlagte bruken. Regelen og vurderingen har ulike oppgaver.

Dette gir testen en nyttig feilmelding. «Feil svar» lar teamet gjette. «Riktig antall, men målgruppen kom fra lesing i et annet arbeidsområde» peker på et brudd i datagrensen. «Riktig mapping, men ingen samtykkedefinisjon var tilgjengelig» peker på manglende dokumentasjon. Kontrollen bør vise hvilken betingelse som feilet og hvilken hendelse i sporet som utløste den, slik at rettelsen endrer veien fremfor å pynte på sluttresultatets ordlyd.

Hva dokumenterer handlingssporet?

1. Godkjent kilde og påkrevde kontroller

   Godta fremgangsmåten

   Resultatet har dokumentasjonen oppgaven krevde.

2. Kilde fra et annet arbeidsområde

   Avvis fremgangsmåten

   Et likt antall gir ikke tillatelse til lesingen.

3. Påkrevd dokumentasjon mangler

   Vent på gjennomgang

   Resultatet alene viser ikke hvordan det ble utledet.

Ikke gjør handlingssporet til et ritual

En rimelig innvending er: «En agent kan utføre de påkrevde kallene og likevel ignorere dem.» Det stemmer. En liste med kall beviser at kallene skjedde. Den beviser ikke at informasjonen agenten fikk tilbake, påvirket beslutningen.

En måte å teste dette på er å endre informasjonen. Vis to ellers like poster med forskjellig samtykkestatus. Hvis agenten gir samme mapping og forklaring i begge tilfeller, kan kildebruken være skuespill. En annen måte er å fjerne en påkrevd kilde og kreve at agenten stopper. En agent som fyller hullet fra hukommelsen, fulgte ikke den tillatte veien.

Prisen er mer arbeid med testgrunnlaget. Noen må definere autoriserte kilder, forventede forskjeller og forbudte snarveier. En generell vurdering av om svaret «så bra ut», er billigere å bygge. Den lærer oss mindre.

Reverse ETL gjør en mapping til gjentatt dataflytting. Når mappingen er godkjent, kan vanlig kode bruke den uten at en agent går gjennom dokumentasjonen for hver rad. Kontrollen av veien hører hjemme ved beslutningene som lager eller endrer regelen, og igjen når en endret kontrakt gjør regelen usikker.

Et riktig svar hentet gjennom feil konto er ikke nesten riktig. Det er en annen oppgave.