Build shared context with your team

Useful context usually splits between Git and hallway conversations. Publish structured docs to the workspace (relationships, ownership, naming) and update them as the team's picture of the data sharpens.

How it works

Step 1: Publish the shared map

Generate the workspace data model file, then publish it so the whole team shares one map of tables and joins.

Step 2: Add workspace-specific context for the team

We keep internal notes on who owns metrics and naming rules. Publish those next to the shared data model so teammates see both.

Step 3: Confirm both documents are live

List what’s published, then show the data model and the team notes so I can confirm both are there.

Step 4: Create, update, or remove a shared document

Push creates or overwrites a stem from ./<STEM>.md. Pull → edit → push updates in place. Delete drops that stem from the workspace when a doc is retired (use the Python client or DELETE /v1/context/{name}; there isn’t a context delete subcommand in the CLI yet).

Publish a RUNBOOK context for the team, revise it after our naming workshop, then delete RUNBOOK when we fold it into DATAMODEL.

Who uses this

• Platform leads owning a central model while individual workspaces layer local rules.
• Product analytics documenting metric ownership at workspace scope.
• Teams piping both schema detail and policy context into agents or codegen.