TimeNet: An Extensible Unified Data Infrastructure for Next-Generation Temporal Foundation Models

1 Introduction

• Existing TSFMs often specialize in particular tasks or domains, while real-world temporal systems can be multimodal, asynchronous, event-driven, and multi-scale.The introduction argues that modeling such systems may require state inference, event explanation, forecasting, and reasoning about interventions.Source: §1 · p. 2
• Datasets commonly use separate, ad-hoc formats and pipelines, and new tasks often repackage the same recordings rather than extend a shared representation.PTB-XL ECG recordings were separately repurposed for classification, question answering, clinical reasoning, and instruction tuning.Source: §1 · pp. 2–3
• TimeNet separates temporal recordings from task definitions and provides an extensible standard, open software infrastructure, and a framework for training and benchmarking across datasets.The shared representation supports multiple task types, while the software provides tools for cataloging, processing, versioning, splitting, and loading datasets.Source: Figure 1 · p. 2, §1 · p. 3

2 Related Work

• Time-series resources range from task-specific benchmarks to heterogeneous pretraining corpora, while evaluation has expanded to reasoning, retrieval, generation, and editing.The passage cites UCR/UEA, Monash, and TSB-UAD [Bagnall et al., 2018], and Time Series Pile, LOTSA, and Time-MMD.Source: §2 · p. 3
• Complementary efforts standardize software interfaces, dataset formats, or observational data, and UTSD and LOTSA harmonize numerical data for pretraining.TimeCopilot provides a unified API across TSFMs but still depends on upstream datasets in compatible formats [Garza & Rosillo, 2025].Source: §2 · p. 3
• AtriumDB unifies clinical waveforms and supports rapid retrieval, but is limited to one data type and clinical environment and lacks first-class tasks and text supervision.It also cannot publish heterogeneous datasets as versioned, shareable entries.Source: §2 · p. 3

3 Methods

• TimeNet uses a common data model and interface to connect dataset ingestion, task definition, and loading, reducing integrations from up to N×M dataset-consumer pairs to N connectors plus M shared-interface integrations.Connectors standardize source datasets, task definitions can be extended without changing the underlying representation, and the loading layer selects and collates data into model-specific inputs.Source: §3 · p. 4

3.1 Data Representation

• TimeF represents datasets as Records with recursive Sources and Signals; Signals support regular, irregular, or ordinal axes, and annotations can be reused across objects.Its object hierarchy maps to a storage model with DuckDB-managed relational metadata and separately stored Signal values.Source: §3.1 · pp. 5–6
• TimeNet tasks reference Records and encode targets inline or through annotation occurrences, allowing the same recordings to support multiple forms of supervision without repackaging Signals.The defined task types include classification, question answering, scalar prediction, temporal localization, forecasting, generation, editing, and correspondence.Source: §3.1 · p. 6
• The registry ingests datasets through connectors and can publish immutable, versioned entries; it currently contains 1.51M task instances.The listed instances include 899k question answering, 484k classification, 131k generation, 441 temporal localization, and 292 scalar prediction.Source: §3.1 · p. 6

3.2 Formal Specification of Temporal Tasks

• Temporal tasks are specified by target kind, target position relative to observed input, and the number of temporal objects involved, whose combinations form six constructions grouped into five semantic families.For example, a Value target within recorded support gives attribute inference, while a Span target gives temporal localization; a future target yields future-directed inference.Source: §3.2 · pp. 6–7, Table 1 · p. 7
• Task signatures distinguish broad semantic families from specializations, while tasks can vary in presentation, rationale requirements, and offline or streaming evaluation.The task taxonomy can be extended with additional constraints without changing the underlying data schema.Source: §3.2 · pp. 7–8

3.3 Data collation

• For each batch, TimeNet resolves referenced records, signals, annotations, temporal scopes, and targets, then applies model-specific collation to produce model inputs and targets.Collation may include windowing, padding, resampling, channel selection, or conversion into tensors, and can be reused across datasets and task types.Source: §3.3 · p. 8

4 Experiments

• TimeNet’s common mapping from tasks to prompts supports training data collation.The experiments assess pooled training and I/O access through a common representation.Source: §4 · p. 8, Figure 5 · p. 9

4.1 Multi-dataset Training

• OpenTSLM’s average F1 rises from 29.16 to 33.28 with pooled training across four datasets.Pooled training increases F1 on each dataset; Table 2 compares individual and joint training.Source: Table 2 · p. 9, §4.1 · p. 9
• SLIP’s ECG-QA F1 falls from 33.93 to 30.00 with pooled training, despite gains on Sleep-EDF and HEARTS.Its ECG-QA accuracy also falls from 40.01 to 31.32; accuracy rises on ARFBench.Source: §4.1 · p. 9

4.2 I/O Performance Across Heterogeneous Datasets

• TimeNet’s I/O performance remains comparable to native formats, though it is not strictly faster.The comparison covers six datasets and notes that native formats can use highly optimized, data-specific, memory-mapped encodings.Source: Table 3 · p. 10, §4.2 · p. 10

• Across six datasets and more than 1.5 million task instances, TimeNet supports access and model-specific collation without dataset-specific loading pipelines.The shared representation maintains practical I/O performance relative to native formats.Source: §5 · p. 10
• Pooled OpenTSLM training raises F1 on all four evaluated datasets, while SLIP improves on Sleep-EDF and HEARTS but decreases on ECG-QA.The authors suggest SLIP’s smaller 400M-parameter size, compared with OpenTSLM’s 1B parameters, might explain its ECG-QA drop.Source: §5 · p. 10
• The authors advocate shared registries where recordings are stored once and new annotations and tasks are added without duplicating or restructuring the original data.They report having begun combining heterogeneous data into a public registry.Source: §5 · p. 10
• The evaluation covers selected models and tasks, six datasets for access, four for training, and QA and time-series reasoning rather than training spanning all tasks.Training a model spanning all tasks is left to future work.Source: §5 · p. 10
• The authors state that source code and external datasets are open source and that these resources ensure reproducibility.Source: Reproducibility Statement · p. 10

A.1 API Example

• A dataset reference lets the client reconstruct typed objects while leaving signal values lazy until read.The same code searches and traverses datasets independently of original file formats and source-specific dependencies.Source: §A.1 · p. 16
• The API organizes data as Records containing Sources and Signals, with annotations attached for Tasks to reference as context or supervision.Signals combine values with a typed specification and axis; Sources can form recursive acquisition hierarchies.Source: §A.1 · p. 16
• Dataset authors use composable Python objects; add_record() and add_task() validate references, and write() commits an immutable version.The write operation derives the schema and commits the manifest, control plane, and values plane.Source: §A.1 · p. 16

• Table 4 lists datasets as released and names task types using TimeF’s task-registry tags.Source: Table 4 · p. 16

B A Compositional Taxonomy of Temporal Tasks

• The appendix formalizes the full task specification and its support relations.It also enumerates the signature space and task families.Source: B A Compositional Taxonomy of Temporal… · p. 17
• It describes the output-type registry and task specialization.The appendix also covers orthogonal interaction axes and task constructors.Source: B A Compositional Taxonomy of Temporal… · p. 17
• It closes by stating the current scope of the specification.Source: B A Compositional Taxonomy of Temporal… · p. 17

B.1 Full task specification

• Signals inhabit a record’s recursive source hierarchy, and annotations can attach to records, sources, or signals.A task specification also includes conditioning, output type, target support, target derivation, and scoring.Source: §B.1 · p. 17

B.2 Support relation and arity

• Target support distinguishes withheld regions, future targets, and unobserved channels; arity counts the temporal objects jointly defining a target.Known future covariates do not change the future relation, which is determined relative to target channels.Source: §B.2 · p. 18

B.4 Formal definitions of the constructions

• The constructions distinguish attribute and relational inference, temporal construction and transformation, localization, and future-directed inference.Construction generates a signal without observed temporal input; transformation produces one from an existing object, while localization identifies where or when a phenomenon occurs and forecasting is the signal-valued future case.Source: §B.3 · p. 18, §B.4 · pp. 19–20

B.3 The signature grid

• The signature space partitions well-posed tasks into six constructions, represented by output-kind rows and support-relation columns, with relational tasks in a final column.Signal-valued construction and transformation together form the temporal-synthesis family.Source: §B.3 · p. 18, Table 5 · p. 19

B.5 Output-type registry

• Output types are registered with validators, semantic kinds, and compatible scoring functions, while composite outputs inherit the most temporally structured kind of their components.The registry includes representative built-in output types and default evaluation functions.Source: §B.5 · p. 20, Table 6 · p. 20

B.6 Task specialization

• A task signature identifies its semantic family, while task-specific restrictions constrain admissible inputs, conditioning, outputs, or temporal support.Single-step and probabilistic forecasting are examples of specializations that restrict the target.Source: §B.6 · pp. 20–21

B.7 Orthogonal axes: interface, reasoning, and protocol

• Question answering is an interface, and rationale requirements and streaming protocols can vary without changing the underlying semantic task family.Streaming predictions receive only the input prefix available at each prediction time.Source: §B.7 · p. 21

B.8 A compositional task algebra

• Task specifications factor semantic signature, specialization constraints, exposure and supervision axes, and evaluation into distinct components.Source: §B.8 · p. 21

B.9 Task constructors

• Constructors shift, mask, reduce, or pair task targets, while restriction adds constraints and asking, explaining, or streaming changes orthogonal axes.The constructors formalize task relationships rather than requiring corresponding public SDK operations.Source: §B.9 · p. 22

B.10 Constructor preconditions

• Constructor validity requires the resulting task’s supervision and other constructor-specific preconditions; type validity alone does not guarantee semantic usefulness.Derived tasks should retain their derivation as provenance, and constructors must meet domain-specific as well as type-level conditions.Source: §B.10 · p. 22

B.11 Scope and limitations

• The specification covers supervised and self-supervised mappings from temporal views to typed targets.Masked reconstruction and next-step prediction can be represented using Mask and Shift applied to signal targets.Source: §B.11 · p. 23
• Interventional and counterfactual tasks are not first-class because the support relation does not distinguish observational from interventional targets.Conditioning may describe an intervention, but the current support relation does not distinguish it from observational targets.Source: §B.11 · p. 23
• Sequential decision-making is not first-class because actions that change subsequent observations require an interactive environment rather than a fixed stored target.Source: §B.11 · p. 23
• Multi-turn and agentic interactions—including dialogue over a record, tool use, and iterative observation/action loops—are outside the current task specification.Source: §B.11 · p. 23
• Structured outputs such as causal graphs or hierarchical event structures are not built in, though they can be incorporated by registering new output types.Source: §B.11 · p. 23
• The specification is intended to be extensible rather than exhaustive: new output types, relations, and task constraints can be added without changing the temporal-recording representation.Source: §B.11 · p. 23