A source-backed collection for private research workflows: local-first planning, reproducible notebooks, local analytical processing, redaction, human review datasets, trace review, and secret scanning before outputs are shared.
This collection is workflow guidance; each linked notebook, database, labeling, tracing, or scanning tool can still execute code or process sensitive data., Keep private research data out of hosted model prompts, public notebooks, shared traces, and exported datasets unless the data owner has approved that route., Run secret and sensitive-data checks before committing notes, prompts, labels, notebook outputs, or generated reports.
Privacy notes
Research workspaces can contain source documents, interview notes, citations, prompt drafts, labels, embeddings, traces, screenshots, and derived conclusions., Notebook outputs, DuckDB files, Polars exports, Label Studio projects, TruLens traces, and scanner reports may retain private content after the original source is deleted., Local-first tools reduce unnecessary sharing, but backups, sync folders, telemetry, browser downloads, and collaboration platforms still need retention and access-control review.
Author
MkDev11
Submitted by
MkDev11
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
3 safety and 3 privacy notes across 5 risk areas. Review closely: credentials & tokens, network access.
5 areas
SafetyExecution & processesThis collection is workflow guidance; each linked notebook, database, labeling, tracing, or scanning tool can still execute code or process sensitive data.
SafetyGeneralKeep private research data out of hosted model prompts, public notebooks, shared traces, and exported datasets unless the data owner has approved that route.
SafetyCredentials & tokensRun secret and sensitive-data checks before committing notes, prompts, labels, notebook outputs, or generated reports.
PrivacyGeneralResearch workspaces can contain source documents, interview notes, citations, prompt drafts, labels, embeddings, traces, screenshots, and derived conclusions.
PrivacyLocal filesNotebook outputs, DuckDB files, Polars exports, Label Studio projects, TruLens traces, and scanner reports may retain private content after the original source is deleted.
PrivacyNetwork accessLocal-first tools reduce unnecessary sharing, but backups, sync folders, telemetry, browser downloads, and collaboration platforms still need retention and access-control review.
Safety notes
This collection is workflow guidance; each linked notebook, database, labeling, tracing, or scanning tool can still execute code or process sensitive data.
Keep private research data out of hosted model prompts, public notebooks, shared traces, and exported datasets unless the data owner has approved that route.
Run secret and sensitive-data checks before committing notes, prompts, labels, notebook outputs, or generated reports.
Privacy notes
Research workspaces can contain source documents, interview notes, citations, prompt drafts, labels, embeddings, traces, screenshots, and derived conclusions.
Notebook outputs, DuckDB files, Polars exports, Label Studio projects, TruLens traces, and scanner reports may retain private content after the original source is deleted.
Local-first tools reduce unnecessary sharing, but backups, sync folders, telemetry, browser downloads, and collaboration platforms still need retention and access-control review.
Prerequisites
A written research data boundary that separates public sources, licensed material, private notes, customer data, and restricted datasets.
A local or approved private workspace for notebooks, data files, labels, traces, prompts, and exports.
Redaction rules for prompts, extracted passages, tabular data, labels, traces, screenshots, and final reports.
Agreement on which outputs can leave the local workspace and which require review before sharing.
## What this collection sets up
This collection helps researchers and AI-assisted teams keep sensitive research
work close to the operator until it has been reviewed. It combines local-first
workspace planning, reproducible notebooks, local analytical tools, human label
review, trace inspection, and secret scanning into a workflow that separates
private source material from shareable findings.
It is not a guarantee of privacy by itself. The goal is to make data movement
visible: what enters the workspace, what tools process it, what gets logged,
what becomes an export, and what must be redacted before a teammate, model
provider, or public repository sees it.
## Layers
### 1. Local-first research boundary
- **local-first-ai-dev-stack** establishes the starting posture: keep private
work in a controlled local or approved private environment before using
hosted services.
- **prompt-context-hygiene-long-coding-sessions** helps keep prompts, handoff
notes, and long-running context summaries free of unnecessary private data.
### 2. Reproducible notebooks and local analysis
- **marimo** gives research notebooks a reviewable, git-friendly Python source
format and supports local notebook, app, and script workflows.
- **duckdb** handles local analytical queries against files and embedded
datasets without starting a separate database service.
- **polars** supports fast DataFrame processing for tabular cleanup, joins,
filtering, and export preparation.
### 3. Review, traces, and redaction checks
- **label-studio** supports human review and annotation, but should receive only
data that has passed the team's redaction policy.
- **trulens** is useful for inspecting RAG or agent traces, with special care
around retrieved context and model-provider payloads.
- **sensitive-data-alert-scanner**, **pre-write-secret-scanner**, and
**gitleaks** help catch secrets or sensitive content before research outputs
become commits, shared files, or public artifacts.
## Suggested order
Start by writing the data boundary and deciding which sources are allowed in the
workspace. Set up the local-first environment and prompt hygiene rules before
importing private material. Use Marimo, DuckDB, and Polars for reproducible
analysis. Add Label Studio or TruLens only after redaction and retention rules
are clear. Finish by scanning final notes, labels, prompt sets, notebook
exports, and report drafts before sharing them.
## Review checklist
- [ ] {"task": "Data classes are named", "description": "Public, licensed, internal, customer, and restricted data are separated before analysis"}
- [ ] {"task": "Workspace is local or approved", "description": "Research artifacts stay in a reviewed location with access controls and backup policy"}
- [ ] {"task": "Prompt payloads are filtered", "description": "Hosted model calls do not receive raw private notes, secrets, or unnecessary source excerpts"}
- [ ] {"task": "Exports are reviewed", "description": "CSV, Parquet, notebook, screenshot, trace, and report outputs are checked before sharing"}
- [ ] {"task": "Labels are scoped", "description": "Human review tools receive only the fields reviewers need"}
- [ ] {"task": "Scanners run before commit", "description": "Sensitive-data and secret scanners check exported artifacts and repository changes"}
## Source and references
- NIST Privacy Framework: https://www.nist.gov/privacy-framework
- DuckDB clients overview: https://duckdb.org/docs/stable/clients/overview
- Marimo getting started: https://docs.marimo.io/getting_started/
- Polars getting started: https://docs.pola.rs/user-guide/getting-started/
- Label Studio guide: https://labelstud.io/guide/
- TruLens quickstart: https://www.trulens.org/getting_started/quickstarts/quickstart/
- Gitleaks repository: https://github.com/gitleaks/gitleaks
## Duplicate check
Checked existing collections, guides, tools, MCP entries, skills, hooks, open
PRs, and issue history for `privacy-first-research-workflow`, privacy-first
research, local-first research, private research, notebook privacy, DuckDB,
Polars, Marimo, Label Studio, TruLens, Gitleaks, and redaction workflows.
Existing collections cover open-source evals, secure workstations, data
engineering, production readiness, and frontend QA. They do not provide a
focused privacy-first research workflow that combines local-first boundaries,
reviewable notebooks, local data processing, labeling, trace review, and
pre-share secret or sensitive-data checks.
## Disclosure
Editorial collection. No paid placement or affiliate link is used.
About this resource
What this collection sets up
This collection helps researchers and AI-assisted teams keep sensitive research
work close to the operator until it has been reviewed. It combines local-first
workspace planning, reproducible notebooks, local analytical tools, human label
review, trace inspection, and secret scanning into a workflow that separates
private source material from shareable findings.
It is not a guarantee of privacy by itself. The goal is to make data movement
visible: what enters the workspace, what tools process it, what gets logged,
what becomes an export, and what must be redacted before a teammate, model
provider, or public repository sees it.
Layers
1. Local-first research boundary
local-first-ai-dev-stack establishes the starting posture: keep private
work in a controlled local or approved private environment before using
hosted services.
prompt-context-hygiene-long-coding-sessions helps keep prompts, handoff
notes, and long-running context summaries free of unnecessary private data.
2. Reproducible notebooks and local analysis
marimo gives research notebooks a reviewable, git-friendly Python source
format and supports local notebook, app, and script workflows.
duckdb handles local analytical queries against files and embedded
datasets without starting a separate database service.
polars supports fast DataFrame processing for tabular cleanup, joins,
filtering, and export preparation.
3. Review, traces, and redaction checks
label-studio supports human review and annotation, but should receive only
data that has passed the team's redaction policy.
trulens is useful for inspecting RAG or agent traces, with special care
around retrieved context and model-provider payloads.
sensitive-data-alert-scanner, pre-write-secret-scanner, and
gitleaks help catch secrets or sensitive content before research outputs
become commits, shared files, or public artifacts.
Suggested order
Start by writing the data boundary and deciding which sources are allowed in the
workspace. Set up the local-first environment and prompt hygiene rules before
importing private material. Use Marimo, DuckDB, and Polars for reproducible
analysis. Add Label Studio or TruLens only after redaction and retention rules
are clear. Finish by scanning final notes, labels, prompt sets, notebook
exports, and report drafts before sharing them.
Review checklist
{"task": "Data classes are named", "description": "Public, licensed, internal, customer, and restricted data are separated before analysis"}
{"task": "Workspace is local or approved", "description": "Research artifacts stay in a reviewed location with access controls and backup policy"}
{"task": "Prompt payloads are filtered", "description": "Hosted model calls do not receive raw private notes, secrets, or unnecessary source excerpts"}
{"task": "Exports are reviewed", "description": "CSV, Parquet, notebook, screenshot, trace, and report outputs are checked before sharing"}
{"task": "Labels are scoped", "description": "Human review tools receive only the fields reviewers need"}
{"task": "Scanners run before commit", "description": "Sensitive-data and secret scanners check exported artifacts and repository changes"}
Checked existing collections, guides, tools, MCP entries, skills, hooks, open
PRs, and issue history for privacy-first-research-workflow, privacy-first
research, local-first research, private research, notebook privacy, DuckDB,
Polars, Marimo, Label Studio, TruLens, Gitleaks, and redaction workflows.
Existing collections cover open-source evals, secure workstations, data
engineering, production readiness, and frontend QA. They do not provide a
focused privacy-first research workflow that combines local-first boundaries,
reviewable notebooks, local data processing, labeling, trace review, and
pre-share secret or sensitive-data checks.
Disclosure
Editorial collection. No paid placement or affiliate link is used.
Show that Privacy-First Research Workflow is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/collections/privacy-first-research-workflow)
How it compares
Privacy-First Research Workflow side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
1 trust signal differ across this comparison (Submitter).
Next steps differ across entries — use the actions in the table below to copy install commands and source links per resource.
A source-backed collection for private research workflows: local-first planning, reproducible notebooks, local analytical processing, redaction, human review datasets, trace review, and secret scanning before outputs are shared.
Run the parts of your AI dev workflow that touch your code and data — tools, memory, and auxiliary models — on infrastructure you control, while still using Claude as the orchestrator. A practical architecture for a self-hosted, privacy-first developer stack.
Apache-2.0 reactive Python notebook stored as pure Python for reproducible experiments, SQL-backed data workflows, script execution, app deployment, and AI-assisted editing.
✓This collection is workflow guidance; each linked notebook, database, labeling, tracing, or scanning tool can still execute code or process sensitive data.
Keep private research data out of hosted model prompts, public notebooks, shared traces, and exported datasets unless the data owner has approved that route.
Run secret and sensitive-data checks before committing notes, prompts, labels, notebook outputs, or generated reports.
✓Exposing MCP servers over HTTP makes their tools reachable on the network — run them on a trusted/private network or behind authentication, never a public interface.
Self-hosted services are yours to patch and secure; a local model runtime executes code/tools on your machine, so only run models and servers you trust.
✓Marimo notebooks execute Python and SQL, can write files, query databases, call APIs, access object storage, install packages, and start web servers, so notebooks should be treated as trusted project code.
Reactive execution automatically tracks variable dependencies and can run downstream cells after upstream changes; expensive, destructive, or side-effectful cells need lazy runtime, disabled cells, startup autorun, and manual-run policies.
The docs note that Marimo tracks variable definitions and references statically, not arbitrary mutations across cells, so mutable shared state should be designed carefully to avoid misleading results.
App mode uses `marimo run` to serve notebooks as web apps with code hidden by default, but public deployments still need authentication, authorization, rate limiting, reverse proxy policy, and traceback disclosure review.
Disabling token protection, passing access tokens in URLs, or exposing edit servers can give unauthorized users access to notebook execution and should be avoided outside controlled environments.
SQL cells can interpolate Python values, query local files and remote databases, and use engines or extensions such as DuckDB, so SQL strings, credentials, object paths, and output destinations should be reviewed before automation.
Built-in AI and copilot features may inspect notebook code, prompts, tool context, and referenced variable values; provider selection, API keys, local model behavior, and cost controls should be configured deliberately.
Package-management features can serialize requirements and auto-install dependencies into notebook-specific environments, so teams should pin, review, and scan packages before sharing or deploying notebooks.
✓Runs on notification events and scans recent tool input for patterns that resemble secrets or sensitive data.
Produces alerts only and does not redact files, rotate credentials, or block the original tool action.
Pattern-based detection can miss real secrets or flag harmless placeholders.
Privacy notes
✓Research workspaces can contain source documents, interview notes, citations, prompt drafts, labels, embeddings, traces, screenshots, and derived conclusions.
Notebook outputs, DuckDB files, Polars exports, Label Studio projects, TruLens traces, and scanner reports may retain private content after the original source is deleted.
Local-first tools reduce unnecessary sharing, but backups, sync folders, telemetry, browser downloads, and collaboration platforms still need retention and access-control review.
✓The point of the stack is data locality — prompts, tool I/O, and memory stay on infrastructure you control instead of scattered across SaaS.
Caveat: if Claude Code is the orchestrator, its prompts still go to Anthropic's model. For full data locality, run a local model loop (Ollama + an MCP-capable client) and accept the smaller-model tradeoffs.
The memory knowledge-graph persists on local disk — secure and back it up like any other sensitive store.
✓Marimo workflows can process notebook source code, cell outputs, variable values, DataFrames, SQL queries, schemas, database rows, object-store paths, generated apps, CLI arguments, logs, and exported artifacts.
User configuration can store runtime, server, completion, and AI-provider settings, while app configuration can live inside notebook files; secrets should stay in environment variables or secret stores rather than committed notebooks.
AI-assisted editing can send prompts, notebook context, code, schemas, and referenced in-memory values to configured hosted providers, or to local model services when those are selected.
Database and remote-storage workflows can expose connection strings, credentials, table names, bucket names, object keys, query text, sample rows, and download paths to notebooks, logs, cloud services, and deployed apps.
Token login, query-parameter access tokens, Basic auth headers, reverse-proxy headers, and server logs should be handled as sensitive operational data.
✓Reads hook input fields such as tool names, file paths, commands, and text snippets supplied to the notification event.
May print matched sensitive-looking strings or surrounding context to local hook output.
Does not send findings to a remote service in the bundled script.
Prerequisites
A written research data boundary that separates public sources, licensed material, private notes, customer data, and restricted datasets.
A local or approved private workspace for notebooks, data files, labels, traces, prompts, and exports.
Redaction rules for prompts, extracted passages, tabular data, labels, traces, screenshots, and final reports.
Agreement on which outputs can leave the local workspace and which require review before sharing.
A machine with enough RAM/VRAM for local models (16GB+ for small quantized models; a GPU helps for larger ones).
Node.js 18+ and Python 3.10+ (with uv) to run the common MCP servers.
Claude Code or another MCP client as the orchestrator.
Optional: Docker or a small Kubernetes setup to host a server fleet, and a private network (e.g., Tailscale) to reach it from other machines.
Python environment and package-management plan for the selected notebook, app, script, SQL, visualization, and optional AI features.
Notebook execution model for reactive dependency graphs, deterministic cell ordering, lazy or stale runtime behavior, disabled cells, startup autorun, and side-effectful cells.
Data access plan for local files, DataFrames, SQL cells, databases, warehouses, cloud object storage, remote filesystems, environment variables, and credentials.
Deployment and access-control plan for edit servers, read-only apps, token or password protection, reverse proxies, ASGI middleware, public sharing, rate limits, and error reporting.