Skip to content

scientific(split): admit newly available rolling-origin evaluation partitions #685

Open

Description

@seonghobae

Finding

#680 now has the frozen-coordinate/fitted-state prerequisites (#681/#683) and #684 adds a fixed-training predictive numerical primitive, but there is still no owner-issued corpus-split contract that binds one canonical rolling-origin window to the exact training/evaluation snapshot horizons and refuses future-evidence leakage before model selection consumes those rows.

corpus_split::rolling_origin_windows(...) owns ordered cutoff pairs, CorpusSnapshot owns one bound KnowledgeCutoff plus admitted documents' AvailableTime, and build_connected_groups / assert_no_group_leakage own governed co-partitioning. These contracts were separate.

A first source repair incorrectly treated absence from the training snapshot as proof that an evaluation row was newly available. That is not scientifically valid because a snapshot need not be a complete enumeration of every document already available by its cutoff. The admission contract must instead inspect the evaluation document's retained AvailableTime and require it to be strictly later than the training cutoff. The omitted-but-already-available fixture is therefore part of the causal acceptance contract.

Required RED / repair

Keep the narrow owner contract in corpus_split, not a second splitter in model_selection:

  • derive the selected window through canonical rolling_origin_windows(...) from strictly ordered cutoffs;
  • require the training snapshot to be bound to that window's train_cutoff and the evaluation snapshot to its test_cutoff;
  • require nonempty, duplicate-free train/evaluation identity sets with no identity in both partitions;
  • require every training identity to exist in the training snapshot and every evaluation identity to exist in the evaluation snapshot;
  • require every evaluation document's retained AvailableTime to be strictly after the train cutoff; absence from the train snapshot is insufficient evidence of future availability;
  • build governed connected groups over the admitted identity universe and reuse assert_no_group_leakage so revisions/translations/copied variants/shared episodes/canonical-equivalent records cannot straddle train/evaluation;
  • return an immutable admitted partition exposing the canonical window and sorted training/evaluation identities;
  • fail closed on wrong window index, cutoff mismatch, unavailable identity, duplicate/overlap, non-future evaluation AvailableTime, or cross-partition governed leakage.

Boundary

This is availability/split integrity only. It does not authenticate Evidence source/event-time semantics (#527/#658/#671), promote relations (#675), own Membership projection (#605), or claim that transition edges themselves must co-partition. It also does not complete #680: #684's fixed-training predictive score still needs to be wired across admitted windows and exercised in realistic true-K temporal/relational recovery with deliberate leak rejection/audit evidence.

Refs #638 #639 #672 #680 #681 #683 #684.

Activity

  1. seonghobae commented on Sep 22, 2026

    @seonghobae
    ContributorAuthor

    Ordinary-forward source repair is now on Draft #639.

    Lineage:

    • runtime-contract/API RED ea0158e89b8d3027ed5118bd36cb1874b4673730 adds only rolling_origin_partition_contract.rs against predecessor 87e5378f...;
    • production owner 4015248f42b7eec44d5f24cda73a4022e9b782f3 adds RollingOriginPartition / admit_rolling_origin_partition(...) inside corpus_split, deriving the selected window from canonical rolling_origin_windows, requiring exact bound train/test snapshot cutoffs, newly available evaluation identities, and existing connected-group leakage checks;
    • public owner export ac8ac1fc9f37f1b42ebe1855941ff0fc271fd8df;
    • edge hardening d03e02d323f29744766d55d2fc410bada7d26200 covers old-at-train evaluation rows, cross-partition governed leakage, unavailable train/evaluation identities, empty/duplicate/overlap identities, bad window index, and train/evaluation horizon mismatch;
    • CHANGELOG/current head 20e0227f051aca92da686f5ecdccbb78f8f84def records the availability/split-integrity boundary.

    This owner does not authenticate Evidence/event-time truth, Membership provenance, relation promotion, or force transition edges to co-partition. It also does not complete #680: #684 still has to be wired across admitted windows and validated under realistic true-K temporal/relational/multilevel recovery.

    The RED is source-level evidence; exact current-head hosted gates are non-terminal, so no hosted GREEN or closure is claimed.

  2. seonghobae commented on Sep 22, 2026

    @seonghobae
    ContributorAuthor

    Correction to the earlier #685 handoff: 20e0227f... was not scientifically sufficient. It used absence from the train snapshot as the proxy for future availability, but a snapshot can omit a document that was already available by the train cutoff.

    A second causal RED/fix now repairs that gap:

    • RED 7782ac4d369d9f3b9c53d2ff73955592597f8f4d adds an evaluation-only row whose retained AvailableTime is day 1 even though it was deliberately omitted from the day-10 train snapshot; the prior implementation incorrectly admitted it as future evidence;
    • 07540514990406b21b94f92c3dc0f61e3ca4eb9e adds read-only CorpusSnapshot::available_time(...), preserving admitted availability evidence without exposing mutable snapshot state;
    • causal repair bacdc05c5d2c397dd8ce1486e5e0074925ab5ee7 now requires every evaluation document's retained AvailableTime to be strictly later than the canonical train cutoff;
    • corrected CHANGELOG/current head c561ed5d90ae419207372d0614a0a063a60f6c12 explicitly states that snapshot absence is never proof of future availability.

    The issue body has been currentized to this stronger contract. Previous 20e0227f... should be treated as an intermediate incomplete repair, not acceptance evidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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