Skip to main content

ml4t-specs

Python 3.12-3.14 PyPI License: MIT

Serializable, runtime-neutral contracts for market data, artifacts, strategy lifecycles, and execution across the ML4T library ecosystem.

The stable support matrix is CPython 3.12, 3.13, and 3.14 on Linux, macOS, and Windows. CPython 3.15 prereleases are tested on all three operating systems but are not advertised as stable until Python 3.15 is final.

What This Package Does

ml4t-specs provides the small set of shared types that multiple ML4T libraries use to describe:

  • market data column mappings and feed semantics
  • artifact metadata and storage conventions
  • versioned strategy lifecycle and market-event semantics
  • canonical targets, child orders, execution assumptions, and position-rule state
  • lightweight YAML/JSON spec payloads

It exists so the higher-level libraries can exchange consistent contracts without re-defining the same dataclasses in multiple repos.

Today it is used by:

  • ml4t-backtest for feed, lifecycle, strategy-intent, execution, and position-rule semantics
  • ml4t-live for the same runtime-neutral execution contracts
  • ml4t-engineer for artifact metadata
  • ml4t-diagnostic for artifact and backtest-result integration
  • ml4t-models as an optional integration bridge when ml4t-specs is installed

Installation

pip install ml4t-specs

Quick Start

Normalize provider-specific field names into a portable feed contract:

from ml4t.specs import FeedSpec

feed = FeedSpec.from_mapping(
    {
        "time_col": "date",
        "symbol_col": "ticker",
        "price_col": "settle",
        "close_col": "settle",
        "calendar": "NYSE",
    }
)
assert feed.timestamp_col == "date"
assert feed.entity_col == "ticker"
assert feed.price_col == "settle"

Main Types

FeedSpec

FeedSpec defines how downstream libraries should interpret a tradable price table:

  • timestamp column
  • entity column
  • price / OHLCV columns
  • quote columns
  • calendar and timezone
  • data frequency and timestamp semantics
from ml4t.specs import FeedSpec

feed = FeedSpec(
    timestamp_col="date",
    entity_col="ticker",
    close_col="settle",
    price_col="settle",
    calendar="NYSE",
    timezone="America/New_York",
    data_frequency="daily",
)

MarketDataSpec

MarketDataSpec bundles schema, semantics, and artifact metadata into one serializable object.

from ml4t.specs import ArtifactStorage, MarketDataSchema, MarketDataSemantics, MarketDataSpec

spec = MarketDataSpec(
    artifact_id="us_equities_daily",
    schema=MarketDataSchema(timestamp_col="date", entity_col="ticker", close_col="close"),
    semantics=MarketDataSemantics(calendar="NYSE", data_frequency="daily"),
    storage=ArtifactStorage(path="data/us_equities_daily.parquet"),
)

Artifact Contracts

The base artifact layer gives ML4T libraries a shared way to talk about persisted outputs:

  • ArtifactKind
  • ArtifactStorage
  • ArtifactProvenance
  • ArtifactSpec

Lifecycle And Market Events

LifecycleContract defines callback ordering, available information, intent permissions, callback counts, exception behavior, and causal rank for each portable strategy phase. LIFECYCLE_V1 is the supported contract. MarketEvent supplies versioned event identity, validated payloads, provider sequence or gap evidence, and immutable JSON metadata. Phase declaration order is the serialization order; causal_rank defines causal ordering.

Strategy And Execution Contracts

CanonicalTargetIntent records a strategy decision before order construction. CanonicalChildOrderIntent records the resulting unsigned order, its target lineage, fill decision session, fill session, eligibility phase, time in force, and required execution capabilities. eligibility_phase is always a phase in decision_session. The two session fields permit a close decision to schedule a child for a later session's opening auction. Targets may schedule an arbitrary future effective session so allocation systems can register dated decisions in advance; venue calendars decide whether that date is tradable. ExecutionPolicy records the assumptions under which an engine or venue executes those orders. PositionRulePolicy and PositionRuleState make client-side and broker-native exit behavior portable and resumable. Persist one PositionRuleState per rule_id that carries runtime state, including composite parents and stateful leaves. Its remaining quantity is post-action; partial exit quantity and adjusted stop price are stored with the latest action. SCALED_EXIT sizes an exit order below the open position quantity; it does not require the venue to partially fill that smaller order, so it is independent of allow_partial_fills. Stop-loss, take-profit, and trailing-stop rules use the required fractional pct parameter in (0, 1]. Time exits use the required positive integer max_bars; scaled exits use ordered ScaledExitTarget values.

These contracts serialize to JSON-compatible mappings. Their comparison helpers report exact field-level differences, including generated identities and timestamps. Callers comparing two engines must align those fields first. Auction fill eligibility and auction time-in-force values require the matching declared capability. A decision that observes a completed close cannot fill at that same close. Instrument prices may be negative, while quantities, trailing amounts, and trailing percentages remain positive. Favorable and adverse excursions are signed fractional returns. Use validate_child_against_policy() before submission to reject child orders that need execution behavior disabled by the selected policy. Use validate_rule_policy_against_execution_policy() before activating position rules.

For intraday strategies, NEXT_PHASE from INTRABAR or MARKET_EVENT means the next event in that same phase. Cross-session opening fills use OPENING_AUCTION explicitly, with OPG time in force and the opening-auction capability. CURRENT_PHASE, including IOC and FOK, is available only for evolving MARKET_EVENT callbacks. Bar-based INTRABAR decisions have already observed the completed high and low and must use NEXT_PHASE. Engines must call validate_event_against_phase() before dispatch so a completed event cannot be presented as an evolving callback.

CanonicalChildOrderIntent requires both decision_session and effective_session. An order decided before the opening auction uses eligibility_phase=PRE_OPEN with fill_eligibility=OPENING_AUCTION; using eligibility_phase=OPENING_AUCTION means the decision already observed that session's open and is rejected for same-open execution.

Read And Write Spec Payloads

from ml4t.specs import read_spec_payload, write_spec_payload

write_spec_payload(spec, "market_data.yaml")
loaded = read_spec_payload("market_data.yaml")

Why This Exists

The public ML4T libraries share a few contract types at their boundaries. Keeping them here:

  • reduces duplication
  • keeps cross-library serialization consistent
  • gives backtest, modeling, engineering, and diagnostics code one shared contract vocabulary

This package is intentionally small. It is a support layer, not a full end-user workflow library.

Development

Read the contribution guide for issue scope, verification evidence, and contract compatibility requirements.

git clone https://github.com/ml4t/specs.git
cd ml4t-specs
uv sync --dev
uv run ruff check src/ tests/
uv run ty check
uv run pytest tests/ -q
uv build

Resources

License

MIT

Metadata

Release files for ml4t-specs 0.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ml4t-specs 0.2.0
File Size Uploaded Provenance Actions
ml4t_specs-0.2.0.tar.gz 59.7 kB With provenance Details for ml4t_specs-0.2.0.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for ml4t-specs 0.2.0
File Interpreter ABI Platform Actions
ml4t_specs-0.2.0-py3-none-any.whl Python 3 none any Details for ml4t_specs-0.2.0-py3-none-any.whl

Total release size: 96.7 kB

Release files / ml4t_specs-0.2.0.tar.gz

Download URL ml4t_specs-0.2.0.tar.gz
Size 59.7 kB
Tags Source
SHA-256 checksum
How to use checksums
e5d5d614f71d14223341f992009d0d0bf14f30a8398c50872d2b3fb80fd33d82
BLAKE2b-256 checksum
How to use checksums
2e46c734e5bcac1f214c83423243023b5d313bccabd25563da4e7d5e6b80f9f4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.

Transparency log

Release files / ml4t_specs-0.2.0-py3-none-any.whl

Download URL ml4t_specs-0.2.0-py3-none-any.whl
Size 36.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
cfd550d19b469f1b083d6ac3f83b235fe71aee19c28465f2ac2c8620064bae61
BLAKE2b-256 checksum
How to use checksums
66ffbfc427bb71635f31cb240330aa2b1b486748999f05a5922ee5f58df721fe
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.

Transparency log

Security for ml4t-specs 0.2.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for ml4t_specs-0.2.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page