NableU

NableU Privacy Notice

Status: Effective for the NableU controlled Alpha Version: 2026-08-30 Issue: #207 Operator: NableU Community Systems Incorporated (INC2601035), a New South Wales incorporated association

This is NableU's central platform Privacy Notice and APP Privacy Policy for the controlled Alpha from 30 August 2026. It does not replace shorter collection notices and permission explanations shown at relevant collection points.

Plain-language summary

NableU is built around participant agency. Our privacy model follows the same principle: collect what has a real purpose, show who can see it, separate human sharing from AI use, and do not turn access to one part of the system into general access to everything else.

In practical terms:

1. Who we are

NableU is operated by NableU Community Systems Incorporated, NSW incorporated association INC2601035, incorporated on 4 August 2026.

For this Notice, personal information means information or an opinion about an identified individual, or an individual who is reasonably identifiable. Sensitive information includes categories given additional protection under privacy law, such as health information, racial or ethnic origin, religious beliefs or affiliations, sexual orientation, criminal record and some biometric information.

NableU's platform can handle disability, support, access and other information that may be health information or otherwise sensitive. This Notice is therefore designed on the basis that NableU should operate to the standards of the Privacy Act 1988 (Cth) and Australian Privacy Principles (APPs) and, where applicable to the information/activity, the Health Records and Information Privacy Act 2002 (NSW) (HRIP Act) and Health Privacy Principles (HPPs).

The exact application of a law can depend on the activity and record involved. NableU will not use uncertainty about technical classification as a reason to lower the privacy standard applied to participant information.

2. What this Notice covers

This Notice covers personal information handled through NableU's authenticated platform and closely related account, support, security and operational processes.

A separate or additional notice may apply to:

Where we ask for personal or sensitive information, we should also provide a collection-point explanation when context is needed to understand why it is being requested, whether it is optional, what happens if it is not provided, who may see it and whether it will be used by an external service or AI feature.

3. Information we collect and hold

What we collect depends on how you use NableU. We do not need every category from every user.

3.1 Account and contact information

This may include:

3.2 Participant information

Depending on the features you choose, this may include:

Some of these records may reveal or constitute health information or other sensitive information.

3.3 NDIS participant identifiers

Where the current workflow asks for or allows an NDIS participant number, NableU treats it as restricted account/verification information rather than a public profile field.

The current implementation stores the number in protected form and uses a one-way comparison value and limited display fragment for duplicate-account/verification purposes. It is not intended to be exposed to workers merely because they can see a participant profile.

During the current controlled Alpha, initial participant registration asks for an NDIS participant number for duplicate-account and verification purposes. It remains restricted account information and is not a public profile field. NableU is reviewing whether this identifier can become optional at initial registration under its data-minimisation approach.

NableU will not ask for government identity documents by default merely because a participant has an NDIS number.

3.4 Worker information

Depending on the feature and what the worker chooses to provide, this may include:

A worker's public/discoverable profile is separate from restricted account details and restricted evidence. NableU should explain what becomes visible before a worker makes a profile discoverable.

3.5 Support Coordinator information

This may include:

A Support Coordinator relationship does not create unrestricted participant access. If a required participant grant is absent, the platform should deny access rather than treating the role label as authority.

3.6 Organisation information

This may include:

Personal information relating to organisation owners, workers and contacts remains personal information even when associated with an organisation record.

3.7 Communications and user content

We may hold:

The audience varies by feature. NableU should display the effective audience before consequential sharing. A private draft or private reflection does not become public merely because other NableU content is social/community content.

3.8 Support, safety and complaints information

If you contact support, raise a concern or make/receive a complaint, we may collect the information reasonably needed to understand, route, investigate and resolve it. This can include sensitive information if it is relevant to the issue.

Generic audit or diagnostic records should not copy message bodies, private reflections, credentials, support-case narratives or sensitive documents merely for convenience.

3.9 Usage, audit and provenance information

NableU may record structured information about material actions so that important events can be reconstructed, such as:

We use privacy-minimised provenance rather than treating a general audit log as a second copy of private content.

NableU may also collect coarse analytics about feature entry/completion, reliability and usability. Product analytics should avoid unnecessary sensitive field values.

3.10 AI/reasoning and optional live-voice request information

The optional Ikirōne companion uses bounded server-side provider routes. When you actively submit a typed request, the current implementation may send to the configured reasoning provider:

If you enable the buddy and deliberately press Talk with Ikirōne, the browser asks for microphone permission and establishes a live WebRTC session through NableU's authenticated voice endpoint. Live microphone audio and provider audio replies then pass through that realtime connection. NableU does not request input speech transcription, store raw voice audio or create a persistent voice transcript in this Alpha implementation. If enabled in Expression settings, temporary text for Ikirōne's spoken replies is held in the page and cleared when the account/context ends.

The current typed and voice adapters do not retrieve your My Manual, messages, private reflections or participant records for the provider request. Stored information is not added to a provider request unless you have explicitly opted in to the relevant AI feature or setting that authorises that specific context. The adapters have no authority to change NableU data or act on your account. The typed provider request is configured with response storage disabled (store:false); the voice session is configured without tools, persistent memory or NableU transcript storage.

A future cognition system that uses additional participant records, persistent AI memory, stored voice/transcript content, tools or different processing zones must not inherit permission merely from this Notice or from the fact that the data is already stored. It requires the appropriate explicit context authority, updated notice and, where required, consent.

4. Where information comes from

We usually collect information directly from you when you create an account, complete a profile, set preferences, communicate, upload evidence, enter an agreement, join a group, use an assistant feature or contact support.

We may also receive information:

If we collect health information about you from another person and law requires us to notify you, we will take reasonable steps to do so unless an exception applies.

An invitation about you does not authorise NableU to publish a worker profile or relationship on your behalf before you take the required acceptance step.

5. Why we collect, use and disclose information

NableU handles information only for purposes connected with its functions and activities and the relationship/permission involved. These purposes may include:

We do not treat "it might be useful later" as a sufficient reason to collect sensitive information.

6. Sensitive and health information

NableU may handle information about disability, health, access needs, safeguarding, cultural or ethnic background, religion/spirituality, criminal-record checks, immunisation or other sensitive matters.

Where consent is required to collect sensitive information, that consent must be informed, voluntary, current/specific and given by a person with capacity or lawful authority. We should ask at the relevant collection point, not rely on the registration statement "I have read the Privacy Notice" as blanket consent.

Where a sensitive field is optional, NableU should say so. Where a field is necessary for a feature, we should explain why and what happens if it is not provided.

Private reflections and similarly sensitive participant-authored material are not generic trust evidence, AI context or organisation data merely because they exist in NableU.

7. Who can see or receive information

The actual recipient depends on the feature, relationship, scope and audience.

7.1 Other NableU users

Information may be shared with another user when you choose or authorise a feature that requires it, for example:

NableU should apply the minimum effective scope rather than treating one relationship as permission to see all information about a person.

7.2 NableU people with an operational need

Authorised NableU personnel may access information to operate, secure, support or govern the system where their role requires it. Ordinary management/support access is not a general private-data bypass. Exceptional forensic access, if needed, must follow the stronger controls defined for that purpose.

7.3 Service providers/processors

NableU uses or may use service providers needed to operate the platform, including categories such as:

Service providers receive only information reasonably necessary for the service they perform and should be subject to appropriate contractual, security and privacy controls.

NableU keeps an operational processor/subprocessor register for the services used to run the platform. Provider arrangements and processing locations can change, so NableU does not infer a country from a vendor's headquarters. Where applicable privacy law requires disclosure of likely overseas countries, NableU will publish verified information and update this Notice. Current processor information can be requested at hello@nableu.org.

7.4 Legal, regulatory and safety disclosures

We may use or disclose information where required or authorised by law, a valid court/tribunal/regulatory process, or an applicable privacy-law exception. This can include a serious threat, safeguarding or emergency circumstance where the law permits the disclosure.

Where practicable, we will assess the authority and scope of a request rather than disclose a broader dataset by default.

7.5 No sale of personal information

NableU does not sell personal information or operate a data-broker model.

We do not give advertisers access to private participant information for behavioural advertising.

8. AI, automated matching and decision transparency

NableU distinguishes several different things that are often incorrectly collapsed into "AI consent":

  1. storing information in NableU;
  2. sharing information with another human;
  3. allowing information to be used as context for a particular AI request;
  4. retaining information as persistent AI memory; and
  5. using information for model training.

Permission for one does not grant any of the others. Stored information is not used as AI context, persistent AI memory or model-training data unless you have explicitly opted in to that specific use. Enabling one AI feature or setting does not authorise another.

Current matching is intended to preserve deterministic eligibility/safeguarding rules and explicit participant preferences as the authoritative layers, with bounded computational/AI interpretation or explanation where enabled. NableU should not silently rewrite participant preferences because a model inferred something different.

From 10 December 2026, additional APP Privacy Policy transparency obligations commence for arrangements where a computer program uses personal information to make decisions that could reasonably be expected to significantly affect an individual's rights or interests. Before that date, NableU must complete an automated-decision inventory and update this Notice if any NableU arrangement falls within those provisions.

Irrespective of that statutory threshold, consequential automated or AI-assisted outputs should be explainable enough for users to understand the material factors and should not become unreviewable authority merely because they were generated automatically.

9. Direct marketing and service communications

NableU may send communications necessary to operate your account or a feature you use, such as verification, security, relationship, message, scheduling, agreement, support or service-status notifications. These are service communications rather than optional product marketing.

Optional NableU product updates are a separate choice. Registration currently records that choice independently from acceptance of the Terms and acknowledgement of the Privacy Notice. You may withdraw an optional marketing choice through the available account preference or contact channel.

Withdrawing optional product marketing does not stop messages reasonably necessary to secure or operate your account.

10. Overseas processing and disclosure

Some technology providers may process information outside Australia or use global infrastructure.

NableU must assess whether each arrangement is a use by a controlled contractor, an overseas disclosure, or another form of processing under the applicable law and contract. Where NableU discloses personal information to an overseas recipient, we will take the steps required by applicable privacy law, including reasonable contractual/technical safeguards and transparency about likely countries where required.

NableU publishes verified country information when reasonably practicable and required by applicable privacy law. Where a provider uses global or dynamically allocated infrastructure and a reliable country list cannot yet be stated, NableU will say so rather than guess.

11. How we protect information

NableU uses technical and organisational safeguards proportionate to the information and current platform risk. Current controls include, at a high level:

No internet service can promise absolute security. NableU maintains security and incident controls and will respond to suspected breaches according to the nature of the event and applicable law.

We do not publish operational security detail where doing so would weaken the control itself.

12. Data breaches

If NableU becomes aware of a suspected data breach, we will assess and contain it, investigate the affected information/people, remediate the cause where practicable and meet applicable notification duties.

Where the Notifiable Data Breaches (NDB) scheme applies and an eligible data breach has occurred, NableU will notify affected individuals and the Office of the Australian Information Commissioner as required.

Other notification or incident duties may also apply depending on the affected information or NableU's regulatory status at the time.

13. How long we keep information

NableU retains information only for as long as reasonably needed for the purpose for which it is held, or for a longer period where a law, genuine evidence/audit requirement, dispute, safety need, financial obligation or other lawful purpose requires retention.

Different records need different rules. For example, a temporary invitation token, an account record, a bilateral Service Agreement, a community post, a security event and health information should not all inherit one arbitrary retention period.

When information is no longer required and no lawful retention reason applies, NableU should securely delete or de-identify it, including through the applicable backup lifecycle.

NableU applies record-class retention rather than one blanket period. The detailed operational schedule is maintained and expanded as controlled-Alpha features mature. Where a statutory minimum applies — including any applicable HRIP Act rule for health information — that minimum overrides a shorter ordinary deletion period.

Archiving a record is not the same as deleting it.

14. Accessing your information

You may ask NableU whether we hold personal information about you and request access to it, subject to applicable legal exceptions.

Where the platform already gives you safe direct access to a record, you may use that mechanism. For a broader privacy request, use the privacy/contact channel identified in section 20.

We may need to verify your identity or authority before releasing information. We will not disclose another person's private information merely because it appears in a record connected to you.

If a request involves health information and the HRIP Act applies, NableU will also follow the applicable NSW access requirements and timeframes.

15. Correcting information

You may update many profile and preference fields directly.

If personal information NableU holds about you is inaccurate, out of date, incomplete, irrelevant or misleading, you may ask us to correct it. Where we cannot change a historical record without destroying its evidentiary meaning, we may preserve the original record and attach or record the correction rather than silently rewriting history.

This is especially important for immutable agreement revisions, audit/provenance and other records whose purpose is to show what was actually agreed or recorded at a particular time.

16. Deletion, de-identification and account closure

You may request account closure and, where law permits, deletion or de-identification of personal information that NableU no longer needs.

A deletion request does not necessarily mean every connected record can be erased immediately. We may need to preserve, for example:

Where full deletion is not lawful or appropriate, NableU should explain the applicable reason and restrict further use to the retained purpose.

17. Anonymity and pseudonymity

Where lawful and practicable, NableU should allow people to seek general information or use public information without identifying themselves.

Some platform functions cannot operate anonymously because they depend on identity, authority, bilateral agreement, safeguarding, account security or relationship provenance.

NableU should not require identification merely for convenience when the feature can reasonably operate without it.

18. Children and authorised representatives

Information about children can be especially sensitive. NableU must consider the child's capacity, the authority of the adult acting for them, the child's own rights and preferences, and the purpose of the information handling.

The current controlled Alpha does not yet have a complete guardian/nominee/authorised-representative account model for every participant situation. NableU must resolve this before collecting children's information at scale.

A representative should not create an account by impersonating the represented person. NableU should provide an explicit representation/authority model so the system can preserve who acted, for whom, and under what authority.

19. Privacy complaints

If you believe NableU has mishandled your personal information, you may make a privacy complaint through the contact method in section 20.

NableU will:

Depending on the law and issue, external options may include the Office of the Australian Information Commissioner (OAIC) and/or the Information and Privacy Commission NSW (IPC). Nothing in this Notice removes any right to approach an external body directly where the law permits it.

20. Contact us about privacy

NableU Community Systems Incorporated NSW incorporated association: INC2601035

Privacy and complaints contact: hello@nableu.org Accessible contact methods: written/digital contact is accepted and reasonable adjustments may be requested. Telephone contact is not required.

If a physical service address is required for a particular legal process, request the current service details through the contact above or use the applicable statutory service process.

21. Changes to this Notice

We will keep this Notice current as NableU's actual information practices change.

Material changes should be versioned and communicated appropriately. A new Privacy Notice version may require acknowledgement, but acknowledgement is not a substitute for specific consent where the law requires consent for a new sensitive-information collection, secondary use or disclosure.

Previous effective versions should be retained so NableU can reconstruct what users were told at the relevant time.

22. Document control

Field Value
Version 2026-08-30
Effective date 30 August 2026
Intended role Central platform Privacy Notice / APP Privacy Policy
Collection notices Separate layered notices still required
Supersedes Technical-preview privacy notice dated 9 August 2026
Owner NableU Community Systems Incorporated
Publication authority Published by NableU for the controlled Alpha on 30 August 2026; broader-production legal review remains ongoing
Tracking GitHub issue #207

23. Legal/privacy references

NableU maintains this Notice against the current versions of, at minimum: