Marimo notebooks
Python notebooks scoped to a workspace and your managed tables — reactive, governed, no separate data-science stack required.
Marimo notebooks are Python notebooks that run inside your Scrydon cluster, scoped to a workspace, and pre-wired to your managed tables. They're reactive — cells re-run when their inputs change — and they go through the same governance as everything else.
What they're for
| Use case | Why marimo |
|---|---|
| Ad-hoc analysis on a managed table | No need to export — query the table from Python with the user's masks already applied |
| Build a one-off report | Reactive cells make iterating quick |
| Sketch out a feature engineering pipeline before turning it into a workflow | Same data surface, same governance |
| Run model evaluations against historical data | Notebooks can call back into the workflow engine for inference |
How they're scoped
A notebook is owned by a workspace and authenticated against the user who opened it:
- Reads apply the user's masks and row filters.
- Writes to managed tables go through the user's
managed-table:writegrant. - Notebook artefacts (datasets it produces, plots it renders) inherit the workspace's classification by default.
There is no marimo-admin super-user that bypasses governance — the notebook is just another caller.
Built-in helpers
The platform exposes a thin Python library inside each notebook for common operations:
from scrydon import tables, kb, llm
# Read a managed table — column masking already applied
df = tables.read("compliance_authorities")
# Query the knowledge base — clearance already applied
results = kb.search("regulatory framework Q3", limit=10)
# Call an LLM through Cortex — same routing as workflows
answer = llm.complete(model="default", prompt="Summarise the trends in this data: " + df.head().to_string())You can also use any installed Python library — pandas, numpy, scikit-learn, plotly, …
Reactivity
Marimo's reactivity is what makes it useful here. Change a parameter at the top of the notebook (e.g. the table name, the date range, the filter), and every dependent cell re-runs. No stale state, no "run all cells" rituals.
Sharing
Notebooks are workspace-scoped. Sharing a notebook with another workspace member is a one-click op — they get a read-only view that re-runs in their own session, with their own masks applied.
Notebooks do not export raw data. A user with low clearance who opens a notebook produced by a higher-clearance user re-runs the queries under their own identity — they don't see the high-clearance user's cached results.
What they don't do
- Marimo notebooks are not a replacement for the workflow engine. They're for analysis, not for production triggers.
- They don't have a stable schedule / cron. If you need that, build a workflow or an automation.
- They don't expose a public HTTP API. They're a UI surface.
Related
- Architecture → Analytics stack — where marimo sits in the cluster.
- Managed tables — what the notebooks read from.
- Classification & masking — what governance applies.