Share your expertise.
Protect what is private.
We value your expertise and your perspective. This policy helps you develop a public voice through writing, speaking, podcasts, demos, video, and company launches. Participation is optional. Your experience and opinions are welcome; you choose which ideas to develop and where to share them.
This is the full example policy for the fictional Basis company in the Continuum walkthrough. A real workspace would link to its own company’s policy.
1. Support factual claims
Make a factual claim only when you can support it with accurate, current information cleared for public use. Link to the original source when possible. Check that the source supports the precise claim you are making, including its limitations and date.
- Distinguish your experience, your opinion, and a verified fact. “I found this useful” is different from “this is the most effective approach.”
- Avoid unsupported claims about performance, safety, security, competitors, market leadership, or results.
- Do not invent customer outcomes, statistics, quotations, or endorsements.
- If you do not know, say so. Offer to check an approved source rather than guessing.
Example: “Here is what our public test measured, and here are its limits” is useful. “We are better than every competitor” requires evidence you may not have.
2. Keep confidential information private
Do not disclose unreleased product plans, internal metrics, private customer work, contractual terms, security-sensitive details, credentials, personal information, or private conversations. Information you can access at work is not automatically information you can publish.
- Use published material or passages specifically approved for public reuse.
- Removing a name does not make a confidential story safe to share. Details may still identify a person, customer, or project.
- Keep restricted recordings and transcripts separate from approved public excerpts.
- Do not put confidential work into external writing or recording tools without the company’s permission.
Example: A published case study can be discussed within its stated scope. A private customer meeting cannot be turned into a public anecdote without permission.
3. Identify your affiliation and your perspective
When discussing Basis or work you do here, make your affiliation clear. You can describe your own expertise, experience, and opinions. Do not present a personal preference as a company decision, a product commitment, or a confirmed position.
Example: “I work on the infrastructure team at Basis. My view is…” makes the context clear. If an interviewer asks about an unannounced company decision, explain what you can discuss publicly and say that a decision has not been announced.
4. Respect people’s privacy
Ask before publishing a colleague’s, customer’s, or partner’s name, image, story, or quote from a private setting. Permission should cover the wording, format, destination, and intended use. A private conversation or meeting invitation is not permission to publish.
Do not share private contact details, employment information, personal circumstances, or screenshots that reveal someone else’s data. Give people an opportunity to review how they are represented.
5. Preserve attribution, context, and rights
Credit the people whose ideas or words you use. Verify quotations against the original. Do not edit a passage so that it changes the speaker’s meaning. A paraphrase should still retain its source.
Permission to use text does not automatically include video, audio, images, or a new publishing channel. Confirm recording and reuse rights separately, including the permissions of identifiable participants.
6. Follow the agreed release timing
Before sharing a launch, check which facts are public and when they become public. Use the agreed release time and honor any embargo. Internal “ready” status does not itself make information public.
Your own contribution should explain what you know or helped build. Use approved product documentation for factual claims. If a launch date or draft changes, review the updated text, account, and publishing time before posting.
7. Keep control of your work
Your Writing Room draft starts private. Sharing it for feedback is your choice. Jules Rivera, the example communications editor, can help with the argument, public sources, format, and preparation. That feedback does not replace your own judgment or approval.
- Review the exact version that will represent you.
- Approve the specific account and time before anything is scheduled.
- Reopen review when an approved draft, source, or publishing plan changes.
- You can withdraw a draft or your writing-profile consent. An already published item may require a separate correction or removal request.
Company accounts have their own review process. Personal participation is optional, including reactions to or sharing of company posts.
8. Prepare for the format you choose
Readiness is specific to a subject and an activity. Speaking on a podcast about digital assets calls for different preparation from giving a live product demo. Choose public examples, practice explaining them clearly, and plan how you will handle questions you cannot answer.
- Writing and blogs: check sources, quotations, claims, and the clarity of your own argument.
- Podcasts and talks: rehearse your main point and a response to sensitive or unfamiliar questions.
- Demos and livestreams: use a prepared environment; hide credentials, customer data, private screens, and unreleased work.
- Launches: verify public facts, your contribution, and the release timing.
9. Ask for help and correct mistakes
If you are unsure whether information can be shared, pause and ask the communications team with the exact passage or question. Bring the context and intended destination so the answer can be specific.
If you publish something inaccurate, let the team know, check the original sources, and correct it clearly. If confidential or personal information was disclosed, contact the team promptly so it can help limit further exposure.