Skip to content

scientific(membership): classify longitudinal observation support without atomistic collapse #640

Open

Description

@seonghobae

Scientific / DDD finding

membership_core::classify_membership_design currently classifies one shared EventTime. Topic-lineage and other longitudinal consumers instead evaluate each modeled observation at its own event time. Re-running the single-instant classifier inside those consumers would duplicate Membership-domain truth; collapsing the observation set to one synthetic instant would be scientifically wrong.

The owner contract must classify a set of (MemberId, EventTime) observation coordinates directly from MembershipNetwork, preserving the same closed design vocabulary already owned by Membership: Nested, CrossClassified, MultipleMembership, CrossClassifiedMultipleMembership, HeterogeneousClassification, and HeterogeneousClassificationMultipleMembership.

This is needed by release issue #638 / Draft #639, but the implementation belongs here in the Membership bounded context. #639 must consume a released/pinned owner contract or an ordinary protected-main landing; it must not copy this classifier.

Required RED

Add owner-side contract tests proving that observation support is classified across the actual event time of each observation:

  1. one member may leave/re-enter or change contextual assignments over time without the consumer selecting one global as_of instant;
  2. locally single-classified observations that span different roles across the observation support are HeterogeneousClassification, not Nested;
  3. a local cross-classified observation plus a separate local multiple-membership observation yields CrossClassifiedMultipleMembership;
  4. a partial-weight/same-role multi-group observation remains MultipleMembership even when other observations are nested;
  5. any requested observation with no active membership at its own event time fails closed rather than disappearing from the support;
  6. an empty observation support fails closed.

The API should use opaque MemberId + EventTime coordinates only. Do not add HR/person truth, caller-asserted design labels, normalization, pseudo-row duplication, or estimator arithmetic.

Acceptance

Protected base at finding time: main@a243f18da4a4ca8a8d068c39922537f1f8ed6ad0. Canonical Membership owner PR at finding time: #605 c7defa251761f104e51a614cbba14f9f952bec58.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions