Problem

Chronon users currently repeat entity keys, output fields, and types in Feast Entity, ChrononSource, and FeatureView definitions. Keeping those definitions aligned adds work and creates opportunities for metadata drift.

Proposed solution

Allow explicitly selected native Chronon GroupBy and Join objects to be registered directly, without requiring a second handwritten feature definition or a decorator. For example:

# Proposed API, subject to design review
store.apply([purchases.v1, training_set.v2])

Normalize these objects into Feast registry definitions before the existing validation/inference pipeline. Resolve deployed names, keys, output names, and types from authoritative Chronon metadata. Where the object is incomplete, support analyzer-generated schemas or validated output schemas with explicit configuration overrides; do not guess types from sample values.

Keep endpoint and historical-output configuration separate from the computation definition. Chronon continues to own computation, deployment, backfills, and serving.

Acceptance criteria

• Representative GroupBy and Join objects produce usable Feast entities, sources, and feature views through the SDK.
• Preserve Join prefixes, key mappings, and resolved derivation outputs; missing or unsupported metadata produces actionable errors.
• Registration is deterministic and idempotent, with clear errors for incompatible entity/view names or types.
• CLI registration has explicit selection and shares the SDK conversion logic. Imported Chronon dependencies are not silently registered.
• Online-only definitions have a supported path without inventing a Parquet path or timestamp field.
• Existing Feast definitions remain compatible, and Chronon remains an optional dependency with documented supported versions.
• Tests cover registry round-trips, representative retrieval, schema/name conflicts, absent dependencies, and SDK/CLI equivalence; include a runnable example.

Alternatives considered

Maintain separate Feast definitions, generate Python files, or require a decorator. Direct object acceptance should be the primary authoring experience; an internal adapter may implement the conversion.

Context

Follow-up to #6188. Starting points: FeatureStore.apply, repository discovery, and ChrononSource.

This is a proposed enhancement; API details need agreement before implementation.