ASCA Event Services Supplement

This document supplements the applicable ASCA Core terms for an Organization that uses event capabilities, centered on Event Management and Membership Authentication (E.M.M.A.). It applies only after an applicable Organization agreement, order, or approved enrollment identifies the Event scope. It does not itself grant services, set pricing, or become effective.

Event configuration and operations

An identified Event Organizer may configure Events, Sub-Events, registration windows, eligibility, forms, capacity, waitlists, credentials, check-in, communications, vendor workflows, integrations, and closure only within its documented authority. The Organizer remains responsible for its event operations, rules, admission decisions, staffing, supervision, venue arrangements, safety planning, emergency response, insurance, and legal obligations unless a separate written agreement assigns a particular responsibility to ASCA.

ASCA may provide software, infrastructure, records, communications, and integrations. Platform use does not make ASCA the Event Organizer, Venue, promoter, security provider, medical provider, insurer, ticket reseller, merchant of record, employer, transportation provider, or physical custodian.

Event hierarchy and configuration limits

Each Parent Event and Sub-Event MUST identify its Organizer, scope, status, eligibility, capacity, credential conditions, payment/refund treatment, applicable rules, and required supplemental acknowledgments. A Parent Event registration, payment, consent, or credential does not automatically authorize a person for a Sub-Event. Organizer-configured rules cannot override mandatory platform restrictions, applicable law, or a higher-authority accepted document.

Records and transition

Registration, attendance, credential, waiver, payment, incident, equipment, and communication records are handled under the applicable Event schedules and data terms. Deactivation, cancellation, organizer change, and archival follow DOC-EVT-014. Retention, deletion, export, security, and legal-preservation duties follow the applicable retention schedule, accepted terms, and law.

Package relationship and precedence

This document is one instrument in the Events and participation 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 organization-agreement-or-incorporated-order-acceptance. 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 organizers, venues, vendors, sponsors, participants, contributors, 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.