Privacy at Mosa
On this page
Document Information
| Field | Detail |
|---|---|
| Document | Privacy at Mosa |
| Document Version | v1.0 |
| Reviewed | 27 September 2026 |
| Status | Approved |
| Parent Company | Sidekick Platforms |
| Platform Brand | Community.OS |
| Consumer Product | Mosa |
| Brand Promise | Making Participation Visible |
| Core Message | When participation becomes visible, communities become stronger. |
| Supporting Line | Every little bit helps. |
| Guide | Pitch |
Participation works better when trust comes with it
Mosa helps people participate in the communities that matter to them.
That might mean volunteering at your child's school, helping at a sporting club, joining a committee, coaching a team, attending an event or contributing somewhere completely different.
Over time, the same person may participate across many different organisations and communities.
Mosa is designed so you shouldn't need a new identity every time you do.
But connecting participation should never mean making your life visible to everyone.
Our approach is simple:
One person. Many communities. Your information stays connected to you, while access stays connected to the right context.
This page explains what that means in practice.
1. Who is Mosa?
Mosa is the experience you use to participate in your communities.
It is built on Community.OS, the platform that helps communities manage participation, relationships, communications and other community activities.
Community.OS and Mosa are operated by:
OSA Management Pty Ltd ABN 62 677 945 863 Trading as Sidekick Platforms
You'll normally see Mosa when you're participating, and Sidekick Platforms or Community.OS where we're talking about the company or platform behind it.
Our formal Privacy Policy explains our legal privacy obligations and information-handling practices in more detail.
This page explains the same philosophy in everyday language.
2. One person, one Mosa identity
Mosa is built around a simple idea:
You should be one person, wherever you participate.
Your school shouldn't need to create one version of you.
Your football club shouldn't create another.
Your community group shouldn't create a third.
Instead, Mosa maintains one persistent identity for you and connects that identity to the different relationships you have.
That means your participation can build over time without creating disconnected accounts and duplicate profiles everywhere you go.
Your organisation doesn't own your identity
An organisation can have a relationship with you through Mosa.
It may need information about you to manage that relationship.
But that does not mean it owns your Mosa identity.
If you leave an organisation, your Mosa identity does not leave with it.
And joining another organisation does not automatically give that organisation access to everything you've done elsewhere.
One Mosa identity does not mean one universally visible profile.
3. Who can see what?
Different people need different information for different reasons.
A volunteer coordinator might need to know whether you hold a required qualification.
A team manager might need to know whether you're available for Saturday's game.
An authorised first-aid or safeguarding role may need access to important Health & Safety Information.
Another participant may only need to see your name and profile image.
Mosa is designed around contextual access.
That means access should depend on things such as:
- who the person is;
- their relationship with you;
- the organisation involved;
- their role and authority;
- what information they need;
- why they need it;
- the activity or context;
- and whether that access is still appropriate.
Being an organisation administrator does not automatically mean being able to see everything about everyone.
Being connected to you in one community does not automatically reveal your relationships with another.
And Mosa itself may hold information that no individual organisation is entitled to see.
Connected information does not mean universally visible information.
4. Families, children and young people
Families don't always fit neatly into a single account.
Mosa doesn't expect them to.
A young person can exist as their own Person in Mosa even before they have their own login, email address, phone or device.
A parent, guardian or other authorised representative may act for them where appropriate.
For example, a parent might:
- register their child for an activity;
- respond to availability;
- provide required information;
- manage permissions;
- receive relevant communications;
- or agree to appropriate conditions on their child's behalf.
But the young person's identity remains their identity.
They aren't simply a sub-profile belonging to their parent.
Families can be complicated
A child may be part of more than one Household.
Different parents or guardians may have different relationships and authority.
An emergency contact is not automatically a guardian.
Being in the same Household does not automatically give one person authority over another.
Mosa is designed to represent those relationships rather than assuming every family works the same way.
Growing into your own Mosa experience
As a young person becomes ready to use Mosa directly, their access can evolve.
They shouldn't need to create a new identity and lose their history simply because they now have their own login.
Their existing participation, relationships and Community Story can remain connected to them while their own access and control develop appropriately.
Growing up shouldn't mean starting your community identity again.
5. The information Mosa holds
The information Mosa needs depends on how you use it.
It may include things such as:
- identity information;
- contact information;
- Household and family relationships;
- organisation memberships and relationships;
- participation and attendance;
- qualifications and eligibility;
- Health & Safety Information;
- Accessibility & Support Information;
- emergency contacts;
- communications;
- payments and payment status;
- Community Story;
- preferences;
- permissions and consents;
- and security information needed to protect your Account.
Not everyone can see every category.
Some information requires much stronger protection than others.
We should have a reason for asking
Mosa should not collect information simply because it might be useful one day.
When information is required, there should be a legitimate purpose for it.
And where an organisation only needs an answer, it shouldn't necessarily receive the underlying evidence.
For example, an organisation may need to know:
Required qualification satisfied
rather than receiving every document or piece of evidence used to establish that result.
We call this idea:
Trusted outcome over unnecessary evidence.
6. Sharing information between organisations
One of the benefits of Mosa is that you don't have to rebuild everything about yourself every time you participate somewhere new.
But that does not mean every organisation gets access to a shared master file about you.
Suppose you've already verified a qualification through Mosa.
Another organisation may legitimately need to know whether you satisfy the same requirement.
Where appropriate, Mosa may be able to provide the trusted outcome without unnecessarily giving the second organisation all of the information behind it.
The same principle applies more broadly:
Reuse trust, not unnecessary sensitive data.
Information should only move between contexts where there is a legitimate reason, appropriate authority and the required permission or other basis for doing so.
7. Communications
Community participation involves communication.
Mosa is being designed so communities can increasingly communicate where their participation already happens, rather than scattering conversations across email chains, text messages, social media groups and unrelated messaging apps.
Privacy and safeguarding remain part of that design.
Organisation communications
An organisation may need to communicate with you because of a legitimate relationship.
For example:
- an event update;
- roster change;
- registration reminder;
- important operational notice;
- or information relevant to your membership.
Your notification preferences can affect how Mosa alerts you.
They don't necessarily remove the organisation's legitimate ability to communicate with you inside the appropriate context.
Participant conversations
Personal and group conversations are different from operational organisation communications.
Mosa's communication architecture is designed to distinguish them.
As communication features grow, controls may include:
- muting;
- leaving conversations;
- blocking;
- reporting;
- participant controls;
- age and relationship-aware safeguards;
- and stronger protections for communications involving young people.
Children and communication
The fact that somebody is a coach, volunteer or administrator does not automatically mean they should be able to privately contact any child.
Mosa's communication model is intended to consider the relationship, age, authority, context and safeguarding requirements before communication is permitted.
8. Your Community Story
Participation matters.
Mosa is designed to help make the contribution people make to their communities visible over time.
Your Community Story may include things such as:
- organisations you've participated with;
- activities and events;
- volunteering;
- roles;
- participation hours or credits;
- qualifications;
- achievements;
- recognition;
- and other parts of your community contribution.
But building a Community Story does not mean making all of it public.
Different parts may be:
- private;
- visible to you;
- visible in a relevant organisation;
- shareable by you;
- or appropriate for broader visibility.
Mosa should allow the value of participation to travel with the Person without turning their community history into a universally searchable record.
9. Partners, integrations and other systems
Community.OS won't exist in isolation.
Organisations already use systems for things such as:
- payments;
- membership;
- sport;
- learning;
- communications;
- fundraising;
- commerce;
- identity;
- and administration.
Mosa may connect with other services where doing so genuinely improves participation or community operations.
Those connections should not create invisible, unlimited access to Mosa.
An integration should have an identifiable purpose and appropriate authority.
Where possible, access should be limited to the information and capabilities genuinely required.
Connecting a system should not mean connecting everything.
There is also a difference between a service provider Mosa uses to operate the platform and an external system an organisation chooses to connect.
Our formal Privacy Policy and future Trust Centre will provide more detail about relevant providers and information handling.
10. Commercial partnerships
Mosa is a commercial platform, and partnerships, commerce and other commercial opportunities may form part of the Mosa experience over time.
But Mosa is not being designed as an advertising platform.
We don't want community participation to become an experience cluttered with irrelevant advertising or built around capturing people's attention so it can be sold to advertisers.
Instead, commercial partnerships should have a clear purpose:
Creating genuine value for participants, Organisations and their communities.
That might include:
- member benefits and discounts;
- community offers;
- club or Organisation benefits;
- partner promotions;
- commerce;
- sponsored community programs;
- surveys or research;
- or other relevant opportunities.
The important distinction is that a commercial relationship should not automatically give a partner access to people's personal information or Community Story.
For example, a partner may want to provide an offer to people who meet particular criteria.
Where appropriate, Mosa can determine who is eligible and present that opportunity without first providing the partner with a list of those people.
Partner defines the relevant opportunity → Mosa determines who may be eligible → Mosa presents the opportunity → You choose whether to engage
If you choose to engage with an external partner, some information may then need to be shared to provide the product, service, benefit or experience you've chosen.
Where that happens, the relevant information sharing should be made clear.
Mosa may also use appropriately aggregated or de-identified information to understand participation, improve the platform, support communities or develop useful community and commercial insights, provided that information is handled in accordance with our privacy framework.
Our principles are:
Commercial activity should create value for communities, not turn community participation into advertising inventory.
and:
Commercial opportunity should not create unnecessary access to personal information or somebody's Community Story.
11. Your choices and controls
Privacy doesn't mean every use of information can be optional.
Sometimes information is genuinely required to provide a service, manage a relationship, satisfy a participation requirement, protect somebody's safety or meet a legal obligation.
Where genuine choices exist, Mosa should make them meaningful.
Depending on the feature, you may be able to control things such as:
- profile visibility;
- communication preferences;
- sharing;
- optional information;
- marketing;
- commercial engagement;
- particular permissions;
- and consent-based uses of information.
We distinguish between:
Notice
We need to tell you something.
Acknowledgement
It matters that we know you've received or understood something.
Agreement
Conditions apply to a relationship or activity.
Consent
You have a genuine choice about whether something happens.
We shouldn't call something consent if saying no isn't really an option.
12. What happens when a relationship ends?
Leaving an organisation is not the same as leaving Mosa.
And leaving Mosa is not necessarily the same as erasing every historical record of something that happened.
These are different events:
- Organisation relationship ends
- Mosa Account closes
- Mosa identity is deleted or de-identified where appropriate
- Historical participation records are retained where legitimately required
For example, an organisation may legitimately need to retain a historical record showing that a person volunteered at an event on a particular date.
That doesn't necessarily mean the organisation should retain ongoing access to the person's current contact details or everything else in their Mosa profile.
Similarly, deleting an Account should not make historical events falsely appear never to have occurred where legitimate records must remain.
Mosa's goal is to remove ongoing access where it is no longer justified while dealing responsibly with historical records that still have a legitimate reason to exist.
13. Keeping Mosa safe
Privacy also depends on security.
Community.OS is designed so simply working for Sidekick Platforms does not create a general right to inspect participant information.
Our underlying principle is:
Platform employment does not equal information authority.
Where support is required, we prefer to understand what has gone wrong without unnecessarily exposing the information behind it.
Our internal model progresses from:
Diagnostic → Delegated → Break-Glass
Diagnostic access should help support teams understand system state without unnecessarily seeing participant content.
Delegated access may be used where greater access is genuinely required and appropriately authorised.
Break-glass access is intended for exceptional circumstances where normal pathways cannot safely resolve a serious issue.
Powerful access should remain exceptional, attributable and reviewable.
And where Mosa deliberately uses technology that prevents the platform itself from reading particular protected information, emergency access should not secretly defeat that protection.
Being able to operate Mosa does not mean being able to see everything inside it.
14. When Mosa changes
Mosa will evolve.
Community.OS is intended to support many parts of community life over time, not just participation.
New Community Spaces may introduce new information, purposes and workflows.
But they should inherit the same underlying identity, privacy, authority, safeguarding and trust foundations.
A new feature shouldn't quietly create a new privacy model.
Where we materially change how information is handled, introduce an important new purpose or change terms that affect you, the appropriate notice, agreement or consent interaction should follow.
And where you've previously agreed to something, Mosa should preserve which version applied at that time.
Today's policy should not rewrite yesterday's history.
15. Want the legal detail?
This page is designed to explain Mosa's approach to privacy in everyday language.
It doesn't replace our formal legal documents.
As the Mosa legal and trust centre is completed, you'll also be able to access:
Privacy Policy
The formal explanation of how OSA Management Pty Ltd handles personal information.
Children & Young People Privacy Notice
More detail about privacy for young people, parents, guardians and representatives.
Mosa Terms of Use
The terms governing use of Mosa.
Organisation Terms
The terms applying to organisations using Community.OS and Mosa.
Cookie & Tracking Notice
Information about cookies, analytics and similar technologies.
Security at Mosa
An understandable explanation of how Community.OS protects the platform and the communities that depend upon it.
Trust Centre
As Mosa grows, this will bring together our privacy, security, reliability and assurance information.
Mosa and Community.OS are operated by:
OSA Management Pty Ltd ABN 62 677 945 863 Trading as Sidekick Platforms
For privacy or trust questions:
hello@oncommunityos.com
Your identity should help make participation easier without making your life universally visible.
Mosa connects people to their communities while keeping access to information connected to legitimate relationships, purposes and authority.
As Mosa grows, we want privacy to remain something built into how the platform works, not simply something promised in a policy.
Document Status
Document: Privacy at Mosa Version: v1.0 Status: Approved Reviewed: 27 September 2026 Parent Company: Sidekick Platforms Platform: Community.OS Product: Mosa
