Den levende tilstand og registret: to hukommelser i et operativsystem for virksomheden

En kreditcontroller åbner godkendelsesindbakken. En agent har foreslået at frigive en tilbageholdt ordre: kunden betalte to forfaldne fakturaer i morges, den åbne saldo er nu inden for grænsen, forslaget henviser til begge betalinger. Hun godkender. Tre måneder senere bestrider kunden et gebyr, og revisoren stiller et enkelt spørgsmål: hvad vidste systemet klokken 09:14 den dag, og hvem besluttede?

Modulerne kan kun svare på den første halvdel, hvis intet er blevet overskrevet siden. Betalingstabellen viser dagens saldo, ikke morgenens. Ordren viser sin nuværende status, ikke den, agenten så. Selve forslaget er væk fra indbakken, fordi det blev udført. Et system, hvor agenter foreslår og mennesker godkender, træffer beslutninger i et tempo, hvor “vi rekonstruerer det” holder op med at være et svar. Det har brug for en anden hukommelse.

Hvorfor modulernes lager ikke kan være den eneste hukommelse

Lageret under modulerne er bygget til én ting: at ændre virksomhedens nuværende tilstand sikkert. Én ordre, én lås, én transaktion, indekser indstillet til at finde en enkelt række hurtigt. Det er præcis, hvad det skal være, og intet her foreslår at erstatte det.

Superintelligensen stiller andre spørgsmål til de samme data, og hvert af dem belaster det lager.

Læsning i stor skala. Et forslag om én kunde læser tusindvis af rækker på tværs af ordrer, fakturaer, betalinger og reklamationer. En model, der vurderer leveringsrisiko for hele ordrebogen, læser millioner. Læsninger af den størrelse konkurrerer med de transaktioner, lageret findes for at beskytte.

Historik. Lageret rummer det, der er sandt nu. De fleste spørgsmål, en agent får, handler om forandring: hvad grænsen var, da ordren blev accepteret, hvor længe denne leverandør har været bagud, om denne kundes margin er faldet tre kvartaler i træk. Et lager, der overskriver, kan ikke svare; en hukommelse, der gemmer versioner, kan.

Hele virksomheden på én gang. Ordren er i salg, reklamationen i kundeservice, pallen på lageret, stoppet i driften. I ét operativsystem deler de datamodel, hvilket er pointen med systemet. De deler stadig ikke et bekvemt sted at læse det hele på én gang uden at røre de tabeller, modulerne skriver til.

Hvad agenten så. Et forslag kan kun forsvares, hvis de data, det blev lavet ud fra, kan vises senere, præcis som de var. Det kræver et øjebliksbillede, ikke en aktuel værdi.

Hurukans svar er to hukommelser under én ontologi: den levende tilstand, som modulerne ændrer sekund for sekund, og registret, en uforanderlig, versioneret historik over hver hændelse, hvert forslag og hver beslutning. Datalaget, der rummer begge, er under opbygning; det følgende er, hvordan det designes.

Hvad registret er lavet af

Registret er ikke et produkt. Det er tre beslutninger, hver truffet én gang.

Filformater er murstenene. Hver hændelse og hvert øjebliksbillede af en tabel skrives til filer i et åbent format. Rækker, der rejser mellem moduler og konnektorer, går som Apache Avro, hvor skemaet rejser med dataene, og kompatibilitet mellem skriver og læser er en formel regel. Data, der ligger stille og læses kolonnevis, går som Apache Parquet, hvor et spørgsmål om to kolonner på tværs af millioner af rækker rører to kolonner. Hvilket format der tjener hvilken opgave, er emnet for Parquet og Avro: hændelsen mellem modulerne og registret, superintelligensen læser.

Et tabelformat er tegningen. Filer alene er en bunke. Et tabelformat — Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon — gemmer de metadata, der siger, hvilke filer der udgør en tabel på et givet tidspunkt, hvad dens skema er, og hvordan den har ændret sig. Fordi filerne selv aldrig redigeres, forbliver hver version af tabellen læsbar: det er der, tidsrejsen (time travel) kommer fra, og med den svaret på “hvad så agenten klokken 09:14”. Valget mellem dem er et valg om revisionssporet, og det træffes i Revisionssporet er en tabel: Delta Lake, Iceberg eller Hudi.

Et katalog siger, hvor sandheden er. Noget skal holde pegepinden til den aktuelle version af hver tabel og afgøre, hvem der må læse den. Det katalog, ikke filerne, er der, hvor suverænitet vindes eller tabes. Det kører på infrastruktur, virksomheden vælger, og laget for sikkerhed og suverænitet behandler det som en del af virksomhedens eget bo.

Hvordan en hændelse rejser

Et modul ændrer den levende tilstand: en betaling bogføres. Den samme ændring udgives som en hændelse under en kontrakt — et navngivet skema med en version. En pipeline lander hændelsen i registret som en ny fil under tabellens metadata, inden for den forsinkelse, forretningen har bedt om. Natlig er nok til en marginrapport. Minutter er nødvendige til en kreditbeslutning. Sekunder er nødvendige til en arbejdskø på fabriksgulvet, og sekunder koster mere end minutter, hvilket er grunden til, at niveauet er en beslutning og ikke en standard.

Registret skrives i én retning. Agenter og superintelligensen læser det sammen med ontologien, der fortæller dem, hvad en “tilbageholdt ordre” eller en “leverandør, der er bagud” betyder. De skriver ikke direkte til det. En agents output er et forslag, der lander i godkendelsesindbakken; et menneske godkender; modulet ændrer den levende tilstand; ændringen udgives som en hændelse; hændelsen lander i registret. Beslutningsloggen er selv en tabel i registret, med forslaget, dets kilder, godkenderen og tidspunktet.

Hvad agenten så, og hvem der besluttede

Den sløjfe er det, der gør revisorens spørgsmål besvarligt. Registret klokken 09:14 er en version af tabellerne, ikke en rekonstruktion. Forslaget er en række med identifikatorerne for de rækker, det læste. Godkendelsen er en række med en persons navn. Intet i kæden afhænger af, at nogen husker.

Den samme egenskab tjener dem, der bygger systemet. Når en ny version af en agent evalueres, kan en dags hændelser afspilles fra registret mod den, og dens forslag sammenlignes med dem, mennesker faktisk godkendte. Registret er evalueringssættet.

Agenter bygger datalaget, under godkendelse

Hurukan bygges og udvides af agenter, og datalaget er ingen undtagelse. En agent udarbejder den pipeline, der lander en ny hændelsestype. En agent foreslår skemaændringen, når et modul får et nyt felt, og kompatibilitetstjekket mod registret over skemaer kører, før nogen læser forslaget. En agent planlægger komprimeringen af små filer og udløbet af gamle øjebliksbilleder. Hvert af disse er et forslag med en diff og et testresultat, og et menneske godkender det. Godkendelsen registreres som enhver anden.

Det, der bliver hos mennesker, er det, der ikke kan fortrydes eller ikke kan udledes: kontrakten mellem moduler, opbevaringen af historik og sletningen af en persons data, valget af format og katalog, og enhver opgradering af en tabels protokol, der ville lukke en ældre læser ude.

Registret, du kan tage med dig

Hver del af registret er i et format, som andre motorer læser. Hvis virksomheden forlader systemet, forlader den det med sin historik: filerne, tabelmetadataene og kataloget, på sin egen infrastruktur. Hvor virksomheden allerede har værktøjer, der læser ét format — et Microsoft-bo, et datterselskab på Snowflake — kan de samme filer eksponeres i det format uden en kopi, hvilket er emnet for Ét register, læsbart for de værktøjer, du allerede har. Og hvor domæneagenter har brug for den levende tilstand snarere end historikken — arbejdskøen, lageret, godkendelsesindbakken — holder et tabelformat bygget til strømme den tilstand læsbar uden at polle modulernes lager, hvilket er argumentet for Paimon.

En test, du kan lave i dag

Tag én beslutning, din virksomhed traf sidste kvartal på grundlag af en rapport: en kreditgrænse, en genbestilling, en pris. Prøv at fremskaffe dataene præcis, som de var den dag, beslutningen blev truffet, og navnet på den person, der traf den. Tæl timerne. Det tal er prisen for at have én hukommelse, og det er det, registret er til for.