Product Model

Time Seventeen’s primary hierarchy is index-centric: an Index packages weighted Constituents that map to Markets on source Venues, while preserving venue-native Event/Series relationships for traceability.

Index
  └── IndexVersion (immutable methodology + effective interval)
      └── Constituent (weight + eligibility decision)
          └── MarketMapping
              ├── Venue
              ├── SourceEvent / SourceSeries
              └── Market
                  └── Outcome

IndexPriceObservation ── references IndexVersion + source MarketPriceObservations
MarketRating           ── references Market + RatingMethodologyVersion
SeverityAssessment     ── references Event or SeverityIndex + SeverityMethodologyVersion

Account
  ├── Balance
  ├── Position
  ├── Order ── Fill(s)
  └── Settlement / Redemption

Index

An Index is a stable identity (index_id) with a mutable slug/symbol, a status enum, and a pointer to its currently active Index Version. Reading an Index alone never fully determines a value — the value comes from a specific version.

Index Version

An Index Version is immutable once published. It fixes the methodology reference, constituent set, weights, and effective_from (with an optional effective_to once superseded). A rebalance publishes a new Index Version rather than mutating the previous one, so historical index values remain reproducible against the version that produced them.

Constituent and Market Mapping

A Constituent is a weighted, eligibility-decided member of an Index Version. Each Constituent is linked through a Market Mapping to one or more Venue-specific Markets. The mapping records any per-venue normalization applied before the Constituent’s price feeds into index calculation.

Venue, Source Event, Source Series

A Venue is the source prediction-market platform. Time Seventeen preserves the venue’s native Source Event / Source Series grouping alongside its own normalized Event, so a reader can trace a Market back to where it originated even though Time Seventeen does not require every venue to expose identical event/series semantics.

Market and Outcome

A Market is a tradable instrument with a resolution rule, resolution source, eligibility status, schedule, and one or more Outcomes (for example a binary YES/NO pair, or several outcomes in a multi-outcome market). Outcomes are the unit that Orders, Fills, and Positions ultimately reference — never the Market alone.

Independent assessment resources

• MarketRating references a Market and a RatingMethodologyVersion. It never references an Event or a Severity Assessment.
• SeverityAssessment references an Event (or an independently calculated Severity Index) and a SeverityMethodologyVersion. It never references a Market or a Market Rating.

Account-side resources

Trading introduces a parallel Account hierarchy: Balance, Position, Order → Fill, and Settlement/Redemption. These resources are described in Trading Lifecycle and the private API reference pages.

Identity and versioning rules

• Resource IDs are stable, opaque strings with a readable type prefix; clients MUST NOT derive semantics from the prefix.
• Slugs and symbols are mutable presentation fields, never foreign keys.
• Methodology objects are versioned separately from Index Versions, so two Index Versions may share one methodology version.
• Append-only assessments and observations carry revision, supersedes_id, correction_reason, and published_at to preserve a full audit history.
• Deletion is not part of the public protocol for auditable financial/event data. Withdrawal or archival changes a resource’s status while preserving the record.

Continue to Index Lifecycle for how versions are created, rebalanced, and corrected over time.