Svaret er rigtigt. Vejen dertil er forkert.

Tallet 420 kan være korrekt af to uforenelige grunde. I dette tænkte eksempel returnerer to agenter samme kontaktsegment og viser begge 420 kunder. Den ene brugte butikkens godkendte målgruppe og kontrollerede samtykke. Den anden kopierede en forældet eksport fra et andet arbejdsområde og ramte tilfældigvis samme antal.

En bedømmelse, der kun ser på resultatet, giver begge agenter topkarakter. Det er den forkerte karakter.

En samtale om kontrol i agentmiljøer skelner mellem slutresultatet og den vej, der førte til det. I eksemplet med et regneark er det rigtige tal kun en del af opgaven. Formler, kildehenvisninger og påkrævet formatering betyder også noget. Ved integrationer er forskellen endnu skarpere: Resultatets oprindelse kan afgøre, om det overhovedet var tilladt.

En slutværdi kan ikke bevise sin oprindelse

Antag, at en agent foreslår en feltmapping fra et kundeobjekt i en butik til et marketingsystem. Den mapper email til e-mail, firstName til fornavn og et samtykkefelt til målsystemets marketingstatus. Forhåndsvisningen ser rimelig ud.

Hvad læste den for at vælge sådan? Det aktuelle skema, et gammelt eksempel eller et dokument fra en anden konto? Undersøgte den samtykkefeltets betydning, eller gættede den ud fra navnet? Behandlede den null som »ikke tilmeldt« eller som »ukendt«?

Hvert svar ændrer, om den samme færdige mapping er til at stole på. Mappingen er et resultat. Dokumentationen for fremgangsmåden er begrundelsen for at bruge den.

Dokumentationen skal vise, hvilken version af hver kilde der var tilgængelig, da beslutningen blev truffet. Et senere skærmbillede af et rettet skema forklarer ikke en mapping, der blev foreslået i går. Gem den relevante skema- eller dokumentversion sammen med beslutningen, og bevar forbindelsen mellem versionen og den godkendte regel. Målet er at kunne genskabe beslutningen, ikke at gemme alle sider, agenten så.

Derfor kan et spor af værktøjskald betyde mere end en selvsikker forklaring. Sporet registrerer de konkrete kald og id’er, agenten brugte. En skriftlig opsummering kan være nyttig, men den kan ikke bevise, at en kilde blev læst. I en integration bør dokumentationen pege på kildeobjektet, målsystemets kontrakt og den præcise regel, der skal flytte dataene.

Guiden til at integrere virksomhedsværktøjer begynder med ansvar for felterne, fordi navne på begge sider sjældent afgør, hvem der bestemmer. En kontrol af fremgangsmåden spørger, om agenten faktisk læste den beslutning om ansvar, før den foreslog en opdatering.

Skriv den tilladte fremgangsmåde ind i opgaven

En god testsag har to dele. Angiv først, hvad målsystemet skal indeholde. Angiv derefter, hvilken dokumentation og hvilke handlinger der er tilladt på vejen dertil.

For det tænkte segment kan det forventede resultat være 420 kontakter, men den godkendte fremgangsmåde kan også kræve en forespørgsel begrænset til butikken, den aktuelle samtykkemapping og en forhåndsvisning, der viser udelukkede poster. Den kan forbyde læsning på tværs af arbejdsområder og direkte kampagneudsendelser.

Det gør kontrollen konkret. Den kan afvise et id fra et andet arbejdsområde med kode. Den kan kontrollere, at en forhåndsvisning blev kaldt før aktivering. Den kan bekræfte, at datakilden i resultatet svarer til kilden i handlingssporet. Det er regler, ikke modelvurderinger.

Et tilbageværende spørgsmål kan kræve en vurdering: Betød det valgte samtykkefelt faktisk tilladelse til denne kampagne? Her bør en person eller en model til en snæver beslutning undersøge feltdefinitionen og den tilsigtede brug. Reglen og vurderingen har forskellige opgaver.

Det giver testen en nyttig fejlmeddelelse. »Forkert svar« lader teamet gætte. »Korrekt antal, men målgruppen kom fra læsning i et andet arbejdsområde« udpeger en brudt datagrænse. »Korrekt mapping, men ingen samtykkedefinition var tilgængelig« udpeger manglende dokumentation. Kontrollen bør vise den fejlede betingelse og den hændelse i sporet, der udløste den, så rettelsen ændrer fremgangsmåden frem for at polere slutsvarets ordlyd.

Hvad dokumenterer handlingssporet?

1. Godkendt kilde og påkrævede kontroller

   Acceptér fremgangsmåden

   Resultatet har den dokumentation, opgaven krævede.

2. Kilde fra et andet arbejdsområde

   Afvis fremgangsmåden

   Et tilsvarende antal kan ikke give tilladelse til læsningen.

3. Påkrævet dokumentation mangler

   Afvent gennemgang

   Resultatet alene kan ikke vise, hvordan det blev udledt.

Gør ikke handlingssporet til et ritual

En rimelig indvending er: »En agent kan udføre de krævede kald og stadig ignorere dem.« Korrekt. En liste over kald beviser, at et kald fandt sted. Den beviser ikke, at den returnerede dokumentation påvirkede beslutningen.

En måde at teste det på er at ændre dokumentationen. Præsenter to ellers ens poster med forskellige samtykkestatusser. Hvis agenten giver samme mapping og forklaring i begge tilfælde, kan dens tilsyneladende brug af kilder være skuespil. En anden måde er at fjerne en påkrævet kilde og kræve, at agenten stopper. En agent, der udfylder hullet fra hukommelsen, har ikke fulgt den tilladte vej.

Prisen er mere arbejde med testgrundlaget. Nogen skal definere de autoriserede kilder, forventede forskelle og forbudte genveje. En generisk vurdering af, om svaret så godt ud, er billigere at bygge. Den lærer os mindre.

Reverse ETL gør en mapping til gentagen dataflytning. Når mappingen er godkendt, kan almindelig kode anvende den, uden at en agent gennemgår dokumentationen for hver række. Kontrollen af fremgangsmåden hører til ved de beslutninger, der skaber eller ændrer reglen, og igen når en ændret kontrakt gør den tvivlsom.

Et rigtigt svar hentet gennem den forkerte konto er ikke næsten korrekt. Det er en anden opgave.