Notebooks op geïsoleerde compute
Python op uw beheerde data, in een notebook dat in seconden start, in zijn eigen geïsoleerde compute draait en wordt vernietigd zodra u het sluit. Geen gedeelde kernel, geen kopieën op laptops.
Zijn eigen geïsoleerde compute
Elke notebooksessie start in een geïsoleerde microVM met een gedeclareerde envelop voor CPU, geheugen en opslag — nooit een gedeelde kernel, en vernietigd zodra de sessie eindigt.
Beheerde datatoegang
Notebooks lezen via de ontologie onder dezelfde identiteit en hetzelfde beleid als elke andere workload, dus niemand krijgt een privéachterdeur naar de lakehouse.
Reactief en reproduceerbaar
Wijzig een waarde en alles stroomafwaarts draait opnieuw; afhankelijkheden worden met het notebook gedeclareerd, dus het gedraagt zich hetzelfde voor de volgende die het opent.
Een notebook is waar een analist of datascientist werkelijk werkt: wat Python schrijven, naar de data kijken, plotten, beslissen wat te doen. Het lastige is altijd geweest wáár die code draait en wat ze kan bereiken. Hier draait ze binnen het platform, op compute die van niemand anders is, op data die u toch al mag zien — en ze laat niets achter.
Lees dit als u als analist, datascientist of engineer echte code op echte data nodig hebt, in een omgeving die uw securityteam kan goedkeuren.
Notebooks zijn interactieve Python-omgevingen die binnen het platform draaien op per sessie geïsoleerde compute, die beheerde, ontologiegefundeerde data lezen via dezelfde permissies als elke andere workload, met reproduceerbare afhankelijkheden en zonder persistente runtime die gecompromitteerd kan worden.
Elke organisatie die analytics serieus neemt, eindigt met notebooks, en elk securityteam eindigt er ongemakkelijk bij: een gedeelde Jupyter-server die credentials verzamelt, of erger, een kopie van de data op iemands laptop. De notebooks van Scrydon dichten beide gaten. Elke sessie krijgt haar eigen geïsoleerde compute met een gedeclareerde envelop voor CPU, geheugen en opslag; de runtime wordt door het platform beheerd en is read-only; data wordt bereikt via de ontologie en hetzelfde toegangsbeleid dat de rest van het platform afdwingt; en wanneer de sessie eindigt, wordt de omgeving vernietigd. Notebooks zijn reactief in plaats van voer-de-cellen-op-volgorde-uit, dus een gewijzigde waarde werkt alles bij wat ervan afhangt — en dat is wat een notebook iets maakt dat u aan een collega kunt geven en kunt vertrouwen.
Notebooks in het Scrydon-platform
Eén geïntegreerde, soevereine architectuur. Hier past Notebooks — uitgelicht binnen de volledige stack waarmee het samenwerkt.
Het AI OS voor mensen en AI-agenten
Ontologie- en semantische laag: één samenhangend model voor uw data, kennis en processen
Het beste van data lakes, datawarehouses en search gecombineerd
AI-agenten, workflows en automatiseringen die uitvoeren over al uw systemen heen
Integreer via A2A, MCP, legacy systemen en databronnen
Veilige domeinfederatie, vertrouwd datadelen en intelligentie over organisatiegrenzen heen
Soevereine fundamenten
Notebooks in detail
Analytics
Data die in warehouses en dashboards ligt die niemand leest, is data die niemand kan gebruiken. De Analytics-laag verandert dat — door de juiste mensen de juiste informatie te geven zonder dat zij erom hoeven te vragen. Elke metric is verankerd in de Cognitive Enterprise-ontologie, zodat een omzetcijfer nooit los van zijn context binnenkomt. Data in context — niet alleen in dashboards.
Besluitvormers krijgen een live beeld van de organisatie — financiële prestaties, operationele gezondheid, inkoopstatus — zonder te wachten tot een datateam een rapport klaarzet.
- Interactieve notebooks: Python- en SQL-omgevingen met volledige toegang tot uw lakehouse-data — zonder data te verplaatsen.
- Visuele dashboards: Kant-en-klare rapportage die automatisch meebeweegt met de business — geen handmatige refresh, geen verouderde cijfers.
- Agent-native analytics: AI-agenten kunnen autonoom queryen, samenvatten en handelen op inzichten — en zo de cirkel tussen analyse en actie sluiten.
Cortex is de natuurlijke-taalinterface die menselijke conversatie verbindt met de volledige mogelijkheden van het AI OS. Praat met uw data, start complexe workflows en bevraag uw knowledge graph — allemaal in gewone taal, zonder technische drempel.
- Ontologie-bewust: Begrijpt de structuur van uw enterprise knowledge graph en levert daardoor precieze, contextgevoelige antwoorden.
- Workflowtriggers: Beschrijf wat er moet gebeuren en Cortex routeert het verzoek automatisch naar de juiste Human + AI Orchestrator-processen.
- Multimodale invoer: Accepteert tekst, documenten en gestructureerde data, en baseert antwoorden op uw werkelijke bedrijfsdata in plaats van generieke LLM-kennis.
- Audit trail: Elk gesprek wordt gelogd, is herleidbaar en toetsbaar — zodat u voldoet aan de compliance-eisen van gereguleerde sectoren.
Het Lakehouse is het hoogperformante datafundament onder de Cognitive Enterprise. Het is gebouwd op StarRocks — een razendsnelle, gevectoriseerde MPP-queryengine die analytics binnen een seconde, realtime updates en hoge concurrency levert — en bevraagt open Apache Iceberg-tabellen rechtstreeks. Zo combineert het de flexibiliteit van een data lake met de snelheid van een warehouse, onder één soeverein dak.
- Open Iceberg-tabellen: Bevraag Apache Iceberg en andere open tabelformaten rechtstreeks — uw data blijft van u, zonder proprietary lock-in en zonder dataverplaatsing.
- Bliksemsnelle OLAP: De gevectoriseerde engine, cost-based optimizer en materialised views van StarRocks maken realtime SQL mogelijk — van dashboards tot het redeneren van agenten — zonder dataduplicatie.
- Geïntegreerde vector search: Sla embeddings op en bevraag ze naast traditionele data, waardoor het Lakehouse direct klaar is voor AI-workloads.
Wat notebooks hier doen
Een notebook is hier een interactieve Python-omgeving die binnen het platform opent, naast de data, in plaats van op een laptop of een gedeelde server ergens anders. U schrijft code, bevraagt de lakehouse via de ontologie, plot het resultaat en komt op uw keuzes terug — en omdat het notebook reactief is, draait het wijzigen van één waarde alles opnieuw wat ervan afhangt, in plaats van verouderde output boven en verse output onder achter te laten. De omgeving wordt beschreven door het notebook zelf: de afhankelijkheden die het nodig heeft, worden ermee gedeclareerd, zodat de collega die het volgende maand opent dezelfde omgeving krijgt in plaats van een puzzel. Wanneer een notebook iets heeft aangetoond, kan het worden gepromoveerd tot een geplande pipeline op hetzelfde platform in plaats van door een ander team in een andere taal te worden herschreven.
Draaien in het platform — Het notebook draait naast de data, binnen uw perimeter — er wordt niets naar een laptop geëxporteerd om geanalyseerd te worden.
Starten schoon, elke keer — Een sessie brengt haar eigen compute omhoog met gedeclareerde afhankelijkheden, dus er is geen drift tussen wat u draaide en wat een collega draait.
Reageren op verandering — Bewerk een cel en elke afhankelijke cel wordt bijgewerkt, in plaats van verouderde staat achter te laten waar de volgende lezer over struikelt.
Groeien door naar pipelines — Een notebook dat iets aantoont, kan worden gepromoveerd tot een geplande pipeline in plaats van van nul te worden herschreven.
Waarom notebookgovernance een securityprobleem is
Vraag een securityteam wat hen rond analytics wakker houdt en notebooks komen snel ter sprake. De gebruikelijke opzet is een langlevende notebookserver die iedereen deelt: die verzamelt packages, credentials en andermans staat, en één compromittering bereikt dat allemaal. Het alternatief waar de meeste organisaties in afglijden is erger — het platform is onhandig, dus iemand exporteert een extract en analyseert het op een laptop, en de kopie die niemand beheert is de kopie die het gebouw verlaat.
Er is een tweede, stiller probleem. Een resultaat dat niet opnieuw kan worden gedraaid, kan niet worden gereviewd, en een getal dat niet kan worden gereviewd hoort geen beslissing te voeden die iemand tegenover een raad van bestuur of een toezichthouder moet verdedigen. "Het werkte toen ik het draaide" is geen bewijs.
Beide problemen worden scherper op het moment dat een AI-agent zelf code schrijft en draait. Vanaf dat punt houdt isolatie op analistengemak te zijn en wordt ze een beheersmaatregel — hetzelfde argument, en dezelfde naad, als de sandbox waarin agenten draaien.
Gedeelde kernels stapelen op — Een langlevende notebookserver verzamelt credentials, packages en andermans staat; één compromittering bereikt dat allemaal.
Laptops zijn het echte lek — Als het platform lastig in gebruik is, exporteren analisten een extract — de kopie die niemand beheert, is de kopie die het gebouw verlaat.
Onreproduceerbaar is oncontroleerbaar — Als een resultaat niet opnieuw kan worden gedraaid, kan het niet worden gecontroleerd, en hoort het geen beslissing te voeden die verdedigd moet worden.
Agenten hebben dezelfde naad nodig — Zodra een AI-agent code draait, houden isolatie en beleid op analistengemak te zijn en worden ze een beheersmaatregel.
Geïsoleerde compute, beheerde data, niets blijft achter
Een notebook openen start een eigen sessie: de toegang wordt gecontroleerd, geïsoleerde compute wordt gestart, het notebook en zijn gedeclareerde afhankelijkheden worden geladen, en de dataverbinding wordt onder uw identiteit opgezet. De compute-envelop is expliciet — CPU, geheugen en tijdelijke opslag zijn gedeclareerd, de runtime wordt door het platform beheerd en is read-only, en de hele omgeving wordt vernietigd zodra de sessie eindigt. Er is geen gedeelde kernel tussen gebruikers en geen langlevende host om te hardenen.
Een notebook starten: toegang gecontroleerd, geïsoleerde compute gestart, afhankelijkheden geïnstalleerd, data verbonden. Het computeprofiel wordt benoemd in plaats van aangenomen — en de runtime is read-only en wordt door het platform beheerd.
Data wordt bereikt via de ontologie onder dezelfde identiteit, hetzelfde beleid en dezelfde logging als elke andere workload, dus een notebook is nooit een privéroute naar de lakehouse — datagovernance geldt hier precies zoals voor dashboards en agenten. En omdat afhankelijkheden van binnen de perimeter komen, start hetzelfde notebook op een soevereine cloud, on-premises of op een air-gapped netwerk, zonder externe dienst om aan te roepen.
Isolatie per sessie — Elk notebook krijgt zijn eigen microVM met een expliciet resourceprofiel; de runtime wordt door het platform beheerd en is read-only.
Eén toegangsmodel — Data wordt bereikt via de ontologie onder uw identiteit — dezelfde permissies, logging en DLP-naad als elke andere workload.
Efemeer door constructie — De omgeving bestaat voor de duur van de sessie. Er is geen langlevende notebookhost om te hardenen, patchen of compromitteren.
Soeverein, waar dan ook — Dezelfde notebooks draaien op een soevereine cloud, on-premises of op een losgekoppeld netwerk, zonder externe dienst om aan te roepen.
Veelgestelde vragen
Wat is een soeverein notebook?+
Hoe is elk notebook geïsoleerd?+
Kunnen notebooks bij alle data in de lakehouse?+
Zijn resultaten reproduceerbaar?+
Kan een notebook een productiepipeline worden?+
Werken notebooks als het netwerk losgekoppeld is?+
Hoe verhoudt dit zich tot Cortex?+
Ontdek het platform
Gerelateerd
Schrijft u liever? Mail naar hello [at] scrydon.com en wij nemen contact met u op.
Partners
