i instaboard

Onboarding fordata teams, builton DataHub.

instaboard saves how your team does a task as a step-by-step guide, then keeps checking that guide against your DataHub catalog. New hires ask it questions in chat and get answers from the live catalog, real table names included.

42%

of institutional knowledge is unique to one person. When they leave, no copy exists.

YouGov for Panopto, n=1,001, 2018
5.3 hrs

lost per knowledge worker every week, waiting for colleagues’ knowledge or recreating it.

same survey
41%

of data teams name ambiguous data ownership as an obstacle to their work.

dbt Labs, State of Analytics Engineering, n=363, 2026

Guides name real columns, tables and owners.

Every guide points at real things in the catalog: the columns its SQL sums, the tables it reconciles against, the owner it says to ping. All of that keeps changing, and a guide has no way to notice on its own. So instaboard re-checks every guide against DataHub and pins each mismatch to the step it breaks.

The Handoffs page after a validation run: the guide is marked Out of date with four findings, including the missing column and the changed owner

This is that check running in the app. A month after the guide was recorded, validation comes back Out of date with four findings: the revenue column was renamed, the rollup table was deprecated, a freshness assertion started failing, and the person the guide says to ping no longer owns the table.

Each finding sits on the step that uses it, with the drift spelled out and a correction proposed. The same run writes back to DataHub, where the dataset gets a warning tag and an incident goes to its current owner.

Break it yourself below and watch the verdict change.

It works off the catalog you already run.

Nothing here is pre-written. Every question sends the agent to DataHub while you wait, so the answer reflects whatever the catalog holds at that moment. Below is a real run against the demo catalog: four tool calls, then an answer that cites the URN it found.

agent transcriptnorthbeam · demo catalog
askedIs it safe to build a report on the raw events table?
  1. search query: "events"2 datasets across postgres + snowflake
  2. get_entities postgres,northbeam_app.public.eventsowned by James Okafor and Sarah Chen · domain Growth
  3. get_dataset_health same urndeprecated 2025-11-01 → analytics.marts.events_sessionized
  4. get_usage_stats window: 30d74 queries, trending down

That table was deprecated on 2025-11-01 and is kept around for pipeline debugging. Build on events_sessionized instead, the sessionized mart James Okafor owns. Volume on the raw firehose has been sliding all quarter.urn:li:dataset:(urn:li:dataPlatform:snowflake,analytics.marts.events_sessionized,PROD)

What you can ask it.

A sample of week-one questions and what comes back. The middle column is the DataHub call the agent chose, and the right column is what a new hire actually gets, with names, owners and definitions pulled from the catalog. Every row works in the demo the moment the app starts.

AskCallsComes back
What tables do we use for revenue?search → get_entitiesfct_revenue and mrr_monthly, with owners and URNs
How do we calculate MRR?get_entitiesthe glossary definition, plus related terms like ARR
What breaks if I change users.email?get_lineagethe downstream marts affected, and who to warn
Show me SQL for churn analysisget_dataset_queriesthe saved query someone already wrote against fct_churn
Which Payments tables should I learn first?get_usage_statsan order built from what people query
Is this table safe to build a report on?get_dataset_healthdeprecation, open incidents, and failing assertions
Why is there no description here?save_documenta drafted description, filed for an owner to approve

What you actually do with it.

Three surfaces, and the same agent behind all of them. Chat answers questions, the side panel explains whatever DataHub page you are on, and Handoffs holds the recorded guides. Everything below runs on a laptop with npm run dev and a DataHub you can reach.

The sidebar adds three more pages. Learning Path builds a week-one plan for a role, Lineage explains what feeds a dataset and what it breaks, and Progress tracks the plan. From a terminal, npm run draft writes guides straight from the catalog and npm run validate checks every stored guide.

web app · Chat

Ask the catalog something

  1. Run npm run dev and open localhost:3000. It lands on Chat.
  2. Paste an LLM key into Settings in the left sidebar, unless you already put one in .env.local.
  3. Type a question, or click one of the five starters sitting on the empty state.
  4. The tool trace above the answer shows each DataHub call it made.
Chrome side panel

Record what you know

  1. Load extension/ unpacked at chrome://extensions, then pin the icon and click it.
  2. Open the DataHub page you would normally start from and hit ● Record in the panel header.
  3. Do the task. Each page you land on becomes a step, and Add note attaches the why to the step you are on.
  4. Hit ■ Stop, name the task, and click Generate guide & save to DataHub.
web app · Handoffs

Find out when it breaks

  1. Open Handoffs and pick a guide. Every step shows the action, the why, the real SQL and the gotchas.
  2. Click Validate against DataHub. It re-reads every entity the guide depends on and reports what moved.
  3. A broken guide gets a tag, a failing assertion and an incident on the datasets involved, over in DataHub.
  4. Run npm run propose to get the correction as a diff.

A Chrome extension that rides along inside DataHub.

The Chrome extension reads the URN of whatever DataHub page you have open and explains it right there, so you stay on the page. It runs as a thin client on the same agent, which keeps API keys out of the browser. The chips under the answer cover the common asks, including recording a handoff without leaving the tab.

Installing takes a minute: download the zip, unzip it, open chrome://extensions, turn on Developer mode, and hit Load unpacked. It also ships in the repo’s extension/ folder.

Guides get recorded by doing the task.

Writing documentation is a separate job nobody has time for, so the recording rides along with the work itself. Press record in the side panel and do the task the way you always do it, typing the why next to each step as you go. The agent fills in the rest from the catalog, and the finished guide is saved back into DataHub through save_document, linked to the datasets it touches.

youRecord

Open the side panel, press record, and do the task the way you always do it. Every DataHub page you land on gets captured as a step.

youAnnotate

Type the why next to each step, such as the reason one column gets filtered out before any of the numbers make sense.

instaboardEnrich

The agent looks up every step in the catalog and attaches owners, saved SQL, lineage and tags.

new hireReplay

Whoever picks the task up replays it in the same panel, and each step lights up when their browser lands on the page it describes.

Break the catalog and watch validation catch it.

Pick a change below and the validator re-checks the guide against the catalog, live on this page. It catches missing columns, deprecated tables, failing assertions and changed owners. The check is a plain diff with no LLM involved, so any verdict can be confirmed in the DataHub UI. Against a real catalog the result is written back as a failing assertion, a warning tag and an incident for the current owner.

Break the catalog. The guide was recorded 2026-07-01 against a catalog where all of this was true.
guide validationmonthly MRR report · recorded 2026-07-01 by Priya Patel
detection is a schema and health diff against what the recording captured — no LLM in itdiffAgainstCatalog

This runs against a built-in fixture of the Northbeam catalog, so nothing is written back — incidents, assertions and tags need a real DataHub. The verdict above comes from the same function the live sweep calls. Receipts from real runs, including a stale tag being applied and then retracted when the guide is repaired, are committed at examples/live/.

Does the catalog help? We measured it.

Twenty questions a new hire asks in week one, answered by the same agent under three setups. Scoring is deterministic, and no LLM judges anything. The middle arm gets what a bare warehouse connection returns, which is how you find out the metadata is doing the work. When a question names a table that doesn’t exist, the grounded agent says so and the control invents a schema. Read the scorecard or run it yourself: DEMO_MODE=true npm run eval.

with DataHubsame agent, MCP tools on
18.0/20
warehouse schema onlysame agent, information_schema and nothing else
8.7/20
withoutsame agent, no catalog
3.0/20

Means over three passes against a live catalog; the spreads are in the scorecard, and the ranges of the arms never touch. On DataHub’s own showcase datapack, 1,065 entities this repo did not author, the grounded arm scored 20/20.

Running in about a minute.

Demo mode answers every catalog call from a built-in fixture of Northbeam, a subscription-commerce catalog with 14 datasets, four owners and real lineage. It needs nothing beyond an LLM key. Pointing it at a live catalog takes two more commands, npm run datahub:up and npm run seed, covered in the README.

$npm install
$echo "DEMO_MODE=true" > .env.local
$npm run dev
# then paste an LLM key in Settings