Data access
What data gets used, and why.
The product needs enough context to rank decisions well, not a blank check to collect everything it can see.
What the product needs
- Sales and stock movement
- Without movement and on-hand context, reorders and stock risk become guesswork.
- Product and catalog fields
- Titles, variants, vendors, and status help the queue point to the right record.
- Cost or margin context
- Margin-sensitive work is weaker without financial context.
- Order and supplier context
- Lead time and order behavior affect timing, not just quantity.
- Review feedback
- Approvals, skips, and corrections teach the system what the team actually found useful.
What it should not collect by default
- Everything in every system
- More data is not automatically better if it does not improve a recommendation.
- Private message content for analytics
- Questions and answers can inform product design without being sprayed into analytics.
- Credentials in public surfaces
- Connector access belongs in protected backend flows, not docs, logs, or client code.
- Unrelated customer context
- The product should not behave like a vacuum cleaner pointed at every field it can reach.
Why the boundary matters
A review-first product needs enough context to be useful, but trust disappears fast when collection feels sloppy or unexplained. The safer path is to name the signals that help the queue, explain why they matter, and keep the rest out unless there is a real reason to add it.