Data Platform Documentation — Standard Tabs for Google Sheets
This file is the single source of truth for the standard tab names and column headers used when updating or creating a client’s Data Platform Documentation Google Sheet. The data-platform-doc skill reads this file in every mode (kickoff, update, backfill, audit) to resolve tab aliases, compare the workbook to the standard set, fill cells, and create any missing standard tabs 1–11 per universal rule U3 (see the unified skill). Audit mode reports gaps and may not write, depending on skill configuration.
Production Mart Catalog (tab 11) is required for engagements that include a curated mart layer: the sheet must include this tab (or a listed alias). Agents create it if missing, then populate from live warehouse inventory + dbt + markdown/schema descriptions per the section below.
References:
- data-platform-documentation-template-guide.md — sheet purposes and what to fill in
- Brainforge x LMNT - Data Platform Documentation — example Google Sheet structure and Data Sources columns
Standard tab names (order)
Use this order when creating missing tabs. Tab names are exact (case-sensitive where the sheet API preserves it).
- How to Use This File
- Business Context
- Teams
- Data Stakeholders
- Naming Taxonomy Conventions
- Data Tools & Costs
- Data Sources
- Core Metrics & Lineage
- Dashboards
- Reverse ETL / Outbound Pipelines
- Production Mart Catalog — curated inventory of production marts tables (warehouse + dbt folder alignment)
Excel (.xlsx) note: Microsoft Excel does not allow / in sheet tab names. A downloaded Excel file may show Reverse ETL - Outbound Pipelines (hyphen) instead of the slash. Treat that name as the same standard tab; the data-platform-doc skill and tools/data-platform-doc-validate accept both.
Aliases (avoid duplicate-function tabs)
When checking if a standard tab already exists, treat these sheet tab names as satisfying the corresponding standard tab. Do not create a second tab if the sheet already has a tab with one of these names.
| Standard tab | Aliases (sheet may use instead) |
|---|---|
| How to Use This File | ReadMe, Read Me, How to Use |
| Data Stakeholders | Stakholders (typo), Stakeholders |
| Core Metrics & Lineage | Core Metrics |
| Reverse ETL / Outbound Pipelines | Reverse ETL - Outbound Pipelines, Reverse ETL |
| Production Mart Catalog | Mart Catalog, PROD_MARTS Catalog, Marts Catalog |
Data Sources vs reference tabs: The standard tab Data Sources is the inbound pipeline inventory (source systems, owner, pipeline tool, method, frequency, DW, destination). A sheet may also have a separate reference tab (e.g. “External Data Sources”) that lists platform → cookies/params for implementation. Treat “External Data Sources” as not satisfying “Data Sources” — the skill should still ensure a Data Sources tab exists for pipeline rows. Keep client-specific reference tabs as-is; do not rename or remove them.
Optional / client-specific tabs
Do not create these by default. Only fill or reference them if the sheet already has them or the user requests.
- Subject areas (or similarly named) — glance tab: subject area ↔ warehouse schema ↔ short “what lives here” / build state. Optional companion to Production Mart Catalog (standard tab #11); not a substitute for tabs 1–10 in this workbook.
- Snowflake Objects
- Exec Dashboard scratchpad
- SOURCE_MEDIUM - Metrics Airtable
- Any other client-named tab (e.g. “External Data Sources (reference)“)
Production Mart Catalog — row 1 headers (standard tab #11)
When creating or validating this tab, use row 1 exactly as below (18 columns). Clients may add trailing rows of help text (e.g. how to read colors / Apps Script) below table data; treat those as non-data rows, not errors.
| Column A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Full name | Schema | Table | Table type | Grain | Primary business topic | Sources / systems | Key joins / upstream | Description | dbt path hint | Build state | Narrative vs code | Time completeness | Sensitivity | Primary consumer | Status buckets | Cross-source | Doc freshness |
Column headers per tab (for creating new tabs)
When the skill creates a new sheet (tab), it must write row 1 with these headers so the tab is usable. Use the exact strings below; adjust only for client-specific placeholders where noted.
How to Use This File
No single header row; content is free-form (purpose, last updated, maintained by, table of sheet names). When creating this tab, write at minimum: A1 = “Brainforge Client Data Platform Documentation”, and a row for “Last Updated” and “Maintained by”. Optionally add a small table: Sheet Name | Purpose | When to Fill | Owner.
Business Context
| Column A | Column B | Column C |
|---|---|---|
| Field | Description | Guidance |
Teams
| Column A | Column B | Column C |
|---|---|---|
| Team Name | Description | Parent Team |
Data Stakeholders
| Column A | Column B | Column C | Column D | Column E |
|---|---|---|---|---|
| Name | Role | Team | Brainforge Team |
Naming Taxonomy Conventions
| Column A | Column B | Column C | Column D |
|---|---|---|---|
| Category | Rule/Format | Example | Notes |
Data Tools & Costs
| Column A | Column B | Column C | Column D | Column E | Column F | Column G | Column H | Column I | Column J | Column K | Column L |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Tool | Type | Contract Start | Contract End | Notice Due By | Relationship Owner | Monthly Cost | Annual Cost | Pricing Method | Recommendation | Notes |
Data Sources (inbound pipeline inventory)
Use these headers for the Data Sources tab (pipeline/source rows). For client sheets that use extended columns (e.g. LMNT), the skill may add or retain client-specific columns (e.g. “Connector Built”, “BF Granted UI Access”). Minimum standard set:
| Column A | Column B | Column C | Column D | Column E | Column F | Column G | Column H | Column I | Column J |
|---|---|---|---|---|---|---|---|---|---|
| Name | Domain | Priority | Description | Owner | Pipeline Tool | Pipeline Method | Freshness | Data Warehouse | Destination |
Extended (LMNT-style) optional columns can be inserted; common set from reference sheet: Connector Built, BF Granted UI Access, BF Team Discovery Complete, BF Granted API Access, Pipeline Active, Expected ingestion completion date, System Status — add after Name/Domain if the client sheet already uses them.
Core Metrics & Lineage
| Column A | Column B | Column C | Column D | Column E | Column F | Column G | Column H | Column I | Column J | Column K | Column L | Column M | Column N | Column O | Column P | Column Q | Column R | Column S | Column T |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Business Domain | Metric ID | Metric Name | Channel | Priority | Business Definition | Metric Type | Grain | Product Scope | Aggregation | Is Derivative? | Formula / Logic | Source Systems | Marts Model | Data Owner | Primary Stakeholder | Refresh Frequency | Notes / Caveats | Brainforge Commentary | Client Commentary |
Dashboards
| Column A | Column B | Column C | Column D | Column E | Column F | Column G | Column H |
|---|---|---|---|---|---|---|---|
| System | Dashboard Name | Owner | Priority | Data Category | Has Last Updated At | Refreshing Frequency | Link |
Reverse ETL / Outbound Pipelines
| Column A | Column B | Column C | Column D | Column E | Column F | Column G | Column H |
|---|---|---|---|---|---|---|---|
| Pipeline Name | Source (e.g. mart/table) | Destination System | Destination Object | Tool | Frequency | Owner | Notes |
Production Mart Catalog
Purpose: One row per production mart object the client exposes for analytics (typically Snowflake DATABASE.SCHEMA.TABLE under a single marts database such as PROD_MARTS). Rows must align with the client’s dbt layout: models/marts/<subject_area>/ ↔ Snowflake schema name (per client custom_schema / naming conventions). This tab is not optional—it belongs on every Data Platform Documentation sheet alongside tabs 1–10.
Where agents gather truth (try in order):
- Warehouse (authoritative inventory): Query the client’s production marts database
INFORMATION_SCHEMA.TABLES(or BigQueryINFORMATION_SCHEMA.TABLES, or RedshiftSVV_TABLE_INFO/ equivalent). If the engagement’s warehouse is unclear (Snowflake vs BigQuery vs Redshift), infer from Data Sources, dbtprofiles.yml/target, orsources.ymldatabase types—ask the user once if still ambiguous. - dbt repo (layout + docs): Resolve
dbt_project/per data-platform-doc-common.md (READMEprimary_dbt_project_path, vault, workspace glob). Usemodels/marts/**/*.sqlfor path hints and folder↔schema mapping. - Narrative descriptions: Prefer
dbt_project/docs/*MART*CATALOG*.mdorPROD_MARTS_CATALOG.md-style files when present; elseschema.ymldescriptionon mart models. - Subject-area sheet (optional companion): Some clients keep a Subject areas tab with one row per Snowflake schema (business lens, build state at schema level). That tab is not a substitute for Production Mart Catalog (table-level).
How to populate (automation or manual): Follow knowledge/standards/02-writing/data-platform-doc-common.md → Mart catalog automation — behavior contract (implementation-agnostic). In short: (1) list production marts from warehouse metadata, (2) align to models/marts/<folder>/, (3) merge markdown or schema.yml descriptions, (4) infer documented driver columns, (5) emit 18-column TSV (or chunked JSON for Sheets). Agents may author a small script under dbt_project/scripts/ in the client repo that implements that contract; no dependency on any other client’s repository. A conventional script name is build_production_mart_catalog_for_sheet.py (optional); warehouse auth (e.g. Snowflake CLI snow sql -c <profile>) is typical when querying INFORMATION_SCHEMA.
Writing to Sheets: Use gws sheets spreadsheets values batchUpdate (preferred) or Google Workspace MCP modify_sheet_values. For very large grids or MCP limits, write in row chunks (e.g. 8–15 rows per call) or narrow ranges (e.g. only column Q Cross-source) per data-platform-doc-common.md. Do not use paste fallback when writes are blocked.
Row 1 headers (exact strings, columns A–R):
| Col | Header | What to fill |
|---|---|---|
| A | Full name | DATABASE.SCHEMA.TABLE (production object id). |
| B | Schema | Snowflake schema / subject area (e.g. RETAIL, MARKETING). |
| C | Table | Table or view name. |
| D | Table type | Dim / Fact / Snapshot / Summary / Mart rollup (inferred or from warehouse). |
| E | Grain | One row per … (from description or model docs). |
| F | Primary business topic | Short tag (e.g. retail, marketing). |
| G | Sources / systems | Upstream systems for that subject area (from SCHEMA_SOURCES-style mapping or discovery). |
| H | Key joins / upstream | Notable joins, rollups, or cross-network notes. |
| I | Description | Mart purpose; prefer markdown catalog or schema.yml. |
| J | dbt path hint | e.g. models/marts/<folder>/<model>.sql. |
| K | Build state | e.g. Prod / In development (per deployment reality). |
| L | Narrative vs code | e.g. OK / May lag merges. |
| M | Time completeness | e.g. N/A / Complete periods only. |
| N | Sensitivity | e.g. Internal / PII. |
| O | Primary consumer | Analytics, Finance, etc., when known. |
| P | Status buckets | Wholesale-style segments when applicable; else blank. |
| Q | Cross-source | Yes when the mart layer combines multiple upstream systems (e.g. multi-network supply chain, multi-platform ads); No otherwise—use repo logic or explicit schema rules, not guesswork. |
| R | Doc freshness | Last reviewed / TBD. |
Trailing legend row (optional): Some implementations add a final row (e.g. row 62) with a short “how to read colors / dropdowns” note in column A; leave other columns empty. Optional Apps Script (e.g. production_mart_catalog_sheet_setup.gs in the client repo) can attach data validation on columns K–R using a _lists tab—document in client README if used.
Warehouse-specific notes:
- Snowflake: Default pattern in reference script:
prod_marts.information_schema.tables. - BigQuery: Replace with project/dataset metadata; keep the same column semantics where possible; Full name as
project.dataset.table(backtick-qualified in Sheets if needed). - Redshift: Use catalog tables exposing schema + table + type; same column semantics.
Summary for the skill
- Read this file at the start of the “scan tabs” step.
- List current sheet tabs (from Google Sheets API / MCP).
- Resolve: For each standard tab, if the sheet has a tab with that name or an alias, treat it as present.
- Gap list: Missing = standard tabs with no matching tab (by name or alias). “External Data Sources” does not satisfy “Data Sources”; ensure a Data Sources tab exists for pipeline inventory.
- Create each missing standard tab (1–11) per U3:
create_sheet, then row 1 (headers) from the tables above viamodify_sheet_values; optionally add one placeholder data row (e.g. TBD) per new tab. Kickoff does this after template copy; update / backfill repair missing standard tabs the same way when the skill is in a write mode. - Fill all standard tabs (existing + newly created) from vault, Linear, and discovery; highlight no/TBD in red where supported.
- Production Mart Catalog: After the tab exists (step 5 if created), refresh all data rows (and optional legend) using the client’s mart catalog script or equivalent warehouse + dbt merge—see Production Mart Catalog section above. On kickoff, if the Drive template copy lacks this tab, create it before handoff.