bayesline.api.equity.HoldingsOverrideWindow

bayesline.api.equity.HoldingsOverrideWindow#

model HoldingsOverrideWindow#

A time-windowed set of holdings overrides for a single portfolio.

Each override is re-applied at every rebalance tick of the window (see PortfolioOverride.rebalance_frequency; the window’s start date is always a tick) and the resulting share count is held between ticks.

A child-portfolio target may be any source portfolio selected by the report’s portfolio organizer, even when the parent does not hold it in the baseline. Parent and child need not come from the same upload source. This creates a scenario-only fund-of-funds edge, so the parent must already be a fund-of-funds source portfolio and the resulting topology must remain acyclic. Applying the scenario returns a derived accessor whose portfolio hierarchy includes the new path wherever the parent occurs, decomposed no deeper than the report already decomposes (a child’s own sub-tree below that depth is aggregated into the new path). New paths require an already decomposed parent with a {REST} row to split; hidden baseline children and collapsed branches retain their existing granularity. The original accessor is unchanged.

Targets with no price. An override can only be turned into a position on a date where the target has a price in the risk dataset. On any other date (not yet listed, delisted, id not valid yet, off-dataset) the target is held at zero — and any baseline holding of it is treated as zero, so it is not held either. The override then takes effect at the first rebalance tick on which the target is priced. Nothing is held in its place: the portfolio is simply smaller by that amount until then (cash is not modelled), so normalized weights and returns are those of the positions that could be held. Consequences:

  • With rebalance_frequency=NEVER the only tick is the window start; an override on a target unpriced there never takes effect in the window.

  • An override of 0 on a target keeps it out of the book for the whole window, priced or not.

  • Overrides never fail for lack of a price; there is no error to catch.

Fields#

Field

Type

Required

Default

end_date

date

Yes

override_unit

OverrideUnit

No

<OverrideUnit.NAV: 'nav'>

overrides

dict[str, float]

No

factory

snapshot_date

date | None

No

None

start_date

date

Yes

field end_date: date [Required]#

Override effective end date.

field override_unit: OverrideUnit [Optional]#

How to interpret the overrides values. NAV (default): an absolute target NAV in the report currency. WEIGHT: a target fraction of the parent portfolio’s own total NAV, supported only for child-portfolio targets and for leaf targets on fund-of-fund / source portfolios (a weight on a post-lookthrough / non-cascade leaf target is rejected).

field overrides: dict[str, float] [Optional]#

Mapping of target_id (a leaf asset_id or a child portfolio_id) to an override value, applied after snapshot replacement. Each value is interpreted per override_unit. A leaf target with no price on a date is held at zero on that date and picks up the override at the first priced rebalance tick (see the class docstring). A child portfolio only needs to be selected by the report’s organizer; it does not need to be an existing child of the parent or come from the same upload source.

field snapshot_date: date | None [Optional]#

If set, replace the portfolio’s holdings within this window with the full holdings as of this date. Overrides are then applied on top. If None, only the explicit overrides are applied.

field start_date: date [Required]#

Override effective start date.