Challenge on Adaptive and Reliable Open-World Social Dynamics Discovery

1. November 8, 2026

   Final submission deadline

   Teams submit their final solutions by this date.

2. November 9, 2026

   Results announcement

   Winning teams are announced.

Deadlines fall at 21:00 in the Anywhere on Earth (AoE) time zone.

Register Your Team

Enter the Challenge on Adaptive and Reliable Open-World Social Dynamics Discovery as a team with one captain and up to five additional members.

To register, complete the form with accurate details, including your team ID and name, contact email, affiliations, countries, and other required information.

News: Registration and submissions remain open until the extended deadline: November 8, 2026, at 21:00 AoE. Teams may continue submitting under the existing daily limit.

General Participation Rules

These rules apply to both Task 1 and Task 2, together with the task-specific evaluation and submission requirements.

Teams and Registration

Each team may have 1–6 members, including one captain. Each participant may enter both Task 1 and Task 2, but may belong to only one team per task. Participants may join different teams for the two tasks. Each distinct team must register separately. A team may participate in either or both tasks, with a separate submission for each task.

Each team ID and registration email can belong to only one team. Team IDs are unique regardless of letter case. Different teams must register with different IDs and emails.

Use your team ID, captain’s registration email and password for submissions. A team entering both tasks uses the same credentials, with separate submission records and daily allowances for each task.

Public Data and Pretrained Models

Publicly accessible external datasets and pretrained models are allowed, provided they are available to all participants under the same conditions. Private datasets and non-public pretrained models are not allowed. Teams may train or fine-tune their own models using permitted data and models.

Declare all external datasets and pretrained models in source_code/README.md with the final submission, including their sources, versions and roles in the method. Closed-source paid APIs are not allowed in the competition solution pipeline, including data generation, training and inference.

Test Data and Fair Evaluation

Do not obtain or use hidden test labels, manually annotate test answers, or manually modify predicted results. All submitted predictions must be generated by the submitted program.

Reproducibility

Provide source code with the final submission on November 8 (AoE), including source_code/eval.py. Include dependency instructions, run commands, access to required model weights, and random seeds where applicable, so that the organizers can reproduce the results. Public release of every team's code is not required by these rules.

Submission Frequency and Leaderboard Updates

Each team may submit at most once per task per AoE calendar day, measured in AoE (00:00–23:59). The daily limit applies to the team, identified by its registered team_id and captain’s email address.

Starting October 25, 2026 (AoE), the leaderboards are updated once daily, at 00:00 AoE. Each update includes submissions received before 21:00 AoE on the previous day, allowing three hours for evaluation. Each team's ranking uses its most recent valid submission received before that update’s cutoff. Valid zero scores are ranked normally. All teams that have submitted to a task before the cutoff are listed. Teams without a valid score appear after ranked teams, with their latest submission marked as invalid, pending evaluation, or pending review; no numerical score or rank is assigned. If a newer submission is invalid or awaiting evaluation, the most recent valid score is retained.

Submission Deadline

Registration and final submissions close on November 8, 2026, at 21:00 AoE. The submission portal closes automatically at the deadline. The final assessment is based on the most recent valid submission received before the deadline.

Upload ZIP archives directly through the task submission portals (maximum 50 MB per archive).

Introduction

Trending events attract many users to discussions and information sharing, giving rise to different social groups. These groups often lack explicit membership lists: a user may belong to multiple groups, and a group may participate in multiple events. Discovering them requires adaptability across contexts and reliable identification of group boundaries.

Given user attributes, content features, and interaction records, participants predict the number of social groups and the members of each group in single-event and multi-event scenarios, with group counts unknown in advance. In multi-event scenarios, the same group appearing across events should be identified and merged to avoid duplicate counting.

Dataset

The dataset is provided as Dataset.zip, with separate train and test folders. It includes both single-event and multi-event packages:

• Training set — 5 packages: three single-event packages, one two-event package and one three-event package.
• Test set — 3 packages: a mix of single-event and multi-event packages.

Dataset.zip
├── train/
│   ├── single_event_01/
│   ├── single_event_02/
│   ├── single_event_03/
│   ├── two_events_01/
│   └── three_events_01/
└── test/
    ├── package_01/
    ├── package_02/
    └── package_03/

Each package contains user attributes, content features and interaction records.

Every package contains the following seven data files:

• users.pt — User identifiers and account attributes, including follower and following counts.
• user_name.pt — Display-name features, paired with user identifiers.
• user_description.pt — Biography features, paired with user identifiers.
• user_avatar.pt — Avatar features, paired with user identifiers.
• posts.pt — Identifiers, authors, publication times and references for posts, comments and replies.
• post_text.pt — Text features for posts, comments and replies, paired with their content identifiers.
• interactions.pt — Publishing, commenting, liking, reposting and replying records, including the users involved, interaction targets and interaction types.

Embedding Encoder. The provided display-name, biography, avatar and post-text embeddings in user_name.pt, user_description.pt, user_avatar.pt and post_text.pt are generated using Qwen3-VL-Embedding-2B. Each embedding is a 2,048-dimensional feature vector.

Training only: labels.pt provides the ground-truth group count and member lists for each training package. Only groups with eligible_for_scoring=true count toward the target; OTHER groups and groups with fewer than five members are excluded. See the dataset README for label fields and a filtering example. This file is not included in test packages.

Metric

Evaluation uses two components:

• Group Count Score: calculated as max(0, 1 − |true count − predicted count| / true count). If the true count is zero, the score is 1 if the predicted count is also zero, and 0 otherwise.
• Group Membership Match: the average member-set IoU under optimal one-to-one group matching. Matching maximizes the total IoU over as many pairs as the smaller group count, including zero-overlap pairs. Missing true members or including unrelated members lowers IoU. If both group counts are zero, the membership score is 1; if only one is zero, it is 0.

Example: With 10 ground-truth groups, predicting 8 or 12 groups gives a Group Count Score of 0.8; predicting 10 gives 1.0.

The Group Discovery Score is the product of these two components. The final score is the arithmetic mean of the Group Discovery Scores across all test packages, multiplied by 100. Each package contributes equally to the final score. Empty predictions score 0 for packages containing ground-truth groups.

Higher scores are better.

Submission Rules

The General Participation Rules apply to this task.

Prepare Your Archive

Name your archive {team_id}.zip, keeping the capitalization of your registered team ID.

Before November 8, 2026 (AoE), upload {team_id}.zip containing only results.json. On November 8 (AoE), submit your final archive before November 8 at 21:00 AoE with results.json and source_code/, including eval.py.

Prediction Schema

results.json contains a JSON array with one entry per test package. The example below shows one entry; please include results for all three test packages in the full submission.

[
  {
    "sample_id": "package_01",
    "group_count": 2,
    "groups": [
      {"group_id": "G1", "members": ["U01", "U02", "U03", "U04", "U05"]},
      {"group_id": "G2", "members": ["U04", "U05", "U06", "U07", "U08"]}
    ]
  }
]

sample_id identifies the test package. group_count should match the number of entries in groups. Each group has a unique group_id within the package and a members list of at least five distinct user identifiers from that package’s users.pt.

Different groups may share users, and users may remain unassigned. Do not repeat identical member sets. Merge the same group across events, using the union of its members within the package. If none is found, use group_count=0 and groups=[].

Upload and Confirmation

1. Prepare {team_id}.zip using the regular or final submission format above, according to the submission date (AoE).
2. Open this task’s submission portal and verify your team using the team ID, captain’s registration email and password.
3. Select and upload {team_id}.zip directly. The maximum archive size is 50 MB. For large model weights, provide access instructions in the README. Complete the upload before the deadline and download the submission receipt.
4. To update your results before the deadline, submit a new ZIP through the portal, within the daily submission limit. Each accepted archive is stored separately. The server timestamp after the complete archive is received and recorded determines the submission time.

A submission receipt confirms that the archive was stored successfully; it does not confirm that the contents meet the task requirements or have been scored. Failed or incomplete uploads do not use the daily quota. An archive received successfully uses the quota even if it later fails evaluation. Retain the receipt for your records.

Predictions will be scored using the published metrics. Potential award-winning submissions will undergo code and reproducibility verification before results are confirmed.

Acceptance requires compliance with all competition rules.

Introduction

Emerging events generate diverse discussions, where similar wording may describe different events and some events receive only limited attention. Discovering these events requires generalization beyond familiar examples and reliable separation of events from background content.

Given a collection of social media posts, participants discover events, estimate the number of events, and assign each event one of five predefined types. Each post is assigned to an event or identified as non-event content. Test events are unseen during training, requiring models to recognize new events from both extensive and sparse discussions.

Dataset

The dataset is provided as Dataset.zip, with separate train and test folders. Both sets contain posts from multiple events mixed with non-event posts. The entire test set is evaluated together.

Dataset.zip
├── train/
│   ├── posts.pt
│   └── labels.pt
└── test/
    └── posts.pt

There are five event types, represented by integer labels 1–5, with the same label mapping across training and test sets. Posts that do not describe or clearly refer to a specific event are marked NON_EVENT with event_type=0. They do not count as events; 0 is not a sixth event type.

Post Data

posts.pt is a PyTorch-serialized post data file. Each record represents one post and contains the following fields:

• post_id — A globally unique anonymous post identifier.
• author_id — An anonymous author identifier, consistent for the same user.
• text — The 2,048-dimensional post-text embedding generated using Qwen3-VL-Embedding-2B.
• created_at — The publication time in ISO 8601 format, using UTC.
• like_count — The number of likes.
• comment_count — The number of comments or replies.
• repost_count — The number of reposts.

Training Labels

Training only: labels.pt provides the following fields and is not included in the test set:

• post_id — The identifier of the corresponding post.
• event_id — The event identifier within the training set, or NON_EVENT for non-event posts.
• event_type — An integer from 1 to 5 for an event, or 0 for non-event posts.

Posts belonging to the same event share the same event identifier and type. Each post belongs to exactly one event or NON_EVENT. Event identifiers do not need to correspond across training and test sets.

Metric

Evaluation uses three components across the entire test set:

• Event Count Score: calculated as max(0, 1 − |true count − predicted count| / true count). If the true count is zero, the score is 1 if the predicted count is also zero, and 0 otherwise.
• Event Membership Match: the average post-set IoU under optimal one-to-one event matching. Matching maximizes the total IoU over as many pairs as the smaller event count, including zero-overlap pairs. Missing true posts or including unrelated posts lowers IoU. If both event counts are zero, the membership score is 1; if only one is zero, it is 0.
• Type Classification Accuracy (Acc): the proportion of matched event pairs with positive IoU that have the correct event type label. If no matched pair has positive IoU, Acc is 0. Matching is based on post-set IoU, not event type labels.

Example: With 10 ground-truth events, predicting 8 or 12 events gives an Event Count Score of 0.8. If the average matched IoU is 0.75, the Event Discovery Score is 60. If 6 of 8 positive-overlap matched pairs have the correct type, Acc is 75%.

NON_EVENT is excluded from event counts, matching and type accuracy. Assigning non-event posts to an event can lower its IoU.

The Event Discovery Score is the Event Count Score multiplied by the Event Membership Match, then multiplied by 100. Ranking uses this score, with Type Classification Accuracy (reported as a percentage) as the tie-breaker. Higher scores are better.

Submission Rules

The General Participation Rules apply to this task.

Prepare Your Archive

Name your archive {team_id}.zip, keeping the capitalization of your registered team ID.

Before November 8, 2026 (AoE), upload {team_id}.zip containing only results.json. On November 8 (AoE), submit your final archive before November 8 at 21:00 AoE with results.json and source_code/, including eval.py.

Prediction Schema

results.json contains a single JSON object with the predictions for the entire test set:

{
  "event_count": 2,
  "events": [
    {
      "event_id": "E1",
      "event_type": 1,
      "members": [
        "P001",
        "P002"
      ]
    },
    {
      "event_id": "E2",
      "event_type": 3,
      "members": [
        "P003",
        "P004"
      ]
    }
  ],
  "non_event": {
    "event_id": "NON_EVENT",
    "event_type": 0,
    "members": [
      "P005"
    ]
  }
}

• Events: List the detected events in events. Set event_count to the length of this list; non-event posts do not count as an event.
• Each event: Provide an event_id unique within the test set, an integer event_type from 1 to 5, and a non-empty members list of post IDs. You may choose your own event IDs.
• Non-event posts: List their IDs in non_event.members, with event_id="NON_EVENT" and event_type=0. Use an empty members list if there are none.
• Post assignment: Place every post from the test set in exactly one list: an event's members or non_event.members.

If no events are detected, use event_count=0 and events=[], and place all post IDs in non_event.members.

Upload and Confirmation

1. Prepare {team_id}.zip using the regular or final submission format above, according to the submission date (AoE).
2. Open this task’s submission portal and verify your team using the team ID, captain’s registration email and password.
3. Select and upload {team_id}.zip directly. The maximum archive size is 50 MB. For large model weights, provide access instructions in the README. Complete the upload before the deadline and download the submission receipt.
4. To update your results before the deadline, submit a new ZIP through the portal, within the daily submission limit. Each accepted archive is stored separately. The server timestamp after the complete archive is received and recorded determines the submission time.

A submission receipt confirms that the archive was stored successfully; it does not confirm that the contents meet the task requirements or have been scored. Failed or incomplete uploads do not use the daily quota. An archive received successfully uses the quota even if it later fails evaluation. Retain the receipt for your records.

Predictions will be scored using the published metrics. Potential award-winning submissions will undergo code and reproducibility verification before results are confirmed.

Acceptance requires compliance with all competition rules.

A champion award will be presented to the top-performing team in each task.

For the update schedule and ranking policy, see the General Participation Rules.