# 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: - account information is not automatically public profile information; - participant information is shared according to the relationship, audience and permission shown in NableU; - Support Coordinators receive only the participant-authorised scopes that are actually granted; - workers and organisations control their own identity/profile information subject to information they must provide truthfully; - private reflections and restricted records stay private unless a separate permission or lawful basis allows another use; - stored information is never used as AI context, AI memory or model-training data unless you have explicitly opted in to the relevant AI feature or setting; - optional product marketing is separate from service messages; - NableU does not sell personal information; and - you may ask about, access or correct information we hold about you, subject to lawful exceptions. ## 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: - a public website or expression-of-interest form using a distinct data store; - a physical NableHood event or site; - employment or volunteering; - a research project; - a grant-funded program with special data requirements; or - a third-party service you choose to connect. 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: - name and preferred/display name; - email address; - mobile number; - account role(s) and persona/context choices; - authentication and account-verification state; - password verification data rather than a readable copy of your password; - passkey/recovery/security records; - session/device information such as a browser or device description; - privacy-notice acknowledgement, Terms acceptance and optional product-update choices, including version and time; and - security metadata such as a protected representation of network/session information used to detect or investigate unauthorised access. ### 3.2 Participant information Depending on the features you choose, this may include: - broad locality or area; - communication preferences; - profile photo; - interests, hobbies and activities; - types of support wanted; - support preferences and preferred worker approach; - access needs and practical requirements; - support goals, tasks or coordination plans; - support needs/jobs and applications or invitations; - participant-worker relationships; - Service Agreements, pricing disclosures and support-session records; - availability/schedule information; - plan-manager or Support Coordinator contact details; - Support Coordinator sharing/grant settings; - My Manual information; - private reflections or notes where a feature is explicitly private; - safeguarding preferences or needs; - messages and conversation records; - community/group content and audience choices; - support cases, complaints, reports or incident-related information; and - documents or media you choose to upload. 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: - public/display identity and photo; - locality/service area; - introduction and work history; - support capabilities and style; - interests and activities; - availability and travel/transport information; - rates/pricing context and direct-work preference; - organisation affiliations and work pathways; - qualifications, training and professional evidence; - NDIS Worker Screening, Working With Children, police, first-aid, CPR or similar evidence/status information; - licence, transport, insurance or other role-relevant evidence; - languages; - worker-supplied cultural, religious/spiritual, inclusion or immunisation information where the product permits it; and - participant relationships, agreements, sessions, messages and related activity. 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: - professional profile/contact information; - service area and experience/capabilities; - organisation/business affiliation; - professional evidence or review state; and - participant relationships and the exact participant-granted access scopes applicable to those relationships. 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: - legal and trading/display name; - ABN where relevant; - organisation type and contact details; - service areas and descriptions; - owner/admin and other scoped roles; - worker memberships/affiliations; - services and participant-facing pricing; - worker remuneration or commercial disclosure records according to the relevant audience; and - agreement, invoice/accounting and external payment-status records as these features are enabled. 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: - direct messages and conversation metadata; - Meet & Greet and support-session proposals/acceptances; - community posts, replies, group content and audience choices; - private drafts; - documents, images or other uploaded content; and - notifications and delivery state. 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: - actor and acting capacity; - action and affected resource; - time, request/correlation identifiers and application/policy version; - authority or permission used; - result/reason code; and - changed-field metadata where appropriate. 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: - the text you typed for that request; and - limited interface-orientation context such as an allow-listed page/module/path indicator. 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: - from another NableU user who invites or connects with you; - from a participant, worker, Support Coordinator or organisation in a relationship involving you; - from an authorised representative acting lawfully for another person; - from an organisation administrator acting within their actual authority; - from external services you deliberately connect; - from an authoritative register/source where NableU actually performs a stated verification; or - automatically from platform/security operation, for example session or audit metadata. 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: - creating, securing and recovering accounts; - verifying contact details and preventing duplicate or fraudulent accounts; - building the profile and preferences you choose to use; - participant-controlled worker discovery and matching; - invitations, applications and relationship formation; - messaging and collaboration; - Meet & Greet, Service Agreement and support-session workflows; - participant-controlled Support Coordinator collaboration; - organisation identity, roles, pricing and authorised administration; - activity/evidence/provenance records; - community/group participation for the selected audience; - notifications and transactional communications; - support, complaints and safety response; - preventing, detecting and investigating security abuse or unauthorised access; - meeting legal, regulatory, governance, insurance and record-keeping obligations; - maintaining backups, reliability and service continuity; - improving accessibility, usability and platform reliability using minimised data; and - providing optional AI/reasoning assistance when the user invokes it under the applicable context boundary. 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: - a discoverable worker profile shown to participants; - a participant's relevant support need shown to eligible workers; - information in a bilateral conversation or Service Agreement; - a Support Coordinator's participant-authorised workspace scope; - organisation information shown to an authorised worker/manager; or - community/group content shown to the audience selected for the post. 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: - infrastructure/hosting/database and backup services; - Microsoft Graph or another configured email-delivery service; - web-push delivery infrastructure; - security/operational services; and - the configured AI/reasoning provider when a user invokes a feature that uses it. 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: - authenticated and server-authorised access boundaries; - scoped relationship and organisation permissions; - encryption/protection for selected sensitive identifiers; - one-way password verification data rather than readable passwords; - protected session/security metadata; - secure transport and browser security controls in remote environments; - restricted public diagnostic information; - origin/provenance checks for browser writes; - privacy-minimised audit/provenance records; - controlled backups and deployment checks; and - separation between stored user data and AI context authority. 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: - a record another user is independently entitled or required to retain; - a bilateral agreement or support-session record; - a security/fraud event; - a complaint, incident or legal-hold record; - financial/accounting evidence; or - health information subject to a statutory minimum retention period. 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: - accept complaints in accessible forms and make reasonable adjustments where needed; - identify the issue and relevant records; - investigate with appropriate independence from a conflicted decision-maker; - explain the outcome and any remediation; and - tell you about relevant external review options where applicable. 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: - Privacy Act 1988 (Cth) and Australian Privacy Principles; - OAIC Australian Privacy Principles Guidelines, including APP 1, APP 3, APP 5, APP 8, APP 11, APP 12 and APP 13; - Privacy and Other Legislation Amendment Act 2024 (Cth), including APP automated-decision transparency amendments commencing 10 December 2026; - Health Records and Information Privacy Act 2002 (NSW) and current IPC NSW Health Privacy Principle guidance where applicable; - Notifiable Data Breaches scheme requirements; and - any NDIS privacy/information-management obligations that become applicable to NableU's actual registration/service status.