Mosa Organisation Terms

Document Information

1. About These Terms

1.1 Who Operates Community.OS and Mosa

Community.OS and Mosa are operated by:

OSA Management Pty Ltd ABN 62 677 945 863 Trading as Sidekick Platforms

In these Terms:

we, us and our mean OSA Management Pty Ltd;

Sidekick Platforms means our primary trading identity;

Community.OS means the underlying community operating platform;

Mosa means the participant-facing experience built on Community.OS;

Organisation means the organisation entering into these Terms; and

you and your refer to the Organisation and, where the context requires, its authorised users acting on its behalf.

1.2 These Terms Govern Organisation Use

These Terms govern an Organisation's use of Community.OS, Mosa Organisation capabilities and related services supplied by us.

They apply together with any:

• Order Form;

• subscription selection;

• Enterprise agreement;

• Community Space terms;

• Data Processing or Organisation Privacy Terms;

• implementation statement;

• service schedule;

• or other agreement expressly incorporated into them.

1.3 Acceptance

An Organisation accepts these Terms when an appropriately authorised person:

• accepts them electronically;

• signs an Order Form incorporating them;

• enters another agreement incorporating them;

• or otherwise accepts them through an approved Organisation onboarding process.

The person accepting these Terms confirms that they have authority to bind the Organisation.

1.4 Order of Precedence

If documents forming part of the Organisation's agreement conflict, the following order generally applies unless expressly stated otherwise:

1. a specifically negotiated Enterprise agreement or signed Order Form;

1. any applicable service or Community Space schedule;

1. applicable Data Processing or Organisation Privacy Terms;

1. these Organisation Terms;

1. published product documentation.

A document only overrides another document to the extent of the actual inconsistency.

2. The Relationship Between Sidekick Platforms and the Organisation

2.1 We Provide the Platform

We provide and operate Community.OS and Mosa.

The Organisation remains responsible for the community, activity, service, program, membership or other underlying relationship it operates.

2.2 The Organisation Remains Independent

Using Community.OS does not make the Organisation:

• our employee;

• our agent;

• our representative;

• our joint venture partner;

• or part of OSA Management Pty Ltd.

Similarly, Sidekick Platforms does not become the operator of the Organisation merely because the Organisation uses Community.OS.

2.3 We Do Not Run the Organisation's Activities

Unless expressly agreed otherwise, the Organisation remains responsible for its:

• memberships;

• activities;

• events;

• teams;

• programs;

• volunteers;

• employees;

• officials;

• governance;

• participant decisions;

• safeguarding;

• qualifications;

• payments;

• refunds;

• and operational practices.

Community.OS may support those activities without taking responsibility for conducting them.

3. Eligibility to Use Community.OS

3.1 Legitimate Organisations

An Organisation must be a legitimate entity, group or community body authorised to use Community.OS.

This may include:

• schools;

• sporting clubs;

• associations;

• charities;

• community Organisations;

• businesses;

• committees;

• governing bodies;

• councils;

• not-for-profits;

• or other legitimate Organisations.

3.2 Accurate Organisation Information

The Organisation must provide reasonably accurate information about itself.

This may include:

• legal or operating name;

• trading name;

• Organisation type;

• contact information;

• billing details;

• administrator details;

• and other information reasonably required to establish the Organisation.

3.3 Authority

The Organisation must ensure that people establishing or managing its Community.OS presence have appropriate authority to do so.

4. Organisation Administrators

4.1 Administrator Authority

The Organisation may appoint people to administrative or other authorised roles.

Those roles may allow significant actions involving:

• participant information;

• invitations;

• memberships;

• communications;

• exports;

• payments;

• integrations;

• roles;

• safeguarding;

• reporting;

• and Organisation configuration.

4.2 The Organisation Is Responsible for Administrator Selection

The Organisation is responsible for selecting appropriate administrators.

It should only grant administrative authority to people who reasonably require it.

4.3 Removing Access

The Organisation must remove or update administrative access when a person's authority changes or ends.

This includes where a person:

• leaves the Organisation;

• changes role;

• no longer requires the relevant authority;

• or should no longer access particular information or capabilities.

4.4 Individual Accounts

Administrators should use their own individual Accounts.

The Organisation must not intentionally create shared administrative credentials where Community.OS provides individual authenticated access.

4.5 Administrator Responsibility Does Not Replace Platform Controls

The Organisation remains responsible for appropriate administrator selection and use.

We remain responsible for implementing appropriate platform security and authority controls within Community.OS.

4.6 Regular Access Review

The Organisation must take reasonable steps to periodically review:

• administrators;

• managers;

• assigned roles;

• significant permissions;

• integration access;

• and other consequential Organisation authority.

The Organisation should remove or reduce access that is no longer reasonably required.

Regular review is particularly important for access involving:

• participant information;

• children and young people;

• Health & Safety Information;

• safeguarding information;

• communications;

• exports;

• payments;

• integrations;

• and other high-consequence capabilities.

Community.OS may provide reminders, reporting, automated controls or other tools to support these reviews.

5. People and Identity

5.1 People Are Not Organisation-Owned Records

Community.OS is built around persistent Persons.

A Person may participate with multiple Organisations throughout their community life.

The Organisation has a legitimate relationship with a Person.

It does not own that Person's underlying Mosa identity merely because the Person is:

• a member;

• volunteer;

• player;

• student;

• parent;

• employee;

• official;

• participant;

• or otherwise connected to the Organisation.

5.2 Organisation Context

The Organisation may hold and steward legitimate information arising from its own relationship with a Person.

That does not create authority over unrelated information concerning that Person.

5.3 Organisation Assertions

Community.OS may distinguish between:

• participant-controlled information;

• verified information;

• Organisation-provided assertions;

• derived information;

• and historical Organisation records.

The Organisation must not intentionally represent its own assertion as independently verified where it is not.

6. Invitations, Memberships and Onboarding

6.1 Invitations

The Organisation may invite people to establish or confirm a relationship through Mosa.

The Organisation must have a legitimate basis for doing so.

6.2 Imported Information

Where Community.OS permits member or participant imports, the Organisation must only provide information it is legitimately entitled to use for the relevant purpose.

6.3 No Artificial Identities

The Organisation must not intentionally create fake, placeholder or misleading participant identities where the platform requires a real Person relationship.

6.4 Identity Reconciliation

Where imported or Organisation-provided information appears to relate to an existing Person, Community.OS may use identity reconciliation processes rather than automatically creating a new Person.

6.5 Membership Decisions

The Organisation remains responsible for legitimate decisions concerning:

• membership;

• approval;

• rejection;

• suspension;

• termination;

• eligibility;

• and Organisation-specific participation.

Community.OS may administer or record those decisions.

7. Participant Information

7.1 Access Follows Legitimate Context

The Organisation may access participant information only to the extent made available through its legitimate relationship, role and authority within Community.OS.

7.2 Access Is Not Universal

An Organisation relationship does not automatically give access to:

• unrelated Organisation memberships;

• unrelated participation;

• complete Household information;

• private communications;

• unrelated Community Story;

• or other information outside the Organisation's legitimate context.

7.3 Minimum Necessary Use

The Organisation should use participant information only to the extent reasonably necessary for its legitimate purposes and applicable obligations.

7.4 Sensitive Information

Where the Organisation has access to sensitive, Health & Safety, safeguarding or other protected information, it must use that information appropriately and restrict access to people with legitimate need and authority.

7.5 Trusted Outcomes

Community.OS may provide the Organisation with an outcome rather than underlying evidence.

For example:

Requirement satisfied

may be provided instead of a full qualification document.

The Organisation must not attempt to circumvent those protections merely because it would prefer broader information access.

7.6 Minimum Necessary Collection

The Organisation should not request, collect, access or require participant information merely because Community.OS makes it technically possible to do so.

Information requested from a Person should be reasonably necessary for a:

• legitimate Organisation purpose;

• participation requirement;

• safety requirement;

• safeguarding requirement;

• operational requirement;

• or legal obligation.

Where Community.OS can provide an appropriate trusted outcome without revealing the underlying information, the Organisation should ordinarily rely on that outcome.

For example, where an Organisation only needs to know whether a Person satisfies a Working with Children Check or other qualification requirement, it should not require access to the underlying evidence unless there is a legitimate reason for doing so.

The Organisation should therefore consider:

• Why do we need this information?

• Who genuinely needs to see it?

• How long is it needed?

• Can Community.OS provide the required answer without revealing the underlying information?

The intended principle is:

Information should reveal itself when it is legitimately required, rather than being collected in advance simply because it may become useful.

8. Privacy Responsibilities

8.1 Shared but Distinct Responsibilities

Sidekick Platforms and the Organisation may each have privacy obligations depending on:

• the information;

• its source;

• the purpose;

• who determines the relevant processing;

• and applicable law.

8.2 Organisation Compliance

The Organisation must comply with privacy and information-handling obligations that apply to it.

8.3 Sidekick Platforms Compliance

We remain responsible for privacy obligations applicable to our operation of Community.OS and Mosa.

8.4 No Expansion Through Contract

The Organisation cannot use these Terms, its own policies or participant agreements to give itself access that Community.OS otherwise legitimately restricts.

8.5 Organisation Privacy Notices

Where the Organisation provides its own privacy notices, those notices remain the Organisation's responsibility.

The Organisation must not represent an Organisation-issued policy as a Sidekick Platforms policy.

9. Children, Young People and Safeguarding

9.1 Additional Responsibility

Where an Organisation works with children, young people or vulnerable participants, it must comply with applicable:

• safeguarding;

• child safety;

• screening;

• conduct;

• reporting;

• communication;

• and other legal or regulatory requirements.

9.2 Organisation Roles Do Not Create Unlimited Authority

A person's role as:

• teacher;

• coach;

• administrator;

• coordinator;

• volunteer;

• official;

• or employee

does not automatically entitle them to unrestricted access or communication with a young Person.

9.3 Platform Safeguards

Community.OS may restrict or shape communication and information access according to safeguarding rules.

The Organisation must not intentionally bypass those controls.

9.4 Organisation Policies

The Organisation may apply additional safeguarding controls where appropriate.

Those controls should not weaken platform protections.

9.5 Serious Concerns

Serious safeguarding concerns may require escalation beyond ordinary Organisation administration.

We may take platform-level action where appropriate to protect participants or Community.OS.

10. Activities and Opportunities

10.1 Organisation Responsibility

The Organisation is responsible for activities and opportunities it publishes or operates through Community.OS.

10.2 Lawful and Appropriate Opportunities

Activities and opportunities must comply with applicable law and legitimate regulatory requirements.

Depending on the context, this may include:

• child safety;

• workplace requirements;

• health and safety;

• insurance;

• qualification requirements;

• licensing;

• anti-discrimination laws;

• sporting rules;

• and governing-body requirements.

10.3 Accurate Descriptions

The Organisation must not knowingly publish materially misleading information about:

• an activity;

• opportunity;

• role;

• qualification requirement;

• cost;

• eligibility;

• location;

• commitment;

• or other material participation condition.

10.4 Participant Safety

The Organisation remains responsible for operating its activities safely and appropriately.

Using Mosa does not transfer that responsibility to Sidekick Platforms.

11. Participation Records

11.1 Organisation Records

The Organisation may create or maintain legitimate records concerning:

• registration;

• attendance;

• roles;

• participation;

• volunteer activity;

• qualifications;

• requirements;

• recognition;

• or other Organisation interactions.

11.2 Accuracy

The Organisation must take reasonable care not to knowingly create materially false or misleading participation records.

11.3 Historical Integrity

The Organisation should not alter historical records merely to create a preferred current narrative.

Where correction is appropriate, Community.OS may preserve relevant provenance or history.

11.4 Community Story

Legitimate Organisation participation may contribute to a Person's Community Story according to Community.OS rules.

The Organisation does not obtain ownership of the Person's broader Community Story.

12. Communications

12.1 Organisation Communications

Community.OS may allow the Organisation to communicate with people connected to it.

12.2 Legitimate Communication Context

The Organisation must only communicate through authority appropriate to the relevant relationship and purpose.

12.3 Operational Communications

The Organisation may send legitimate operational communications concerning matters such as:

• memberships;

• events;

• rosters;

• activities;

• registrations;

• requirements;

• safety;

• or Organisation operations.

12.4 Communications Must Be Appropriate

The Organisation must not use Community.OS to send:

• unlawful communications;

• harassment;

• threats;

• abusive material;

• spam;

• deceptive communications;

• unlawful discriminatory material;

• grooming or exploitative content;

• or other seriously inappropriate communications.

12.5 Safeguarding

Communication involving children or protected contexts may be subject to additional safeguarding controls.

13. Marketing and Commercial Communications

13.1 Organisation Marketing

The Organisation may only use participant information for marketing or promotional communication where it has appropriate authority to do so.

13.2 Organisation Relationships Do Not Create Blanket Marketing Permission

Membership or participation does not automatically mean every commercial communication is permitted.

13.3 External Commercial Relationships

Where the Organisation establishes its own sponsor, affiliate, fundraising or commercial relationship, it remains responsible for ensuring that relationship is operated lawfully and consistently with participant privacy.

14. Exports

14.1 Export Capability

Community.OS may permit authorised Organisation users to export information where export functionality is included in the Organisation's applicable plan.

14.2 Export Authority Must Follow Visibility

An export should not provide information the exporting user would not otherwise be entitled to access.

14.3 Organisation Responsibility After Export

Once information is legitimately exported into an Organisation-controlled environment, the Organisation becomes responsible for protecting and using that copy appropriately.

14.4 Export Does Not Expand Rights

The ability to export information does not give the Organisation broader rights over the information.

14.5 Bulk Information Requires Care

The Organisation must take particular care with bulk exports because aggregation can increase privacy and security consequence.

14.6 Export Is a Plan Capability

Data export may only be available to Organisations with an active eligible paid plan.

An Organisation should export any legitimate Organisation information it reasonably requires before the applicable paid subscription ends or is cancelled.

Cancellation, downgrade or expiry does not create a continuing contractual entitlement to paid export functionality after the relevant subscription has ended.

This does not limit any information-access, portability or other right that must be provided under applicable law or another binding agreement.

15. Integrations and External Systems

15.1 Organisation-Controlled Integrations

Community.OS may allow the Organisation to connect external systems.

15.2 Organisation Responsibility

Where the Organisation selects or controls an external system, the Organisation is responsible for:

• selecting the system;

• ensuring its use is lawful and appropriate;

• controlling users and credentials on that system;

• protecting information after it enters that system;

• and disconnecting access when no longer required.

15.3 Community.OS Responsibility

We remain responsible for enforcing appropriate Community.OS integration boundaries and credentials that we control.

15.4 Limited Authority

Connecting an external system does not create unlimited access to Community.OS.

The canonical Security Architecture distinguishes Organisation-controlled external systems from Sidekick Platforms suppliers, because responsibility should reflect who selected and controls the service.

16. Organisation Content

16.1 Content the Organisation Provides

The Organisation may provide:

• logos;

• images;

• documents;

• policies;

• opportunity information;

• communications;

• Organisation descriptions;

• or other content.

16.2 Ownership

The Organisation retains ownership of content it owns.

16.3 Licence to Operate the Service

The Organisation gives us permission to host, store, reproduce, display and process that content to the extent reasonably required to:

• operate Community.OS and Mosa;

• provide the Organisation's services through the platform;

• present relevant content to authorised users;

• maintain platform integrity;

• and comply with law.

16.4 Authority to Provide Content

The Organisation must have appropriate rights to provide content it uploads or publishes.

17. Sidekick Platforms Intellectual Property

17.1 Ownership

We or our licensors own the intellectual property in:

• Community.OS;

• Mosa;

• platform software;

• interfaces;

• product architecture;

• documentation;

• branding;

• and related materials.

17.2 Organisation Licence

We grant the Organisation a limited, non-exclusive right to use the subscribed services for its legitimate internal and community purposes during the applicable subscription or authorised usage period.

17.3 Restrictions

The Organisation must not intentionally:

• copy or commercially exploit our software except as permitted;

• reverse engineer the service except where applicable law permits;

• bypass technical restrictions;

• interfere with Community.OS security;

• misuse APIs or integrations;

• or represent our intellectual property as its own.

18. Feedback

18.1 Feedback Is Welcome

The Organisation may provide ideas, suggestions and product feedback.

18.2 Use of Feedback

We may use voluntary feedback to improve Community.OS without owing compensation for that feedback.

This does not transfer ownership of unrelated Organisation content, confidential information or participant information.

19. Security Responsibilities

19.1 Shared Responsibility

Security responsibilities are shared according to control and authority.

19.2 Sidekick Platforms Responsibilities

We are responsible for the security of Community.OS capabilities we control, including areas such as:

• platform architecture;

• application security;

• infrastructure configuration;

• platform authentication;

• authorisation enforcement;

• platform encryption;

• secure development;

• monitoring;

• backup and recovery;

• platform incident response;

• and internal privileged access.

19.3 Organisation Responsibilities

The Organisation is responsible for matters within its control, including:

• selecting appropriate administrators;

• periodically reviewing access;

• removing unnecessary access;

• protecting Organisation-controlled credentials;

• using participant information appropriately;

• managing Organisation-controlled integrations;

• securing Organisation-controlled devices and systems;

• and responding to Organisation-specific security concerns.

19.4 Security Must Remain Practical

We recognise that many community Organisations do not have dedicated IT or security teams.

Community.OS should make good security behaviour easier through platform design rather than requiring Organisations to recreate enterprise security locally.

20. Account and Credential Security

20.1 Individual Authentication

Authorised users should use individual Accounts and authentication methods.

20.2 Protect Credentials

The Organisation must take reasonable steps to ensure authorised users protect their authentication credentials.

20.3 Suspected Compromise

The Organisation must tell us promptly if it becomes aware of a material compromise affecting:

• administrator access;

• integration credentials;

• Organisation-controlled authentication;

• or Community.OS access.

20.4 Additional Security Requirements

We may require stronger authentication or other protections for higher-consequence Organisation capabilities.

21. Reporting Security and Safety Concerns

21.1 Reporting

The Organisation should promptly report credible concerns involving:

• unauthorised access;

• compromised Accounts;

• safeguarding;

• fraud;

• platform misuse;

• vulnerabilities;

• or material privacy incidents

that may affect Community.OS or Mosa.

21.2 Cooperation

The parties should reasonably cooperate where an incident crosses both platform and Organisation responsibilities.

21.3 Evidence Preservation

Relevant information may need to be preserved where required for:

• security;

• safeguarding;

• investigation;

• legal obligations;

• or dispute resolution.

22. Platform Moderation and Organisation Moderation

22.1 Different Types of Authority

Community.OS distinguishes:

Organisation Moderation

from:

Platform Moderation

Organisation Moderation arises from the Organisation's legitimate community context.

Platform Moderation arises from Sidekick Platforms' responsibility to protect Community.OS, participants and platform integrity.

22.2 Platform Action

We may take platform-level action even where the Organisation has not taken its own action if we reasonably consider it necessary for:

• participant safety;

• safeguarding;

• security;

• legal compliance;

• fraud prevention;

• platform integrity;

• or enforcement of these Terms.

The Privacy Architecture expressly distinguishes Organisation moderation from platform moderation and requires platform moderation authority to remain appropriately scoped.

23. Plans and Subscriptions

23.1 Available Plans

Community.OS may offer:

• free plans;

• paid plans;

• Community Spaces;

• add-ons;

• transactional services;

• Enterprise arrangements;

• and other commercial models.

23.2 Applicable Plan

The Organisation's plan and applicable commercial terms are those shown in its:

• subscription selection;

• Order Form;

• billing experience;

• or other applicable commercial agreement.

23.3 Participants Remain Free

Our current commercial architecture is based on participants using Mosa without participant subscription fees, while Organisations pay for applicable Organisation capabilities.

23.4 Plan Features

Features and limits may vary by plan.

The Organisation should review the capabilities and limits applicable to its selected plan.

24. Active Participants

24.1 Active Participant Model

Standard Organisation pricing may use an annual Active Participant allowance.

24.2 Counting Rules

The definition of a qualifying Active Participant will be determined by the applicable product and commercial rules.

A unique qualifying Person should ordinarily count once per Organisation per subscription year under the current commercial model.

24.3 Unlimited Community Members

Standard plans currently allow Organisations to connect unlimited community members unless a specific capability states otherwise.

Connected members do not consume Active Participant allowance merely because they belong to the Organisation.

24.4 Thresholds

If an Organisation approaches or exceeds the Active Participant allowance for its current plan, it may need to upgrade.

25. Fees and GST

25.1 Fees

The Organisation must pay fees applicable to its selected plan and services.

25.2 Australian Public Pricing

Unless expressly stated otherwise, published Australian Organisation subscription prices are intended to include GST.

25.3 Other Taxes

For Enterprise, international or specially negotiated arrangements, taxes may be dealt with in the applicable Order Form or contract.

25.4 Additional Charges

Additional charges may apply for:

• Community Spaces;

• transaction services;

• implementation;

• Enterprise services;

• externally metered communication;

• payment processing;

• or other separately priced capabilities.

Any applicable fee should be disclosed through the relevant commercial experience or agreement.

26. Billing

26.1 Annual Billing

Standard paid Mosa Organisation subscriptions are currently billed annually unless another arrangement is expressly agreed.

26.2 Billing Contact

The Organisation must maintain current billing contact information.

26.3 Payment Method

The Organisation must maintain a valid payment method where automatic billing applies.

26.4 Payment Authorisation

A person entering or approving billing details confirms they have appropriate authority to do so for the Organisation.

27. Upgrades

27.1 Plan Growth

The Organisation may upgrade its plan during a subscription period.

27.2 Active Participant Growth

An Organisation that exceeds its applicable Active Participant allowance may be required to move to an appropriate higher plan.

27.3 Mid-Term Charges

Any applicable mid-term upgrade charge should be disclosed before the Organisation is charged.

The exact proration mechanics may be governed by the applicable billing specification, Order Form or commercial terms.

28. Downgrades

28.1 Downgrade Requests

An Organisation may request a downgrade where eligible.

28.2 Effective Date

Unless otherwise stated, downgrades ordinarily take effect at the next renewal.

28.3 Eligibility

A downgrade may depend on whether the Organisation fits within the limits and capabilities of the lower plan.

29. Renewal

29.1 Automatic Renewal

Paid subscriptions may automatically renew annually unless cancelled in accordance with the applicable subscription terms.

29.2 Expected Renewal Tier

Under the current commercial model, the expected renewal tier may be based on the highest applicable plan reached during the current subscription year unless an eligible downgrade is arranged before renewal.

29.3 Renewal Information

Where practicable, Community.OS should make relevant renewal information visible to authorised Organisation users.

30. Community Spaces and Add-Ons

30.1 Additional Capabilities

Community Spaces and other add-ons may carry:

• additional annual fees;

• transaction fees;

• usage fees;

• or other charges.

30.2 Additional Terms

Some Community Spaces may have specific terms reflecting their function.

30.3 Billing Alignment

Where an Organisation adds a service during an existing annual term, its billing may be aligned with the Organisation's renewal or structured through another disclosed arrangement.

31. Transaction Fees and External Communications

31.1 Transactional Services

Ticketing, fundraising, commerce and other transactional services may carry separately disclosed:

• transaction fees;

• payment-processing fees;

• or other relevant charges.

31.2 External Communications

SMS or other externally metered communication channels are not included in standard Mosa Participation unless expressly stated.

32. Non-Payment

32.1 Payment Obligations

The Organisation must pay applicable undisputed fees when due.

32.2 Failed Payment

If a payment fails or becomes overdue, we may:

• notify the Organisation;

• request updated payment details;

• retry payment where authorised;

• restrict paid capabilities;

• suspend access to affected services;

• or take another reasonable step.

32.3 Proportionate Restriction

Where practical, non-payment restrictions should be proportionate.

We do not need to disable unrelated participant safety or historical information simply because one paid feature is overdue.

32.4 Outstanding Amounts

Suspension or termination does not automatically extinguish amounts legitimately owing.

33. Cancellation

33.1 Organisation Cancellation

The Organisation may cancel according to the cancellation process applicable to its plan or agreement.

33.2 Effective Date and Financial Consequences

The effective date and any financial consequences of cancellation will be determined by:

• the applicable Order Form;

• subscription terms;

• Enterprise agreement;

• or other published commercial terms.

33.3 Refund and Early Cancellation Rules

Any refund or early cancellation entitlement will be determined by the applicable commercial terms and mandatory legal rights.

These Terms do not create an additional universal refund entitlement beyond those arrangements.

34. Price Changes

34.1 Future Pricing

We may change pricing over time.

34.2 Existing Subscription Period

Unless otherwise agreed, a pricing change should not retrospectively alter amounts already paid for a current fixed subscription period.

34.3 Renewal Pricing

Updated pricing may apply at a future renewal following appropriate notice.

34.4 Negotiated Contracts

Enterprise or other negotiated agreements may contain different price-change provisions.

35. Free Plans

35.1 Free Access

We may offer free Organisation plans or trial capabilities.

35.2 Free Does Not Mean Permanent

Unless expressly stated, we do not guarantee that every free feature, allowance or plan will remain unchanged forever.

35.3 Material Changes

Where a material change affects an Organisation's continuing use, we should provide reasonable notice where practical.

36. Enterprise Arrangements

36.1 Enterprise Terms

Larger Organisations, networks, governing bodies or other customers may enter negotiated Enterprise arrangements.

36.2 Enterprise Extensions

Enterprise arrangements may include:

• custom pricing;

• multiple Organisations;

• advanced security;

• integrations;

• support;

• reporting;

• implementation;

• service commitments;

• or other negotiated capabilities.

36.3 Enterprise Does Not Override Core Trust Architecture

An Enterprise contract may extend Community.OS.

It should not create a hidden parallel identity, privacy or security model.

37. Service Availability

37.1 Reliable Operation

We aim to operate Community.OS reliably.

37.2 Technology Can Fail

The platform may experience:

• maintenance;

• outages;

• provider failures;

• network failures;

• defects;

• incidents;

• or other interruptions.

37.3 No General SLA Unless Agreed

We do not promise a specific uptime percentage, response time or recovery commitment unless that commitment is expressly included in an applicable agreement or service schedule.

37.4 Partial Service

Where appropriate, Community.OS may preserve useful partial functionality while another capability is unavailable.

The canonical reliability model expressly prefers safe partial functionality where practical rather than treating one provider failure as a reason for total platform failure.

38. Maintenance and Changes

38.1 Platform Evolution

Community.OS will evolve.

We may:

• add;

• modify;

• replace;

• improve;

• or retire

features over time.

38.2 Material Changes

Where a change materially affects an Organisation's paid service, we should provide appropriate notice where reasonably practical.

38.3 Security and Emergency Changes

Security, safety or urgent operational changes may need to occur without advance notice.

39. Beta, Pilot and Preview Capabilities

39.1 Developing Features

We may provide beta, pilot, preview or developing capabilities.

39.2 Different Maturity

Those capabilities may:

• change frequently;

• contain defects;

• have limited support;

• or be withdrawn.

39.3 Identification

Where material, we should identify the capability as beta, preview or equivalent.

40. Suspension of an Organisation

40.1 When We May Suspend or Restrict

We may restrict or suspend an Organisation or particular Organisation capabilities where reasonably necessary because of:

• unlawful conduct;

• participant safety;

• safeguarding risk;

• fraud;

• security risk;

• misuse of participant information;

• serious or repeated platform abuse;

• material breach of these Terms;

• non-payment;

• credible regulatory or legal concern;

• compromised administrator access;

• misuse of communications;

• misleading or harmful opportunities;

• or other material risk to participants, Community.OS or Sidekick Platforms.

40.2 Proportionate Action

Where appropriate, we may restrict a particular capability instead of suspending the entire Organisation.

40.3 Immediate Action

We may act immediately where delay could materially increase:

• harm;

• safeguarding risk;

• fraud;

• security exposure;

• or legal risk.

40.4 Notice

Where appropriate, we will provide information about:

• the restriction;

• the reason;

• required remediation;

• and any available review process.

40.5 Purpose of Suspension Rights

Our suspension rights exist to protect legitimate platform, participant, Organisation and legal interests.

They are not intended to create an arbitrary right to suspend Organisations without reasonable basis.

41. Organisation Termination

41.1 Termination by the Organisation

The Organisation may terminate its relationship according to the applicable subscription or contractual terms.

41.2 Termination by Us

We may terminate the Organisation's access where:

• a serious breach is not capable of remedy;

• a remediable material breach is not remedied within a reasonable period after notice;

• continued operation creates unacceptable safety, safeguarding, legal or security risk;

• the Organisation engages in serious fraud or misuse;

• the Organisation no longer legitimately exists or is authorised to use the service;

• or another applicable contractual termination right arises.

41.3 Proportionate Approach

Where suspension or remediation can reasonably resolve the issue, termination should not automatically be the first response.

42. What Happens When the Organisation Leaves

42.1 Organisation Access Ends

On termination or expiry, the Organisation's active access to Community.OS may end or become restricted.

42.2 Participant Identity Remains With the Person

Termination of the Organisation does not transfer or delete participant identity merely because the Organisation leaves.

42.3 Historical Records

Legitimate historical Organisation records may remain where appropriate for:

• legal obligations;

• safeguarding;

• participation history;

• financial records;

• disputes;

• security;

• or other legitimate purposes.

42.4 Ongoing Participant Access

Where appropriate, participants may retain their Mosa identity and Community Story after the Organisation leaves.

42.5 Organisation Data

Any export, return, deletion or retention process applicable to Organisation-controlled information will follow:

• applicable law;

• privacy requirements;

• the information's provenance;

• the relevant contract;

• and Community.OS architecture.

43. Data Export on Exit

43.1 Export Before Cancellation

Where export functionality is included in the Organisation's applicable paid plan, the Organisation should export any Organisation information it reasonably requires before its paid subscription ends or is cancelled.

43.2 Export Availability

Data export is a plan capability and may only be available while the Organisation has an active eligible subscription.

Cancellation, expiry or downgrade does not create a continuing right to access paid export functionality after the relevant subscription has ended.

43.3 Export Scope

Any export remains limited to information the Organisation is legitimately entitled to receive.

43.4 Participant-Controlled Information

Termination does not give the Organisation a right to extract unrelated participant-controlled information, Community Story or unrelated community relationships merely because the Person once had an Organisation relationship.

43.5 Mandatory Rights

Nothing in this section limits any right to access, receive or transfer information that applicable law or another binding agreement requires us to provide.

44. Confidentiality

44.1 Confidential Information

Each party may receive confidential information from the other.

44.2 Protection

A party receiving confidential information should:

• use it only for legitimate purposes associated with the relationship;

• take reasonable steps to protect it;

• and not disclose it except where authorised or legally required.

44.3 Exclusions

Confidential information does not include information that:

• is already lawfully public;

• was lawfully known without restriction;

• is independently developed;

• or is lawfully received from another source without confidentiality obligation.

44.4 Participant Information

Participant personal information is governed primarily by privacy and information-access rules, not merely by this general confidentiality clause.

45. Public References and Branding

45.1 Organisation Branding Within Mosa

Community.OS may display the Organisation's:

• name;

• logo;

• branding;

• and relevant public Organisation information

as part of its presence within Mosa and Community.OS.

45.2 Sidekick Platforms Branding

The Organisation must not imply endorsement, partnership, certification or another formal relationship with Sidekick Platforms beyond the Organisation's actual relationship unless expressly authorised.

45.3 Customer References

Unless the Organisation asks us not to, we may identify the Organisation as a customer or user of Community.OS or Mosa and may use its name and logo for reasonable:

• customer-reference;

• sales;

• case-listing;

• promotional;

• and marketing

purposes.

If the Organisation asks us in writing to stop future customer-reference use, we will do so within a reasonable period.

45.4 No Implied Endorsement

Identifying an Organisation as a customer or user does not mean the Organisation endorses Sidekick Platforms, Community.OS or Mosa.

We will not represent the Organisation as expressly endorsing us unless it has separately agreed to that endorsement.

46. Warranties and Authority

46.1 Mutual Authority

Each party confirms that it has authority to enter the agreement.

46.2 Organisation Warranties

The Organisation confirms that, to the best of its knowledge, it has appropriate authority to:

• operate its Organisation presence;

• appoint its administrators;

• provide Organisation-controlled information;

• publish its own content;

• and use Community.OS for its intended purposes.

46.3 No Guarantee of Participant Behaviour

We do not guarantee how individual participants will behave merely because they use Mosa.

47. Australian Consumer Law and Mandatory Rights

47.1 Rights That Cannot Be Excluded

Nothing in these Terms excludes, restricts or modifies a right, guarantee or remedy that applicable law says cannot be excluded.

47.2 Small Business Protections

Where applicable consumer or small-business protections apply to the Organisation, these Terms operate subject to those protections.

48. Allocation of Risk and Liability

48.1 Responsibility Follows Control

The parties intend responsibility to follow meaningful control.

In general:

Sidekick Platforms is responsible for matters properly within Sidekick Platforms' control. The Organisation is responsible for matters properly within the Organisation's control.

Neither party becomes responsible for every downstream consequence merely because Community.OS connects the Organisation, participants or external systems.

48.2 Organisation-Controlled Matters

To the maximum extent permitted by law, we are not responsible for loss arising from matters properly controlled by the Organisation, including:

• Organisation activities or opportunities;

• membership or participation decisions;

• team selection;

• disciplinary decisions;

• Organisation policies;

• inaccurate Organisation-supplied information;

• Organisation content;

• administrator selection;

• administrator misuse;

• failure to remove administrator access;

• Organisation-controlled credentials;

• Organisation devices or systems;

• Organisation-controlled integrations;

• third-party systems selected by the Organisation;

• Organisation communications;

• Organisation refund decisions;

• or misuse of participant information by the Organisation or its authorised users.

48.3 Participant and Third-Party Conduct

To the maximum extent permitted by law, we are not responsible merely because Community.OS was used in connection with:

• unlawful or inappropriate conduct by a participant;

• misconduct by an Organisation representative;

• failure of a participant to attend or perform a commitment;

• conduct of an independent provider;

• inaccurate information supplied by another Person;

• or another act or omission outside our reasonable control.

48.4 External Services

Where an independent third-party service, integration, payment provider, communications provider, qualification issuer or other external service is responsible for its own service or information, Sidekick Platforms does not become the issuer, guarantor or operator of that independent service merely because Community.OS integrates with it.

48.5 Organisation-Supplied Information

We do not warrant that information supplied by the Organisation is accurate merely because Community.OS stores, displays, processes or communicates it.

48.6 Platform-Controlled Matters

Nothing in these Terms transfers responsibility to the Organisation for:

• defects in Community.OS;

• failures of platform authorisation;

• failures of platform security;

• Sidekick Platforms personnel conduct;

• or other matters properly within our control.

48.7 Excluded Categories of Loss

To the maximum extent permitted by law, and subject to any applicable Order Form or Enterprise agreement, neither party is liable to the other for indirect, incidental or consequential loss that was not reasonably within the ordinary contemplation of the parties arising from the agreement.

For commercial Organisations, excluded loss may include, to the extent permitted by law:

• loss of profits;

• loss of revenue;

• loss of anticipated savings;

• loss of business opportunity;

• loss of goodwill;

• reputational loss;

• loss arising from business interruption;

• or other consequential commercial loss.

This section does not exclude liability that cannot lawfully be excluded.

48.8 Events Outside Reasonable Control

To the maximum extent permitted by law, we are not responsible for loss caused solely by matters genuinely outside our reasonable control where we have otherwise complied with our obligations.

48.9 Liability Cap

To the maximum extent permitted by law, our aggregate liability arising out of or in connection with the Organisation's use of Community.OS or the agreement may be subject to any liability cap specified in:

• the applicable Order Form;

• subscription terms;

• Enterprise agreement;

• or other applicable commercial terms.

Where no separate liability cap applies, liability remains subject to these Terms and applicable law.

48.10 Mandatory Rights Prevail

Nothing in this Section 48 excludes, restricts or modifies liability where applicable law says it cannot be excluded, restricted or modified.

49. Organisation Indemnity

49.1 Organisation-Caused Claims

To the extent permitted by law, the Organisation indemnifies us against reasonable loss or third-party claims directly resulting from:

• the Organisation's intentional unlawful conduct;

• serious or deliberate misuse of Community.OS;

• content the Organisation had no lawful right to provide;

• material infringement of third-party intellectual property rights by Organisation content;

• or material conduct clearly outside the Organisation's legitimate authority.

49.2 Proportionate Responsibility

The indemnity applies only to the extent the relevant loss or claim was caused by the Organisation.

49.3 Exclusions

The Organisation is not required to indemnify us for:

• our own negligence;

• our own wrongful conduct;

• platform failures properly within our responsibility;

• losses caused by our material breach;

• or liability that cannot lawfully be transferred.

49.4 Purpose

This clause is intended to allocate genuine Organisation-caused risk rather than transfer ordinary Sidekick Platforms business risk to community Organisations.

50. Insurance

50.1 Organisation Insurance

The Organisation remains responsible for determining what insurance it requires for its own:

• activities;

• people;

• programs;

• events;

• facilities;

• products;

• or operations.

50.2 Mosa Is Not Insurance

Use of Community.OS does not provide insurance cover unless expressly stated.

51. Compliance With Law

51.1 Each Party's Responsibilities

Each party must comply with laws applicable to its own activities and responsibilities.

51.2 Organisation-Specific Regulation

The Organisation remains responsible for regulatory requirements arising from the type of Organisation or activity it operates.

51.3 Platform Compliance

We remain responsible for legal obligations applicable to our operation of Community.OS and Mosa.

52. Records and Auditability

52.1 Platform Records

Community.OS may maintain records of consequential actions such as:

• administrator changes;

• agreements;

• billing;

• exports;

• integrations;

• participation;

• security actions;

• safeguarding actions;

• or other important events.

52.2 Purpose

Those records may support:

• security;

• accountability;

• dispute resolution;

• privacy;

• safeguarding;

• service operation;

• and legal obligations.

52.3 No Unnecessary Surveillance

Auditability should remain proportionate to legitimate purposes.

Platform security does not justify unnecessary surveillance of Organisations or participants.

53. Support

53.1 Standard Support

Support available to the Organisation may vary by plan.

53.2 Enterprise Support

Enterprise customers may receive additional support commitments where expressly agreed.

53.3 No Implied 24/7 Support

We do not promise continuous human support unless expressly included in the Organisation's applicable agreement.

54. Service Levels

54.1 No General SLA

Standard plans do not automatically include a contractual Service Level Agreement.

54.2 Agreed SLAs

Where an SLA applies, it must be expressly documented.

54.3 Evidence-Based Commitments

Any service commitment should reflect actual platform capability and operational maturity rather than aspirational language.

The Security Architecture expressly requires service commitments to be supported by actual capability and evidence rather than invented contractually.

55. Changes to These Terms

55.1 Updates

We may update these Terms as:

• Community.OS evolves;

• legal requirements change;

• commercial arrangements evolve;

• security requirements change;

• or new Community Spaces are introduced.

55.2 Material Changes

Where a material change affects an Organisation's rights or obligations, we will provide appropriate notice.

55.3 Reacceptance

Where the nature of a change requires renewed agreement, we may require an authorised Organisation representative to accept the updated Terms.

55.4 Historical Versions

A new version does not rewrite the historical agreement that applied earlier.

56. Notices

56.1 Electronic Notices

Contractual and operational notices may be provided electronically through:

• Community.OS;

• Mosa;

• email;

• or another agreed method.

56.2 Organisation Contact Details

The Organisation must maintain appropriate:

• administrative;

• legal;

• and billing

contact information where required.

57. Assignment

57.1 Organisation Assignment

The Organisation must not assign its contractual rights or obligations to another entity without our consent where the assignment would materially change the customer relationship.

57.2 Corporate Changes

We may assign the agreement as part of a legitimate:

• corporate restructure;

• sale;

• merger;

• or transfer of the Community.OS business,

provided the Organisation's substantive rights are not unlawfully reduced.

58. Force Majeure and Events Outside Reasonable Control

Neither party is responsible for failure caused solely by an event genuinely outside its reasonable control to the extent that:

• the event caused the failure;

• the affected party took reasonable steps appropriate to the circumstances;

• and applicable law does not require otherwise.

This does not excuse obligations that remain reasonably capable of performance.

59. Disputes

59.1 Good-Faith Resolution

If a contractual dispute arises, the parties should first try to resolve it through appropriate representatives.

59.2 Escalation

A dispute may be escalated to senior representatives where appropriate.

59.3 Urgent Relief

Nothing prevents either party seeking urgent legal relief where necessary.

59.4 Mandatory Rights

This section does not restrict rights that cannot lawfully be restricted.

60. Governing Law

60.1 Governing Law

These Terms are governed by the laws of New South Wales, Australia, together with applicable Commonwealth laws.

60.2 Jurisdiction

Subject to mandatory legal rights, the courts of New South Wales and courts entitled to hear appeals from them may hear disputes relating to these Terms.

61. If Part of These Terms Cannot Be Enforced

61.1 Reading Down

If a provision is unlawful, void or unenforceable, it should be read down where reasonably possible.

61.2 Severance

If it cannot be read down, the affected provision may be severed without invalidating the remainder of the agreement, to the extent permitted by law.

62. No Waiver

62.1 Rights Are Not Automatically Waived

Failure to immediately enforce a right does not necessarily waive that right.

62.2 Individual Resolutions

Resolving an individual situation pragmatically does not automatically create a permanent rule for every future Organisation.

63. Entire Agreement

These Terms together with incorporated:

• Order Forms;

• schedules;

• Enterprise agreements;

• Community Space terms;

• and other expressly incorporated documents

form the agreement concerning the Organisation's use of Community.OS.

They do not automatically override unrelated agreements between the Organisation and participants or third parties.

64. Contact

Community.OS and Mosa are operated by:

OSA Management Pty Ltd ABN 62 677 945 863 Trading as Sidekick Platforms

Organisation enquiries:

hello@oncommunityos.com

Additional support and commercial contact channels may be available through Community.OS.

65. Definitions

65.1 Account

Account means an authenticated means of accessing Community.OS or Mosa.

65.2 Active Participant

Active Participant means a Person satisfying the applicable qualifying participation rules for the Organisation's commercial plan during the relevant subscription period.

65.3 Administrator

Administrator means a Person given Organisation authority to administer one or more Community.OS capabilities.

65.4 Community.OS

Community.OS means the community operating platform developed and operated by OSA Management Pty Ltd.

65.5 Community Space

Community Space means a capability area within Community.OS such as:

• Participation;

• Sport;

• Fundraising;

• Facilities;

• Governance;

• Learning;

• Commerce;

• or another future capability.

65.6 Community Story

Community Story means the evolving record of a Person's legitimate community participation, contribution, roles, qualifications, achievements and recognition, subject to applicable provenance, privacy and visibility rules.

65.7 Enterprise

Enterprise means a separately negotiated Organisation or network arrangement that may include customised commercial, service or technical terms.

65.8 Mosa

Mosa means the participant-facing experience built on Community.OS.

65.9 Organisation

Organisation means the entity, group or community body entering these Terms.

65.10 Organisation Information

Organisation Information means information legitimately created, supplied or controlled by the Organisation in connection with its Community.OS relationship, excluding information belonging to another information ownership or stewardship context merely because the Organisation can access it.

65.11 Order Form

Order Form means an ordering or commercial document identifying applicable services, fees, term or other agreed commercial conditions.

65.12 Person

Person means the persistent individual identity represented within Community.OS.

65.13 Sidekick Platforms

Sidekick Platforms means the primary trading identity of OSA Management Pty Ltd used in connection with Community.OS and Mosa.

65.14 Terms

Terms means these Mosa Organisation Terms together with incorporated documents applicable to the Organisation.

Organisation Terms Commitment

Community.OS should help Organisations operate stronger communities without requiring them to build their own identity, participation, privacy, communication and security infrastructure from scratch.

The relationship should remain clear:

Sidekick Platforms operates the platform. The Organisation operates its community. People retain their persistent identity. Organisation authority remains contextual. Information should be requested because it is genuinely needed, not simply because it can be collected. Participant information is available because of legitimate relationships, not because an Organisation owns the Person. Security responsibility follows meaningful control. Sidekick Platforms stands behind the platform capabilities it controls. Organisations remain responsible for the community decisions, activities and systems they control. Commercial arrangements should be transparent and configurable without weakening the trust foundation underneath Community.OS.

When those responsibilities are clear, Community.OS can give Organisations powerful capabilities without giving them unnecessary authority, and participants can trust that joining an Organisation does not mean surrendering control of their wider community identity.

Document Status

Version: v1.0 Status: Approved Reviewed: 27 September 2026 Owner: Sidekick Platforms Platform: Community.OS Consumer Product: Mosa