Overvåking er ikke skraping — det er å huske forrige gang

Vi bygde en overvåking av en varekatalog for gjenbruksmaterialer i tre byer: Askim, Trondheim og Verdal. Den kjører seks moduler. Fem av dem er selvforklarende. Den sjette — nei, den tredje — er den eneste som gjør dette til overvåking i det hele tatt.

---

---

Forskjellen på å hente og å overvåke

En skraper svarer på «hva står det der nå». Den gjør det like godt hver eneste gang, og etter tredje kjøring er svaret verdiløst, fordi du allerede vet hva som står der.

En overvåking svarer på «hva er annerledes siden sist». For å kunne det, må den huske sist.

Det høres trivielt ut. I praksis er det stedet folk hopper over, fordi minnet ikke gjør noe synlig. Det ser ut som et unødvendig lagringssteg midt i en ellers ren kjede.

---

De seks modulene

01 — Tre byer. En liste med tre oppslag: by, nøkkel, URL. Legger du til en fjerde by, legger du til én linje. Ingenting annet i kjeden endres.

02 — Hent nå. Vanlig HTTP-henting av byens produktside. Vi tar bort HTML-en og beholder teksten fra og med der produktlisten begynner, kappet ved 7 000 tegn.

03 — Les forrige fra minnet. Vi slår opp samme nøkkel i en base og får gårsdagens kopi. Er den tom, er dette første kjøring.

04 — Sammenlign. En språkmodell får begge blokkene og skal svare med én av tre statuser: BASELINE hvis det ikke finnes noe forrige, UENDRET hvis de er praktisk talt like, ENDRET med en liste hvis de ikke er det.

05 — Skriv nytt minne. Dagens kopi overskriver nøkkelen og blir morgendagens forrige.

06 — Rapport til Notion. Én rad per by per døgn: dato, sted, hva som endret seg.

---

Hvorfor en språkmodell gjør sammenligningen

Det naturlige er en tekstlig diff. Den fungerer dårlig her, fordi kilden er en tett produktliste uten linjeskift — kategori, navn, antall og pris limt sammen på rad. En linjebasert diff ser én lang linje som er litt annerledes, og rapporterer at alt er endret.

Modellen får i stedet i oppgave å gruppere endringene per kategori og skille mellom tre ting: ny vare, fjernet vare, prisendring.

Instruksen inneholder to setninger som gjør mesteparten av arbeidet:

> OBLIGATORISK TO-VEIS SJEKK: hvert produkt i FORRIGE — finnes det i > NÅVÆRENDE? Mangler = FJERNET.

> KRITISK GROUNDING: rapporter KUN faktiske forskjeller. Ikke finn på noe.

Den første fordi en modell som får to lister uten videre legger merke til det som er kommet til, og overser det som er borte. Fjerninger er ofte det mest interessante — en vare som forsvinner er solgt.

Den andre fordi en modell som blir bedt om å rapportere endringer, og ikke finner noen, har en tendens til å finne på en.

---

Veggen: 7 000 tegn

Snapshotet er kappet ved 7 000 tegn. Det er ikke et vilkårlig tall — det er det som får plass innenfor det modellen skal lese uten at kostnaden per kjøring blir uforholdsmessig.

Men det er et tak, og det oppfører seg stygt hvis katalogen vokser forbi det. Da faller halen ut av snapshotet, og sammenligningen vil rapportere at halen er FJERNET — hver eneste dag, om og om igjen, uten at noe faktisk er borte.

Det er en feil som ikke stopper noe. Den bare lyver rolig. Riktig svar er en kontroll på lengden med varsel når snapshotet treffer taket, ikke et høyere tak.

---

Den står av nå

Overvåkingen er skrudd av. Den ble bygget for et kundeoppdrag som ikke gikk videre, og vi lot den stå avslått i stedet for å la den skrive rapporter ingen leser.

Vi nevner det fordi det er lett å skrive om automatisering som om alt man har bygget kjører. Det gjør det ikke. Av 388 scenarioer i plattformen vår er 232 slått på. De øvrige 156 er verktøy som kalles ved behov, arkiverte forsøk, og noen få som denne — bygget, virker, men står stille til noen trenger dem.

Å slå den på igjen er ett klikk. Det er hele poenget med å bygge den slik.

---

Kort vei til svaret

Skal du overvåke en kilde — en konkurrents priser, et register, en katalog — er spørsmålet du bør stille ikke «kan dere hente den», men «hvor lagres forrige tilstand, og hva skjer når kilden vokser».

Les hvordan vi bygger automatisering med stoppunkt