Notebooks on Isolated Compute
Python against your governed data, in a notebook that starts in seconds, runs in its own isolated compute, and is destroyed when you close it. No shared kernel, no laptop copies.
Its Own Isolated Compute
Each notebook session starts in an isolated microVM with a declared CPU, memory and storage envelope — never a shared kernel, and destroyed when the session ends.
Governed Data Access
Notebooks read through the ontology under the same identity and policy as every other workload, so nobody gets a private back door to the lakehouse.
Reactive and Reproducible
Change a value and everything downstream re-runs; dependencies are declared with the notebook, so it behaves the same for the next person who opens it.
A notebook is where an analyst or data scientist actually works: write some Python, look at the data, plot it, decide what to do. The awkward part has always been where that code runs and what it can reach. Here it runs inside the platform, on compute that belongs to nobody else, against data you are already allowed to see — and it leaves nothing behind.
Read this if you're an analyst, data scientist or engineer who needs real code against real data, in an environment your security team can sign off.
Notebooks are interactive Python environments running inside the platform on per-session isolated compute, reading governed, ontology-grounded data through the same permissions as every other workload, with reproducible dependencies and no persistent runtime to compromise.
Every organisation that takes analytics seriously ends up with notebooks, and every security team ends up uneasy about them: a shared Jupyter server that accumulates credentials, or worse, a copy of the data on someone's laptop. Scrydon's notebooks close both gaps. Each session gets its own isolated compute with a declared CPU, memory and storage envelope; the runtime is platform-managed and read-only; data is reached through the ontology and the same access policy the rest of the platform enforces; and when the session ends the environment is destroyed. Notebooks are reactive rather than run-the-cells-in-order, so a changed value updates everything that depends on it — which is what makes a notebook something you can hand to a colleague and trust.
Notebooks in the Scrydon platform
One integrated, sovereign architecture. Here is where Notebooks sits — highlighted against the full stack it works with.
The AI OS for Humans & AI Agents
Ontology & Semantic Layer, one connected model for your data, knowledge & processes
Combining the best of data lakes, data warehouses and search
AI agents, workflows & automations that execute across your systems
Integrate across A2A, MCP, legacy systems and data sources
Secure domain federation, trusted data sharing, and cross-boundary intelligence
Sovereign Foundations
Notebooks in depth
Analytics
Data sitting in warehouses and dashboards that nobody reads is data they can't use. The Analytics layer changes that — giving the right people the right information without them having to ask for it. Every metric is anchored to the Cognitive Enterprise ontology, so a revenue figure doesn't arrive in isolation. Data in context — not just in dashboards.
Decision-makers get a live view of the enterprise — financial performance, operational health, procurement status — without waiting for a data team to prepare a report.
- Interactive notebooks: Python and SQL environments with full access to your lakehouse data — no data movement required.
- Visual dashboards: Pre-built, always-current reporting updated automatically as the business moves — no manual refresh, no stale numbers.
- Agent-native analytics: AI agents can query, summarise, and act on insights autonomously — closing the loop between analysis and action.
Cortex is the natural language interface that bridges human conversation and the full capabilities of the AI OS. Speak to your data, trigger complex workflows, and interrogate your knowledge graph — all in plain language, with no technical barrier.
- Ontology-aware: Understands the structure of your enterprise knowledge graph, enabling precise, context-sensitive answers.
- Workflow triggers: Describe what you want to happen and Cortex automatically routes the request to the right Human + AI Orchestrator processes.
- Multi-modal input: Accepts text, documents, and structured data, grounding responses in your actual enterprise data rather than generic LLM knowledge.
- Audit trail: Every conversation is logged, attributable, and reviewable — meeting compliance requirements for regulated industries.
The Lakehouse is the high-performance data foundation underpinning the Cognitive Enterprise. It is built on StarRocks — a blazing-fast, vectorised MPP query engine delivering sub-second analytics, real-time updates, and high concurrency — and queries open Apache Iceberg tables directly, merging the flexibility of a data lake with the speed of a warehouse under a single, sovereign roof.
- Open Iceberg tables: Query Apache Iceberg and other open table formats directly — your data stays yours, with no proprietary lock-in and no data movement.
- Lightning OLAP: StarRocks' vectorised engine, cost-based optimiser, and materialised views power real-time SQL — from dashboards to agent reasoning — without data duplication.
- Integrated Vector Search: Store and query embeddings alongside traditional data, making the Lakehouse instantly ready for AI workloads.
What notebooks do here
A notebook here is an interactive Python environment that opens inside the platform, beside the data, rather than on a laptop or a shared server somewhere else. You write code, query the lakehouse through the ontology, plot the result, and change your mind — and because the notebook is reactive, changing one value re-runs everything that depends on it instead of leaving stale output above and fresh output below. The environment is described by the notebook itself: the dependencies it needs are declared with it, so the colleague who opens it next month gets the same environment rather than a puzzle. When a notebook has proven something, it can be promoted into a scheduled pipeline on the same platform instead of being rewritten by another team in another language.
Run in the platform — The notebook runs next to the data, inside your perimeter — nothing is exported to a laptop to be analysed.
Start clean, every time — A session brings up its own compute with declared dependencies, so there is no drift between what you ran and what a colleague runs.
React to change — Edit a cell and every dependent cell updates, instead of leaving stale state behind for the next reader to trip over.
Graduate into pipelines — A notebook that proves something can be promoted into a scheduled pipeline rather than rewritten from scratch.
Why notebook governance is a security problem
Ask a security team what keeps them awake about analytics and notebooks come up fast. The usual arrangement is a long-lived notebook server that everyone shares: it accumulates packages, credentials and other people's state, and one compromise reaches all of it. The alternative most organisations drift into is worse — the platform is awkward, so someone exports an extract and analyses it on a laptop, and the copy nobody governs is the one that leaves the building.
There is a second, quieter problem. A result that cannot be re-run cannot be reviewed, and a number that cannot be reviewed should not inform a decision anyone has to defend to a board or a regulator. "It worked when I ran it" is not evidence.
Both problems get sharper the moment an AI agent writes and runs code of its own. At that point isolation stops being an analyst convenience and becomes a control — the same argument, and the same seam, as the sandbox agents run in.
Shared kernels accumulate — A long-lived notebook server collects credentials, packages and other people's state; one compromise reaches all of it.
Laptops are the real leak — When the platform is hard to use, analysts export an extract — the copy nobody governs is the one that leaves the building.
Irreproducible is unreviewable — If a result cannot be re-run, it cannot be checked, and it should not inform a decision that has to be defended.
Agents need the same seam — The moment an AI agent runs code, isolation and policy stop being an analyst convenience and become a control.
Isolated compute, governed data, nothing left behind
Opening a notebook starts a session of its own: access is checked, isolated compute is started, the notebook and its declared dependencies are loaded, and the data connection is established under your identity. The compute envelope is explicit — CPU, memory and temporary storage are declared, the runtime is platform-managed and read-only, and the whole environment is destroyed when the session ends. There is no shared kernel between users and no long-lived host to harden.
Starting a notebook: access checked, isolated compute started, dependencies installed, data connected. The compute profile is stated rather than assumed — and the runtime is read-only and platform-managed.
Data is reached through the ontology under the same identity, policy and logging as every other workload, so a notebook is never a private route into the lakehouse — data governance applies here exactly as it does to dashboards and agents. And because dependencies come from inside the perimeter, the same notebook starts on a sovereign cloud, on-premises, or on an air-gapped network with no outside service to call.
Per-session isolation — Each notebook gets its own microVM with an explicit resource profile; the runtime is platform-managed and read-only.
One access model — Data is reached through the ontology under your identity — the same permissions, logging and DLP seam as every other workload.
Ephemeral by construction — The environment exists for the session. There is no long-lived notebook host to harden, patch or compromise.
Sovereign anywhere — The same notebooks run on a sovereign cloud, on-premises, or on a disconnected network, with no outside service to call.
Frequently asked questions
What is a sovereign notebook?+
How is each notebook isolated?+
Can notebooks reach any data in the lakehouse?+
Are results reproducible?+
Can a notebook become a production pipeline?+
Do notebooks work when the network is disconnected?+
How does this relate to Cortex?+
Explore the platform
Related
Prefer to write? Email hello [at] scrydon.com and we will get back to you.
Partners
