What we share and what stays private
We want people to understand how Pineapple makes decisions and whether the work helps customers. That requires useful explanations and honest results. It does not require exposing customer records.
Conceptual illustration. It does not show the Pineapple interface or a measured result.
The proposed public boundary
Share after review: Customer focus and business principles
Keep private: Customer identities and account activity
Share only with specific permission or after resolution: Identifiable customer stories and quotes
Share after review: Metric definitions and suitable aggregate results
Keep private: Billing records, replay links, support transcripts
Share only with specific permission or after resolution: Sensitive commercial arrangements
Share after review: Operating instructions and reusable templates
Keep private: Credentials, access links, private prompts containing customer data
Share only with specific permission or after resolution: Security incidents whose details could increase harm
Share after review: Decision summaries, failures, corrections, and measured AI costs
Keep private: Personal, family, employee, and supplier details
Share only with specific permission or after resolution: A detailed incident account after the affected people and systems are protected
The private repository includes material unrelated to Pineapple. It must never become a public website directory or be uploaded wholesale for a release.
Check what a summary could reveal
A report can reveal a customer even after their name is removed. A rare industry, date, geography, and payment amount can identify a person together. Public examples should remove those combinations or use a clearly labelled fictional example.
For this first version, the proposed default is to suppress customer-segment breakdowns with fewer than ten eligible members, including their complements when subtraction could reveal a small group. Ten is a review rule, not a guarantee of anonymity. Review overlapping periods and combinations too.
Keep the explanation checkable
Reader pages show an Updated date, with evidence dates beside time-sensitive claims. The responsible owner, source-review date and next review deadline stay in our internal review record. Draft status remains explicit until publication. A decision should connect its evidence to the action and result. A metric should name its period and definition. Where detailed evidence is private, explain the method and the limit without linking to an inaccessible customer record.
Public readers should see what a claim rests on. Private reviewers should be able to follow the exact source and revision.
Correct mistakes visibly
If we discover a material error, correct the maintained page and add a dated note describing what changed. Preserve the old record privately for audit. Remove exposed personal information promptly; keeping a public mistake visible should never repeat the exposure.
If a measurement is no longer current, show that it is stale. If a month is missing, say so. Quiet gaps make a public scorecard difficult to trust.
What we learned from other companies
Buffer makes transparency easy to find. GitLab's confidentiality guidance makes clear that public working still needs private boundaries. We are adapting those ideas to a small company using AI, rather than copying every kind of information those companies disclose.
Use the publication review template before moving a private explanation into public view.
Updated 30 October 2026.
