templates/data-app/examples/product-tracker/data-contract.md

# Product tracker evidence

Two canonical tables: one row per workspace in `workspace_roster`; one row per workspace × Monday-start week after creation in `workspace_activity`. The fixture covers May 4–August 23, 2026. A completed task is the qualifying activity; zero is an observed inactive week. Missing future weeks remain unobserved.

The separate `workspace_feedback` ledger contains one dated synthetic feedback record per stable feedback ID, linked to a workspace and its dimensions. Each record has one primary theme, a synthetic request description and recorded roadmap status. Feedback counts are not distinct workspaces or usage events. The Sankey groups complete paths from feedback source → theme → feature → roadmap status; unplanned requests omit feature deliberately. Every record still reaches a status, so source and terminal totals reconcile. The diagram uses the four complete weeks through the selected cutoff and shares tab population filters. Local flow filters also scope copied/source evidence. Selecting a node or link scopes the feedback-record drilldown to matching records, not fabricated quotes. Dispositions are as recorded at submission, not a claim about historical roadmap state or a delivery commitment.

Roster fields: stable workspace ID, name, creation cohort, plan, region, acquisition channel, member count, and elapsed days to teammate invitation, first project, task creation, first completed task and first task completed by a teammate. Null onboarding milestones mean not observed. `onboarding` identifies the synthetic original/guided setup rollout, not randomized assignment. Members are contextual only: no unique-person usage is inferred.

Activity fields: completed tasks, comments, templates, automation runs and report views. Team/Business plans are eligible for Automations/Reporting; other features are available to all. Plans and acquisition dimensions are fixed in this fixture. A production adaptation with upgrades must use dated eligibility.

Growth counts are sets of workspace IDs, not sums of weekly distinct counts: previous + first-time active + reactivated − dormant = current. The first available week has no prior observation; do not interpret its opening population as acquisition before coverage.

7-day activation uses a full elapsed seven-day eligibility window and first completion ≤7 days. Funnel steps use the same eligible population and horizon. First teammate completion is a later collaboration milestone, not the activation definition. The deterministic fixture intentionally loses the most workspaces between first completion and teammate completion. Activity in a recorded completion week cannot be zero. Cohort retention is exact calendar-week activity divided by all created workspaces, not only activated workspaces; week 0 is not forced to 100%. Week 4 needs observation through creation Monday +34 days. Channel tables expose different maturity denominators explicitly. Weighted rates recompute numerators/denominators rather than average subgroup percentages.

The header's selected week is the snapshot cutoff. History retains prior rows through that week; latest tables use that week's rows. Section-local feature/workspace controls carry the matching raw source rows to charts and tables. Source definitions travel with the artifact. No real customer, revenue, renewal or individual-person evidence is claimed.