/serve-data — Serving Surface interview

This skill runs a short, branching interview that converts a planned (or existing-but-undocumented) consumer-facing serving endpoint into a Serving Surface markdown file at docs/serving-surfaces/<surface>.md in the consumer's project. It is the terminal stage of the spine — the one where the lineage chain closes back onto the Stage 0 decision that started it. It is an interview, not a template — every surface that lands has been pressure-tested against the dual Serving kill-switch (a named upstream Model Plan and a named DGQ the surface informs), the freshness-honesty test, the access-model-honesty test (convention is earned, not role-based asserted aspirationally), the sensitivity-step-down test, and the "is this actually an ADR moment?" routing test.

This skill is self-contained: the vocabulary it leans on is inlined just below, the Serving Surface contract it writes against ships beside it at references/serving-surface.md, and the linter that enforces that contract ships at scripts/lint-serving-surface.sh. Read the contract for the artefact's frontmatter fields, enum domains, and body section order before writing — do not duplicate it into the interview; reference it.

Vocabulary this skill assumes (the minimum it needs; the full worldview is optional deeper reading, linked at the end):

• Serving Surface. The data team's version-controlled model of a single consumer-facing serving endpoint — the decision it informs, the upstream model it reads, the surface type, the consumer and named owner, the freshness contract, the access posture, the sensitivity, and the trigger that would retire it. The operational and contractual model of the surface, not a serving-tool config and not a project-management plan (it contains no LookML, no Tableau workbook XML, no reverse-ETL sync JSON, no API handler code). Stage 5's deliverable — the terminal stage, where the lineage chain closes back onto the Stage 0 decision; one file per surface at docs/serving-surfaces/<surface>.md.
• Serving kill-switch (dual). Stage 5 is the only stage with a two-headed kill-switch, because it both continues the lineage chain and closes the loop. An accepted Serving Surface must name at least one upstream Model Plan in related_model_plans (the chain half — a surface with no governed upstream recomputes business logic from raw/staging, the forked-revenue-definition failure at the serving layer) and at least one DGQ it informs in serves_dgqs (the loop-closure half — a surface that informs no decision is the dashboard-nobody-uses). Both halves must hold; this is the soul of the skill — see the next section.
• access_model posture. The Stage-5-distinctive honesty field — how access is actually enforced today (public, sso, role-based, row-level, or convention). convention (granted broadly, policed by trust with no technical enforcement) is an honest, accepted answer; recording role-based aspirationally when nothing is wired up is the template-mode bias this skill refuses, at the last checkpoint before data leaves the team's boundary.

Optional deeper reading — not required to run this skill (a per-skill install works without them): the full repo worldview in CONTEXT.md and the lifecycle reference in docs/data-engineering-101.md.

A Serving Surface is not a serving-tool config and not a project-management plan. It contains no LookML, no Tableau workbook XML, no Hightouch sync JSON, no API handler code, no feature-store definition, no dbt exposure. It is the operational and contractual model of the surface: the human-authored commitments (the decision served, the freshness contract, the access posture, the consumer, the owner, the retirement trigger) that the actual BI/serving/reverse-ETL code should reflect. The code that implements those commitments lives in the consumer's BI/serving repo and is out of scope — this skill emits no serving code. The surface is the contract the code should be reviewed against, not a substitute for it. It is the structural analogue of the Model Plan one stage upstream, deliberately human-authored and never inferred from a tool: no dbt exposures parsing, no Looker/Tableau/Mode API introspection, no reverse-ETL-platform query, no dashboard view-count or usage-analytics lookup.

Soul of the skill: the dual kill-switch

Stage 5 is the only stage with a two-headed kill-switch, because it is the only stage that both continues the lineage chain and closes the loop back onto the Stage 0 decision. Both halves must hold for an accepted surface; each catches a distinct failure, and a single kill-switch would miss one of them.