v1.0.0 to v1.1.0

+ version: "1.1.0"

+ ## When NOT to Use

+

+ - **You need adjusted price series, not the event calendar.** Building backadjusted OHLCV across splits/dividends belongs to `corporate-action-adjusted-backtesting`, which consumes the event log this skill ingests.

+ - **You are reconciling two vendors' already-adjusted price series** (factor methodology differences, rounding conventions). See `vendor-specific-adjustment-methodology-reconciliation`.

+ - **You owe dividends on a short position.** That is a dividend *payable*; this engine models receivables only and rejects negative share counts.

+ - **You need exchange holiday-calendar arithmetic.** The forward risk window is measured in calendar days; the module carries no business-day calendar.

+

+ 1. **Event Ingestion & Validation**: Ingest event payload (`symbol`, `event_type`, `ex_date`, `record_date`, `payment_date`, `value`). Events are validated on construction: event type must be one of `CASH_DIVIDEND`, `STOCK_SPLIT`, `RIGHTS_OFFERING`, `SPIN_OFF`; dates must satisfy `declaration_date <= ex_date <= record_date <= payment_date` (ex == record is valid under T+1); `value` must be positive and finite. Registration is idempotent on `event_id` — vendor re-broadcasts are dropped, not double-counted.

+ 2. **Upcoming Risk Query**: Query active events for a target date range $[T_{current}, T_{current} + \Delta T]$ (calendar days) to alert trading algorithms of upcoming ex-dates or splits.

+ - On `record_date` close, evaluate portfolio position $N_{shares}$ — i.e. the position held at the close *preceding* the ex-date; buying on or after the ex-date creates no entitlement.

+ - Entitlement Receivable $= N_{shares} \times \text{DividendPerShare}$, recognized for the **latest** dividend whose record date has passed.

+ 4. **Multi-Vendor Feed Reconciliation**: Compare vendor event feeds against Golden Source references in **both directions** — a whole event missing from one feed is as serious as a mismatched date. Ex-date, record date, payment date and value mismatches all raise alerts; declaration-date differences are not flagged (dissemination lag, not entitlement risk). If any discrepancy is found **before the ex-date**, escalate to the golden source and hold downstream processing for the affected symbol — do not silently prefer either vendor's dates.

+ - **Assuming the Ex-Date strictly precedes the Record Date**: since US standard settlement moved to T+1 (SEC Rule 15c6-1(a), compliance date 2024-05-28), exchanges generally set the ex-date **on** the record date; under the prior T+2 convention it was one business day earlier. Entitlement itself is fixed earlier still: you must hold shares at the close *prior to* the ex-date — buying on the ex-date yields no dividend, and shares sold on the ex-date still entitle the seller.

+ - **One-Directional Reconciliation**: comparing only Golden-Source-vs-Vendor misses events the golden source lacks entirely. An event present in only one feed is the most common parity failure and must block automated processing until resolved.

+ - **Double-Counting Re-Broadcast Events**: corporate action feeds re-deliver amended or re-published events. Deduplicate on `event_id` (idempotent registration), not on symbol+date, or one announcement cycle will inflate entitlements and risk queries.

+ - Register the same `event_id` twice; verify it is stored once (registration returns `False` on the duplicate).

+ - Register a second, later dividend ($1.00/share, Record Date: 2025-08-11) for the same symbol; verify the entitlement computed after 2025-08-11 reflects $1.00/share, not the first event.

+ - Verify reconciliation flags an event present in only one vendor feed, and rejects events with out-of-order dates or non-positive values at construction.