Det tekniske svaret på hva dette er under panseret
Arkitektur
Produktsidene er skrevet for dem som skal signere. Denne er skrevet for den som skal drifte, og sier hva plattformen består av, hvor dataene ligger, og hva dere tar på dere hvis dere hoster den selv.
Veien inn
Fire veier inn, ett sted å lande
Uansett hvordan dataene kommer, lander de under samme modell med samme regler. Kollektorer ute ved kilden står ved siden av kontrollsystemene og snakker OPC-UA og Modbus. Den innebygde flytmotoren, som kommer snart, kjører små prosessorfunksjoner som renser, konverterer og avleder mens dataene strømmer gjennom. Et enkelt REST-API tar imot fra alt som kan snakke HTTP, og SDK-ene gjør innlasting til vanlig, testbar kode i Java, Python eller Rust.
Uansett hvordan de kommer, kommer de en gang: samme modell, samme rettigheter, samme spor.
Flytmotoren
En motor, hver pipeline
Først det ærlige forbeholdet: flytmotoren bygges akkurat nå, i det åpne, og kommer snart. En flyt er en liten pipeline: les data fra et sted, transformer eller sjekk dem, skriv dem et sted, på en tidsplan, når en hendelse kommer, eller når noen ber om det. Hvert steg er en funksjon som deklarerer utfallene sine, og koblingene ruter på dem, så «hva skjer ved feil» tegnes i definisjonen i stedet for å ligge begravd i et skript. En flyt er en versjonert definisjon, ikke en cron-jobb på en server: valider den, forhåndsvis den mot den siste timen uten å skrive noe, sett den i drift, og følg kjøringene.
Motoren er grunnen til at plattformens løfter holder overalt. Hvert steg registrerer opphav, hvert kontrollpunkt registrerer kvalitet, og det samme maskineriet er designet for å bære det som kommer: agentorkestrering, policyer, change-data-capture, henting fra eksterne systemer. En motor under alt sammen, i stedet for en mekanisme per funksjon, og alt dere bygger på den, spiller sammen med alt annet.
En pipeline er en definisjon
En endring lager en ny versjon, gamle versjoner beholdes, og hver kjøring registrerer versjonen den brukte. Hva som kjørte i mars, kan besvares i november, og det er det som gjør revisjonssporet ekte.
Deres kode, innenfor gjerdet
De fleste steg er konfigurerte innebygde funksjoner. Når de ikke strekker til, laster dere opp deres egen i Python eller WebAssembly: den skannes, gjennomgås og godkjennes av et menneske før den kan settes i drift, og den kjører alltid i en sandkasse, uansett hva gjennomgangen sa.
Dør et sted, fullfører et annet
Instansene er identiske og deler arbeidet gjennom leaser: en kjøring på en instans som dør, plukkes opp av en annen innen et minutt, og kilder kvitteres først når en kjøring er fullført, så kapasitet og robusthet er et spørsmål om antall instanser.
Nye muligheter er nye flyter, og hver flyt arver opphav, kvalitet og gjerdet.
Der dataene ligger
Hvert lager gjør det ene det er best på
Generisk lagring er slik plattformer blir trege og dyre på samme tid. Målinger og hendelser går til ClickHouse, kolonnebasert og bygget for å skanne milliarder av rader. Kunnskapsgrafen ligger i Neo4j, der det å følge en relasjon er et steg, ikke en join. PostgreSQL holder ontologiens definisjoner og plattformens egne data. Mellom dem bærer Apache Pulsar hvert datapunkt, hver ressursendring og hver hendelse som en strøm, med Valkey og Kvrocks for hurtigbuffer og varige nøkkeloppslag. Dere snakker aldri med noen av dem direkte: alt går gjennom modellen.
Dere spør modellen. Hvor bytene ligger, er plattformens problem.
Veien ut
Ett API, og alt er en klient av det
Konsollet er ikke spesielt, SDK-ene er ikke spesielle og agentene er ikke spesielle: alle går gjennom det samme tilstandsløse REST-API-et, med sanntidsverdier strømmet over WebSocket-abonnementer. Identitet kommer fra Keycloak, hvert kall bærer et token som sier hvem som spør, og tilgang per datasett avgjøres av de samme reglene uansett hvem som kaller.
En flate å sikre
Ett API betyr ett sted der rettigheter håndheves og logges. Det finnes ingen sidedør for interne verktøy, fordi de interne verktøyene bruker samme dør.
Tre SDK-er over
Java, Python og Rust, lisensiert Apache-2.0, så deres egen kode berøres aldri av copyleft. Kan konsollet gjøre det, kan koden deres gjøre det.
Agenter gjennom MCP
En agent når modellen gjennom en MCP-server i stedet for en egen integrasjon. Hva den får lese og endre, er samme policyspørsmål som for et menneske, besvart av de samme reglene.
Lagringsøkonomi
Full oppløsning på historikken, fordi det er billig å beholde den
Kolonnebasert lagring endrer de to tallene som pleide å tvinge frem nedsampling. Industrielle tidsserier komprimeres rundt 100 ganger, fordi naboverdier ligner på hverandre og en kolonne av dem lar seg presse godt sammen. Og en skanning leser bare kolonnene spørringen ber om, og det er slik ClickHouse leser over 10 milliarder rader per sekund i vårt oppsett. Ti år med sekundoppløst historikk slutter å være en diskusjon om lagringstid.
Krympingen er ikke magi: tidsstempler og verdier som beveger seg sakte, lagres som deltaer og komprimeres med ZSTD, og flyttallssignaler bruker Gorilla-koding, oppfunnet for akkurat denne typen data. Og taket er fortsatt på vei opp: ALP, adaptiv tapsfri flyttallskomprimering, slår dagens kodeker på både kompresjonsgrad og hastighet, og det er dit vi skal videre.
Drift
Host den selv, eller kjør på maskinvare vi eier
Selvhosting er Docker Compose for et lite oppsett, eller rett på jernet når maskinene skal være deres, og det er ekte selvhosting: PostgreSQL, ClickHouse, Neo4j, Pulsar og plattformtjenestene er deres å kjøre, oppgradere og sikkerhetskopiere. Det hostede alternativet kjører på maskiner vi eier i Stavanger: AlmaLinux på over 50 servere med 30 TB RAM, ZFS på 2 PB disk og 400 TB SSD, med InfiniBand og NVMe-oF over RDMA imellom. Orkestreringsprogramvaren som kjører det, har vi skrevet selv, liten nok til å feilsøke, og vi følger med på den i Grafana som alle andre.
Hva dere påtar dere å drifte
Selvhosting er ekte selvhosting. Dere kjører PostgreSQL, ClickHouse, Neo4j, Pulsar og plattformtjenestene, og oppgraderinger og sikkerhetskopier er deres. Det er en reell driftsbelastning, og det er prisen for at koden er deres under AGPL-3.0. Vil dere heller slippe, drifter vi den på maskinvare vi eier og drifter selv.
Vanlige spørsmål
Spurt og besvart
Hva kjører IntelliStream på under panseret?
PostgreSQL for ontologien og plattformens egne data, ClickHouse for tidsserier og hendelser, Neo4j for kunnskapsgrafen, Apache Pulsar for strømmer, med Valkey og Kvrocks for buffer og nøkkeloppslag, og Keycloak for identitet. Alt er åpen kildekode. Selve plattformen er AGPL-3.0, mens klient-SDK-ene er Apache-2.0, så koden dere skriver mot dem, berøres aldri av copyleft.
Kan vi hoste den selv, og hva krever det?
Ja, med Docker Compose for et lite oppsett eller rett på jernet. Det er ekte selvhosting: dere kjører databasene, meldingsmegleren og plattformtjenestene, og oppgraderinger og sikkerhetskopier er deres. Vil dere heller slippe den belastningen, hoster vi samme plattform på maskinvare vi eier i Stavanger.
Hvordan kobler AI-agenter seg til plattformen?
Gjennom en MCP-server som står foran det samme API-et alt annet bruker. Agenten autentiserer seg som et menneske, via Keycloak, og tilgang per datasett vurderes likt. Det finnes ingen egen agentvei å sikre eller revidere.
Hvorfor ClickHouse for tidsserier?
Fordi industrielle tidsserier er akkurat det kolonnebasert lagring er god på. Naboverdier ligner på hverandre, så de komprimeres rundt 100 ganger, og skanninger leser bare kolonnene spørringen berører, og det er slik den leser over 10 milliarder rader per sekund i vårt oppsett. Full oppløsning på historikken blir overkommelig i stedet for uoppnåelig.
Hvorfor Apache Pulsar for strømmer?
Fordi strømmen er der alt møtes: hvert datapunkt, hver ressursendring og hver hendelse går gjennom Pulsar-topics på vei til lagrene. Pulsar har tenants som førsteklasses begrep, så isolasjon ikke må ettermonteres, og abonnementsmarkører ligger hos brokeren, så en konsument, eller et WebSocket-abonnement i sanntid, kan falle ut, koble til på en annen instans og fortsette der den slapp. Det lar også en strøm mate to svært ulike konsumenter i hvert sitt tempo: batchede innsettinger i ClickHouse og rekkefølgesensitive oppdateringer i grafen.
Hvorfor Valkey?
Til dataene som bør ligge i minnet fordi det ikke koster noe å miste dem: sesjoner og hurtigbuffer. Eksternaliserte sesjoner er det som lar enhver instans svare på enhver forespørsel. Valkey er det Redis-kompatible lageret som styres av Linux Foundation, og det betyr noe for oss fordi hele stacken er åpen kildekode, og slik skal den forbli. Og i vårt hostede oppsett kjører den på 2 TB Intel Optane-minne per buffernode, så hurtigbufferen måles i terabyte, ikke gigabyte.
Hvorfor Kvrocks?
Kvrocks snakker samme protokoll som Valkey, men holder dataene på disk, så en omstart mister ingenting og minnet forblir reservert til arbeidet som faktisk trenger det. I bunnen ligger RocksDB, og den støtter transaksjoner. Samme grensesnitt, ulikt løfte.
Hvorfor Neo4j for kunnskapsgrafen?
Fordi modellen for det meste er relasjoner, og Neo4j lagrer relasjoner som førsteklasses data i stedet for å gjenskape dem gjennom joins, så det å følge en er et konstant steg uansett hvor stor grafen blir. Cypher holder spørringene lesbare, for ingeniører og for agenter, og nye typer relasjoner legges til uten skjemamigrering, som er akkurat slik en driftsmodell faktisk utvikler seg.
Hvorfor Keycloak for identitet?
Fordi identitet er det siste en plattform bør finne opp selv. Keycloak er den modne identitetsleverandøren i åpen kildekode: den utsteder tokenene hvert kall bærer, og tilgang per datasett følger organisasjonsgruppene dens. Vel så viktig: den har utmerket integrasjon med Microsoft Entra ID, der de fleste industribedrifter allerede har folkene sine, så ingeniørene deres logger inn med kontoen de allerede har, og offboarding skjer fortsatt på ett sted, i deres egen katalog.
Les den før dere snakker med noen
Plattformdokumentasjonen dekker utrulling og drift. SDK-dokumentasjonen dekker hvordan dere skriver kode mot den. Begge er åpne, og ingen av dem spør om en epostadresse først.