Sample data must not mix with real records

What it is

Sample rows and the user’s own records must have different data identities. Search, counts, export, collaboration, and billing must not include the fakes. Confusion is not “they look a bit alike.” It is the system treating a sample as a real object on some channel—unread counts that include samples, reports that include demo orders, a coworker opening a share and seeing “Sample Customer.” Labels and one-click clear reduce misrecognition, but if the backend still writes samples into the same table and index, people can recognize and still compute wrong.

Why it happens

Most product features operate on “records in the container” and do not ask origin. Once samples share a primary-key space with real rows, filters, badges, and sync ingest fakes automatically. People judge workload from those aggregates: a badge of 3 is three letters to answer. A second layer of mix happens at the boundary: export carries samples out, labels drop in a spreadsheet or a foreign system, and fake rows become real downstream input. Collaboration is worse: scenery for the creator is content for the person who received the share. Separation therefore cannot be color. It has to be identity: samples stay out of true-set queries, outbound sends, and metering. After the display job ends, that identity should still be destroyable as a batch, not “become” a user record—that is a different product (a starter).

Where it stops holding

A local-only demo mode is all fake and cannot mix, but those samples must not upload when the account joins the real network. “Save as mine” from a sample is an explicit conversion; the old identity should vanish, leaving no twin that is both sample and real. Analytics environments that use anonymized production rows as samples are a masked sample at environment level, and must not leak into the production workspace.

Applying it

• Give samples their own type or namespace; default query, unread, export, share, and billing exclude them. If the working view must show them, use a separate demo layer, not a mixed list.
• Keep samples off outbound channels (mail, public links, APIs) unless the channel itself is demo mode and marked end to end.
• After the first real record is written, samples must leave that container’s default counts and search.
• Verify on an account that still has samples: search, read the badge, export, open a share link. Any unmarked fake on those four paths is a failed split. Clear samples; counts should match real records.

Related

• Within the group: H2.06.1 Sample data shows the filled shape of the product · H2.06.2 Samples must be labeled and clearable in one action
• Adjacent: H2.08 Sample Data and Starter Content · H5.05 Badges and unread counts · H8.04 Copy, share, and export
• Search terms: sample data leakage · demo vs production records · namespace separation