ASCA AI and Automated Systems Transparency Notice

This notice explains ASCA's public position on artificial intelligence, machine-assisted analysis, and automated systems. It applies when an ASCA product uses an automated system to classify, summarize, transform, generate, recommend, prioritize, route, or assist with a decision.

ASCA uses automation to reduce repetitive operational work and help people focus on leadership, creativity, safety, and community. Automation supports human responsibility; it does not erase the responsibilities of ASCA, an organization, an administrator, a moderator, a user, or another accountable party.

Scope and covered systems

Advanced Moderation and Automated Response (A.M.A.R.), Moderation And Conflict Resolution Operative (M.A.C.R.O.), and Chat To Voice Mod (C.T.V.M.) may use AI-assisted or automated processes in configured contexts. Other ASCA products may use bounded automation for search, fraud and abuse prevention, security, accessibility, support routing, record classification, recommendations, document handling, or operational assistance.

This notice applies to ASCA-operated product behavior. An independent organization, integration, platform, or service may operate its own automated systems under separate terms. Connection to ASCA does not make an external system an ASCA system or make ASCA responsible for every external result.

ASCA's public position

Automation has long been used to filter unwanted messages, identify fraud, route information, improve accessibility, and reduce repetitive work. New forms of artificial intelligence expand what software can analyze and produce, but they do not remove the need for defined purposes, accountable people, security controls, and meaningful review.

ASCA does not treat artificial intelligence as inherently trustworthy or inherently harmful. The relevant questions are what the system does, what information it receives, what authority it has, how uncertainty is handled, what consequences may follow, and who remains responsible.

ASCA's use of automated systems follows these principles:

1. Assist people. Automation exists to make a defined workflow more useful, timely, accessible, or safe.
2. Keep responsibility identifiable. Every consequential configuration and action remains connected to an accountable ASCA or organization role.
3. Limit purpose and access. A system receives only the information and authority permitted for the applicable workflow.
4. Expose material automation. Product information and notices identify material AI-assisted behavior without disclosing protected system design.
5. Design for uncertainty. Low confidence, incomplete inputs, conflicting context, unsupported formats, and service failures produce defined outcomes rather than silent certainty.
6. Preserve correction and review. Applicable products provide a route to report an error, review a result, or challenge an action.

Outputs are not policies or human judgments

An automated output may contain a classification, score, summary, generated response, recommendation, or proposed action. The output is not itself an Organization Policy, Moderation Decision, Human Review, legal conclusion, medical conclusion, employment decision, academic decision, or enforcement action.

ASCA may normalize, validate, combine, reject, or limit an output before it is used. Organization policy, configured thresholds, permissions, product rules, confidence treatment, prior state, human input, and other authorized context may affect the final result.

Where an organization enables an automated action, the resulting action is an execution of the configured workflow rather than a representation that an automated system possesses independent authority. The organization remains responsible for its policy and configuration except where a specific accepted agreement assigns responsibility differently. ASCA remains responsible for the platform duties it expressly undertakes.

Human involvement and accountable automation

Human involvement varies by product, configuration, risk, and plan. Some workflows provide a recommendation for a person to review. Some workflows may take a reversible action automatically under an organization's configured policy. Some security or abuse controls may restrict activity without advance review when immediate action is reasonably necessary to protect the service.

The presence of a human does not guarantee correctness, and the use of automation does not eliminate accountability. Administrators must configure systems within their authority, review material settings, maintain appropriate access, and respond to reports or appeals relevant to their organization.

ASCA may require additional confirmation, human approval, or a different workflow before an automated system is permitted to perform a high-impact or irreversible action.

Transparency and organization configuration

ASCA identifies material automated functions through product pages, documentation, configuration interfaces, notices, release information, or this policy. ASCA may protect confidential architecture, security methods, instructions, routing, thresholds, provider relationships, and other trade secrets that are not required for a user to understand the service.

An organization may configure available policies, sensitivity, thresholds, response modes, review paths, retention choices, and product participation within the limits offered by its plan and the platform. Not every automated function can be disabled independently. Security, fraud prevention, abuse prevention, service integrity, and legally required processing may remain active when necessary to provide or protect the service.

Product documentation identifies available controls. A setting presented as organization-controlled is not changed merely because ASCA changes an underlying technical implementation that preserves the selected behavior.

Information processed by automated systems

Depending on the enabled product and workflow, an automated system may process text, images, audio, video, links, metadata, files, extracted document text, conversation context, organization rules, account signals, transaction signals, security indicators, or authorized historical context.

ASCA applies access controls, validation, size and complexity limits, supported format rules, isolation, threat screening, and failure handling appropriate to the input and product. A file or external resource may be rejected, partially processed, or routed to review when it is unsupported, encrypted, suspicious, unavailable, incomplete, or over a limit.

Prompt-like text, embedded instructions, document metadata, markup, and other user-controlled content are treated as untrusted input. User content does not gain authority merely because an automated system can read it. ASCA may separate instructions from evidence, limit tools and network access, validate structured outputs, and refuse unsupported actions.

Privacy, service providers, and data use

Automated processing remains subject to the Privacy Policy, Data Retention, Export, and Deletion Policy, Security Policy, and Third-Party Services and Integrations Notice. Those documents govern applicable data categories, purposes, disclosures, retention, rights, and security responsibilities.

ASCA may use specialized service providers to supply infrastructure or processing. Provider selection and technical routing may change without changing the purpose of the product. ASCA applies contractual, configuration, access, and security controls appropriate to the supported workflow and does not disclose confidential provider flow where disclosure is not required.

ASCA does not sell organization member personal data. Customer content is not used to train a generally available ASCA model unless ASCA provides a separate, clear notice and obtains the authorization required for that use. Product improvement may use limited operational measures, feedback, security signals, and lawfully prepared data under the applicable privacy terms.

Accuracy, uncertainty, and service limitations

AI-assisted processing can be unavailable, inaccurate, incomplete, biased, uncertain, delayed, or affected by false positives and false negatives. An automated system may misunderstand context, humor, dialect, cultural meaning, images, extracted text, speaker intent, or events outside the supplied input.

ASCA does not promise perfect detection, prevention, translation, classification, generation, extraction, availability, or consistency. Identical or similar inputs may produce different results. A result that appears confident may still be incorrect.

Products may use confidence treatment, multiple stages, policy constraints, context windows, retries, review states, or fallback behavior. These measures reduce some risks but do not eliminate error. Users and organizations must not rely on an automated result as the sole basis for an unlawful, dangerous, or otherwise prohibited decision.

Fairness, accessibility, correction, and appeal

ASCA evaluates automated systems in relation to their intended purpose, available evidence, known limitations, and affected users. Reports of systematic error, discriminatory impact, inaccessible behavior, security weakness, or harmful misuse may lead to investigation, configuration changes, feature restrictions, or suspension.

Where a product records a moderation or comparable action, the applicable organization policy and product plan may provide notice, correction, appeal, or human review. Availability and timing depend on the product, configuration, record status, and governing terms.

A user may report an apparent error through the applicable product support or appeal route. A report must include enough information to locate and understand the result without disclosing passwords, complete payment credentials, access tokens, or unrelated private content.

Prohibited and restricted uses

Users and organizations must not use an ASCA automated system to:

• Violate the Acceptable Use Policy, law, or another person's rights.
• Create or facilitate malware, credential theft, unauthorized access, surveillance, fraud, harassment, exploitation, or evasion of safeguards.
• Make an academic grading, admissions, employment, housing, credit, insurance, healthcare, legal, or other high-impact determination unless ASCA expressly offers and authorizes that specific workflow under applicable terms.
• Represent an automated output as verified fact, professional advice, Human Review, or an official ASCA decision when it is not.
• Attempt to extract confidential instructions, system design, credentials, security controls, or information belonging to another user or organization.
• Circumvent limits, manipulate evaluation, poison context, conceal malicious content, or cause an automated system to act beyond the user's authority.
• Upload or process information that the user or organization lacks authority to collect, disclose, or use.

ASCA may restrict an input, output, feature, integration, account, or organization when necessary to address these risks.

Generated content and intellectual property

An automated system may produce text, images, summaries, classifications, or other material. ASCA does not guarantee that generated material is unique, accurate, non-infringing, or suitable for a particular purpose.

Users remain responsible for reviewing generated material before publication or operational use and for obtaining rights, permissions, attribution, and consents required for their use. A user must not request, publish, or use generated material in a manner that violates the Copyright and Intellectual Property Policy or another person's rights.

ASCA may label, restrict, remove, or preserve generated material when required for safety, support, rights management, security, or legal process.

Monitoring, incidents, and enforcement

ASCA may monitor operational measures, security events, abuse indicators, failure rates, appeals, and reported outcomes to operate and improve automated systems. Routine monitoring does not mean that ASCA reads every item of customer content or pre-approves every automated result.

Suspected compromise, harmful output, unauthorized action, or systematic error may result in containment, suspension, evidence preservation, configuration change, provider change, rollback, user notice, organization notice, or another response permitted by the governing terms.

Use of an automated system in violation of this notice may result in an output being blocked, feature restrictions, account or organization action, or termination. Enforcement remains subject to the applicable terms, records, and review process.

Package relationship and precedence

This document is one instrument in the Platform policy and transparency package. It must be read with the Terms of Service, Privacy Policy, Acceptable Use Policy, the applicable organization agreement or order, and any schedule expressly incorporated into that agreement. A product page, help article, sales statement, roadmap, or technical description does not amend this document.

If two documents appear to conflict, the more specific accepted document controls only for its stated subject and audience. A signed or otherwise verified negotiated instrument controls over standard online terms within its express scope. Mandatory law continues to apply. Technical access, possession of a credential, or use of a feature does not by itself create authority, a service commitment, or an acceptance event.

Acceptance and authority

The contemplated acceptance method is notice-only. Access to a dashboard, possession of a credential, technical administrator status, or use of a feature does not by itself prove authority to bind another person or organization. ASCA may require evidence of identity, role, delegation, ownership, or approval before allowing a person to accept, configure, transfer, export, or terminate a governed relationship.

Each actor must stay within the authority granted by the applicable organization and service. For this package, relevant actors may include users, organizations, authorized administrators, affected participants, and ASCA. A configuration cannot transfer a legal duty that the applicable law or an accepted agreement assigns elsewhere.

Records, privacy, and security

ASCA may maintain version, acceptance, configuration, authorization, notice, support, security, billing, and transition records needed to administer this document and establish what occurred. Those records remain subject to the applicable privacy, security, retention, legal-preservation, and access-control rules. An organization must not use an ASCA feature to obtain information it is not authorized to collect, disclose, or use.

Users must protect credentials, use the least access reasonably needed, review delegated access, and promptly report suspected compromise or misuse. Public legal text describes user-facing responsibilities and safeguards without publishing confidential processing architecture, security controls, abuse-detection methods, or other protected system design.

Changes, suspension, and transition

ASCA may change a feature, integration, limit, or security control when needed to operate, secure, or improve the service. A change that materially alters an accepted legal commitment requires the notice, review, and reacceptance process applicable to that commitment. Routine technical changes that preserve the documented purpose do not create a new contract by themselves.

Access may be restricted to address security risk, abuse, legal process, nonpayment where applicable, loss of authority, or material breach. Suspension does not decide ownership, erase records, waive payment, or cancel export, preservation, incident, or transition duties. Termination and offboarding must follow the applicable package documents and recorded organization authority.

Governing law and disputes

This document and any dispute arising from or relating to it are governed by the laws of Singapore, without regard to conflict-of-law principles. Subject to mandatory law and any expressly accepted dispute procedure, the courts of Singapore have exclusive jurisdiction.

These standard online terms do not require arbitration unless a separately signed agreement expressly provides otherwise. Nothing in this document excludes a right or remedy that applicable law does not permit the parties to exclude.