[research·architecture] One route-scoped market-context capability — shared observations, bounded research, no background news system

[atomchung]

Status

Research / architecture decision only — recorded 2026-08-02. Not an implementation request and not on the current M1 acceptance critical path.

Current execution authority remains #27 / #713: repair the bounded consider rule-effect and product-safe outcome projection, freeze a new exact SHA, then restart owner-live acceptance. Do not widen that repair with this work.

This issue exists because the repository now has good individual market-data and market-lookup pieces, but no single owner for their cross-route product semantics.

Milestone

None yet. Re-evaluate after the current M1 candidate is repaired and the ordinary / market-data recovery / bounded-unavailable owner journeys have completed.

User outcome

Every supported decision route receives the right market context for that user moment:

• fresh public observations when the answer is genuinely about “now”;
• one frozen observation frame when the user is answering, resuming, or amending the same review;
• bounded current-event or decision-dimension research only when it can change the lead judgment or one necessary question;
• no duplicate price sources, no observation-instant drift, no generic news dump, and no claim that a public event was the user's motive without confirmation.

The user should not need to know which internal module fetched a price, built a benchmark window, or verified an event. They should see one coherent answer with source, as_of, and an honest route-specific limitation.

Current repository truth / evidence

Verified against latest main@907627ce147a936fad43b5e58b8a6bfb5f90900d and the current execution index #27.

1. Deterministic observation acquisition is already independent

#605 / PR #611 introduced engine/market_data.py as the single acquisition boundary for:

• instrument and benchmark closes/history;
• split observations;
• spot and historical FX;
• source, as_of, coverage and stable gaps;
• supplied-feed precedence and same-day cache reuse.

prepare and consider consume the same MarketDataBundle. The module explicitly owns no portfolio weights, returns, P&L, recommendation or state transition.

Latest PR #762 adds unresolved and stable throttle/request-failure gaps so a rate-limited symbol is no longer presented as delisted/unpriceable and no longer invalidates same-day cache reuse for the whole universe. This shows the acquisition seam is real and actively hardened, but also that provider behavior remains a reliability and latency concern.

2. Deterministic market backdrop exists as a projection

engine/market_context.py computes frozen SPY / QQQ window and YTD readings plus VIX level/delta. Supported prepare flows build that context from the shared price frame; weekly-market-read (#683) reads the settled plan and never refetches a provider.

#683 is implemented and CI-verified but owner-live UX-unaccepted. Its current slice is deliberately narrow: too_heavy × positive frozen VIX delta, then one read-only watch. It is not a live news recap or monitor.

3. Current-event / decision-dimension research is a separate host contract

#601 / PR #604 added references/market-lookup.md, currently prompt/docs only:

• L0: standing position packet on every consider call — current price vs premise, recent move and 52-week range;
• L1: triggered event lookup for vague/current why_now, a cited current claim, or a narrow contradiction;
• L2: triggered lookup of a decision-central unchecked dimension such as valuation, operating evidence or an official macro release.

The contract correctly separates public_fact, agent_judgment, and user-confirmed why_now, uses one primary source plus at most one countercheck, and persists no research store.

4. The current split creates one unresolved cross-route gap

consider already asks market_data.py for current prices needed by deterministic portfolio arithmetic. The L0 contract separately instructs the host to fetch/transcribe current price and ready-made recent/range readings.

Therefore one answer can currently obtain “current market context” through two acquisition paths:

1. engine MarketDataBundle for valuation/consequence;
2. host L0 lookup for position-in-time judgment.

The repository does not currently prove that these use one source, one observation instant, one coverage result, or one retry/cache policy. The user may see a correctly computed consequence and a separately gathered “recent move / 52-week range” packet that was fetched later, failed differently, or disagreed in basis/provenance.

5. Freshness and failure semantics are correct locally but scattered

• prepare: resolve once, then freeze the review frame; price gaps may degrade after bounded recovery.
• resume, preview, finalize, add-cash: must reuse the frozen frame; refetching would change the review the user already answered against.
• book-aware consider: current observations matter; after bounded recovery is exhausted, the route may refuse rather than answer on an unsafe basis.
• no-book decision framing: host-side, fail-soft, no portfolio arithmetic, but L0/L1/L2 can still improve the decision framing.
• weekly-market-read: retrospective window-frozen companion; omit when its connection gate is absent, never substitute a generic recap.
• generic market/news questions: host informational behavior, not a FOMO Kernel decision-memory or review route.

These distinctions are spread across market_data.py, market-lookup.md, trade-consequence.md, decision-framing.md, weekly-review.md, weekly-market-read.md, SKILL.md and AGENTS.md. There is no one route policy declaring them.

Problem and consequence

1. “Market information” currently names three different truth classes

1. reproducible observations — price, FX, volume/range/benchmark series;
2. deterministic projections — recent move, range position, market backdrop;
3. researched evidence — filing, guidance, macro event, operating or valuation claim.

Treating them as one module either puts non-deterministic research inside the deterministic engine or leaves deterministic numeric context in agent prose. Both violate existing boundaries.

2. L0 may duplicate acquisition and observation instants

A second host-side lookup costs latency and provider requests, has its own failure path, and can describe a different instant from the book consequence.

User consequence: “this becomes X% of the book” and “the stock is near Y point in its range” can both be individually sourced but not form one coherent decision frame.

3. Route freshness is implicit

“Always use the latest data” is wrong for resume, add-cash, preview/finalize and weekly retrospective reading. In those moments, freshness means preserving the exact frame the user already saw, not refetching a newer frame.

User consequence: the same review can change underneath their answers or explain a move that happened after the decision window.

4. A continuous market monitor would solve the wrong first problem

An always-on news/filing service would introduce scheduling, coverage, correction/replay, retention, notification, source licensing, latency and relevance problems before the existing route-scoped lookup has proved insufficient.

It would also move the product toward the research-terminal / investment-OS scope #475 explicitly excludes. “Know everything continuously” is not the product requirement; retrieve and freeze the smallest decision-relevant delta at the right moment is.

Decision

A. Keep three layers, with explicit ownership

Layer 1 — MarketDataBundle: acquisition facts

Keep engine/market_data.py as the single source-neutral acquisition boundary for reproducible observations. No recommendation, interpretation or user motive enters it.

Layer 2 — deterministic market-context projections

Build route-visible numeric context from the same resolved bundle whenever the engine already has the needed series. Candidate projections, names not yet final:

• PositionMarketSnapshot: current close, premise/current relationship, recent return windows, 52-week high/low and range position;
• MarketBackdrop: benchmark window readings and VIX context.

The engine owns window definitions, adjusted/raw basis, observation dates, missing coverage and rounding. The agent selects salience and explains relevance; it does not calculate a parallel L0 packet.

This is a candidate decision, not authorization to implement. First measure whether the current host L0 path actually duplicates calls or produces instant/basis divergence, and define the exact return/range semantics before changing the contract.

Layer 3 — bounded MarketEvidencePacket: researched facts

Keep L1/L2 event and decision-dimension research host-side and triggered. A future typed packet may be justified only if cross-host drift or provenance failure is observed; do not create a crawler, evidence database or generic research graph pre-emptively.

The packet, if introduced, would remain ephemeral to the decision unless a separate product owner names a later reader. It cannot become why_now without the user's own confirmation.

B. Declare one route-scoped market-context policy

Each route should explicitly state four things:

1. observation mode: live | session_frozen | window_frozen | none;
2. research mode: none | triggered_l1_l2;
3. failure mode: degrade | refuse | omit;
4. persistence: which facts are frozen in the existing route artifact and which remain conversation-only.

Initial policy to validate:

User moment	Observation mode	Research	Failure behavior
first / weekly / snapshot prepare	live once, then session-frozen	normally none	bounded recovery, then route-defined degradation
resume / preview / finalize / add-cash	session-frozen only	none	fail closed if the frame is gone; never refetch
book-aware consider	live decision snapshot	triggered L1/L2 when material	bounded recovery; refuse when truth-critical consequence is unavailable
no-book decision framing	live public context, no book arithmetic	triggered L1/L2	fail-soft and state the narrow unverified dimension
weekly-market-read	window-frozen from the settled review	none in current slice	omit; never substitute generic recap
generic news / market recap	not a FOMO Kernel product route	host-defined	no kernel state or decision-memory claim

C. Do not build an always-on market/news subsystem now

No background scheduler, feed ingestion, filing warehouse, KOL crawler, push alert, persistent “what happened” database or market-wide discovery loop is justified by current evidence.

Revisit only if repeated route-scoped owner-live use shows one of these concrete failures:

• lookup latency dominates the decision moment despite cache/reuse;
• the same relevant event must be re-retrieved across many real decisions;
• delayed discovery causes a documented missed product outcome;
• a named future reader needs a durable event record;
• bounded host lookup cannot achieve acceptable source consistency across clients.

User before / after

Before

• consider can price the book through the engine and separately fetch L0 context through the host;
• each route locally knows whether to fetch or freeze, but no single contract makes the difference inspectable;
• “market context” can mean a price bundle, SPY/QQQ/VIX projection, or researched event;
• a user may experience repeated lookups, inconsistent as-of moments, a recovery refusal, or a weekly frozen read without understanding why those routes behave differently.

After the proposed smallest architecture

• one acquisition bundle supplies all reproducible observations for a route;
• deterministic projections own numeric L0/backdrop semantics;
• the agent performs only the contextual event/dimension research that requires judgment;
• every route declares live-vs-frozen behavior and degrade/refuse/omit semantics;
• users get faster, coherent, source-dated answers without turning the product into a market terminal.

Best-practice assessment

This separation solves observed repository risks:

• duplicate acquisition and provider exposure ([architecture·implementation] One market-data resolver — minimum Yahoo calls, one fact bundle for prepare and consider #605, [defect·P2] A permanently-unpriced symbol makes the cache refuse the exact request that produced it — every same-day command re-fetches the whole universe #687 / PR fix(market-data): tell a throttled symbol apart from a delisted one (closes #687) #762);
• multiple facts from different instants ([architecture·implementation] One market-data resolver — minimum Yahoo calls, one fact bundle for prepare and consider #605 / PR feat(market-data): one resolver, one dated bundle, and a consider that can see today's prices (refs #605) (closes #584) #611);
• agent-authored numeric truth and cross-host drift ([design·M1] Bounded market-context lookup — verify why-now without inventing the user's motive #601 boundary);
• refetching a review after the user saw it (TR_MARKET_DATA_FROZEN / [defect·P1] add-cash refuses the session it exists for: the drift gate compares question_queue and state_snapshot whole, so the card-beat cash answer is unrecordable #665);
• generic recap replacing a decision-specific connection ([feat·P1] A weekly review should read the week's market against the user's own holdings — prices, turning points, not only an index delta #683).

It is not justified as architecture cleanliness alone. The implementation should stop if measurement shows L0 does not duplicate acquisition, does not drift, or does not materially affect latency/answer quality.

A provider framework, second source, resident monitor, generic event ontology or persistent research store would be over-design at this stage.

Research scope

1. Trace the actual supported call path for prepare, consider, no-book framing and weekly-market-read on current main.
2. Measure provider/tool calls, observation timestamps and wall-clock for one synthetic case per route.
3. Prove whether book-aware consider performs a second L0 retrieval after MarketDataBundle resolution and whether the visible facts can diverge in source/as-of/basis.
4. Inventory every current numeric field required by L0 and classify it as:
   • already present in the bundle;
   • deterministically derivable from the bundle under a named window/basis;
   • provider-specific ready-made value that should remain host-transcribed;
   • unnecessary for the first useful answer.
5. Produce the route policy table with one authoritative documentation location and thin references from route files.
6. Run one owner-live book-aware consider and one no-book framing to decide whether the market context adds non-obvious value or merely more prose/latency.
7. If and only if duplication/drift is observed, open one bounded implementation issue for a shared deterministic L0 projection.

Non-goals

• No implementation in this issue.
• No second provider or provider plugin registry ([research·parked] A second market-data provider the engine can fail over to on its own #638 remains parked).
• No crawler, market-wide discovery, news feed, scheduler, notifications or email.
• No price target, forecast, buy/sell/hedge/allocation recommendation.
• No generic sentiment or risk-on/risk-off scalar.
• No persistent event/evidence graph.
• No direct read of a private repository or private market note.
• No change to portfolio arithmetic, state identity or canonical review memory.
• No automatic promotion of a found event into user motive.
• No expansion of [feat·P1] A weekly review should read the week's market against the user's own holdings — prices, turning points, not only an index delta #683 before its owner-live verdict.

Acceptance criteria

• The supported route call graph is documented against one exact main@SHA.
• Provider/tool call count, observation as_of, and wall-clock are recorded separately for prepare, book-aware consider, no-book framing and weekly-market-read.
• The issue proves or rejects the L0 duplicate-acquisition / instant-drift hypothesis with a synthetic reproducible trace.
• Every L0 numeric field has a named owner and basis; no field is left as “agent calculates it.”
• One route policy table defines live/frozen mode, lookup trigger, failure behavior and persistence.
• The policy preserves the current difference between review degradation, consider refusal, and weekly-read omission.
• One owner-live verdict states whether current market context materially improved the decision, and whether its latency/extra prose earned its place.
• The conclusion explicitly chooses one of: keep host L0; move bounded L0 projection over MarketDataBundle; or remove fields that do not earn their latency.
• No implementation issue is opened unless the measured failure names the smallest user-visible correction.
• Public evidence uses only fictional/generic instruments and contains no private trade, book, motive, source list or output.

Dependencies / relationships

• tracking: current context index — milestone, critical path, what an agent may pick up #27 / [acceptance·P0] M1 vertical-slice reliability gate — repeatable completion before more capability #713 — current M1 critical path and acceptance authority. This work must not widen or delay it.
• [QA·dogfood] Judgment-quality dogfood — does a real consider answer now carry a supported insight? #610 — owner-live judgment-quality and market-data recovery journey.
• [architecture·implementation] One market-data resolver — minimum Yahoo calls, one fact bundle for prepare and consider #605 / PR feat(market-data): one resolver, one dated bundle, and a consider that can see today's prices (refs #605) (closes #584) #611 — deterministic acquisition boundary.
• [design·M1] Bounded market-context lookup — verify why-now without inventing the user's motive #601 / PR docs(contract): market context reaches a consider answer only through the bounded lookup contract (closes #601) #604 — bounded L0/L1/L2 lookup contract.
• [design·perf] Response-time budget by route — separate real-user latency from QA/test overhead #603 — route response-time measurement.
• [design·process] Only splits stops a new workflow shipping without handling a basic fact — FX, pricing basis and classification have no equivalent #607 — basic-fact / route or aggregation-site coverage discipline; this issue may supply a future freshness/context policy row but does not absorb that process design.
• [feat·P1] A weekly review should read the week's market against the user's own holdings — prices, turning points, not only an index delta #683 — frozen weekly market companion and its owner-live gate.
• [research·roadmap] Staged direction: pre-trade challenge → decision memory → rule learning #475 — product scope guard.
• [research·parked] A second market-data provider the engine can fail over to on its own #638 — second provider remains parked.

Privacy boundary

Only synthetic, fictional or generic books, instruments, timestamps and public-source fixtures may be committed or posted. Real holdings, trades, reasons, lookup queries, source selections and delivered answers remain local.

Market-data cache keys reveal requested symbols and remain local under the protected state root. No new persistence is authorized here.

Rollout / compatibility / recovery

Research only, so no migration or compatibility change.

Any later deterministic L0 projection should be additive first, consume the existing MarketDataBundle, preserve supplied-feed mode, retain existing gap semantics, and leave canonical session/evaluation state readable. Rollback must be code/docs only; no new durable research state should exist to migrate.

Stop condition

Stop after the route trace, duplicate/drift measurement, policy table and two owner-live verdicts. Do not continue automatically into implementation, a second provider, event persistence, scheduling, notifications or a broader research system.

[atomchung]

Private Morning Notes audit — portfolio relevance is not ticker matching

Reviewed the owner's private Morning Notes workflow on 2026-08-02. This comment records only generic architecture conclusions; it contains no private instrument, position, amount, thesis, source list, or output text.

Main finding

The useful pattern is not a broader news collector. It is a portfolio-attention selector layered after broad collection.

The workflow separates:

1. collection recall — gather holding, catalyst and macro candidates broadly;
2. portfolio relevance — decide what can affect the recorded book, including indirect shared drivers;
3. decision importance — select only the few items that change a current check, condition, thesis read or deadline;
4. presentation — omit the rest rather than walking every position.

A direct ticker mention is only one relevance signal and is often not the strongest one.

Reusable patterns

1. Canonical holding membership comes first

The private workflow has one read-only resolver for live holding | minor | tracker | absent. Downstream research does not infer membership from stale research/wiki metadata.

FOMO Kernel equivalent: any market-context selector must consume canonical PortfolioBasis / recorded-book identity, not agent-maintained ticker lists. Tracker/test positions and excluded/unusable holdings need explicit semantics rather than silent inclusion.

2. Search broadly, filter once

Collection intentionally over-recalls candidate events. A separate importance filter selects a small number of user-visible items. A holding that is not mentioned means “no decision-relevant update,” not “the system forgot it.”

FOMO Kernel should not ask the agent to search only for the answer it already expects. Collection and judgment need separate prompts/contracts.

3. Rank by event × portfolio relation, not popularity

A candidate becomes important through one or more of these relations:

• direct effect on a live position;
• effect on a shared portfolio driver or concentrated exposure cluster;
• evidence for or against an existing thesis/falsifier/condition;
• a near-dated catalyst or decision deadline;
• a rule/discipline state that now requires a user judgment;
• resolution of a previously material uncertainty or source conflict;
• a new fact that changes the lead case or counter-case.

Generic industry news without one of these connections remains background even when widely discussed.

4. Aggregate by underlying driver

The strongest Morning Notes section groups several headlines into one driver cluster, then asks what that cluster means for the whole book. This catches second-order effects: an event about one company can matter more to suppliers, peers or every duration-sensitive holding than to the named ticker itself.

Candidate FOMO Kernel concept: a read-only PortfolioAttentionContext or equivalent projection containing engine-owned holdings, weights, driver/classification coverage, current rules/conditions and due catalysts. It is an input to selection, not a new canonical market truth.

5. Keep news, discipline and calendar separate

The private workflow separates:

• new public events;
• position-specific discipline/condition signals;
• future catalyst calendar.

This avoids presenting a stale rule breach as “news” or treating an upcoming event as though it already changed the thesis.

FOMO Kernel should preserve the same separation:

• MarketEvidencePacket — what changed publicly;
• engine rule/condition state — what the user already committed to check;
• time/catalyst context — what becomes knowable next and when.

6. Novelty is relative to the prior state

The workflow reads the prior note/current watch state to avoid repeating unchanged information. An event can be useful because it closes an earlier unknown, not because it is directionally positive or negative.

The selector therefore needs states such as:

• new_material_fact;
• confirms_existing;
• contradicts_existing;
• resolves_uncertainty;
• unchanged_background.

This can remain ephemeral in the first slice; no news/event database is implied.

7. Unresolved provenance reduces eligibility

Conflicting dates, stale prices, unsupported summaries and source disagreements are retained as unknowns and excluded from the decision claim rather than averaged into one confident narrative.

This aligns with #601: source + as_of, public fact separated from agent judgment, and no automatic promotion into the user's motive.

Candidate relevance contract

For one MarketEventCandidate, determine these fields before agent prose:

direct_positions
affected_driver_clusters
affected_book_share        # deterministic where classification coverage permits
thesis_or_condition_links
time_criticality
novelty_state
potential_decision_delta
source_confidence
coverage_limitations

affected_book_share is a ranking input, not necessarily a user-visible number. It must be computed over the same canonical/qualified book and classification coverage as other engine facts; the agent must not sum weights itself.

A possible first ranking order:

1. condition/falsifier or rule judgment is due;
2. event can change a live consider lead/counter-case;
3. near-dated catalyst creates a decision deadline;
4. event reaches a material shared-driver portion of the book;
5. direct holding update with a real evidence delta;
6. background observation only.

Do not collapse this into one opaque scalar initially. Preserve the reasons so the user-facing answer can say why the event matters.

Route application

• Book-aware consider: select at most one current event or unchecked dimension that materially changes the premise judgment. Combine it with the deterministic position snapshot; no market recap.
• No-book framing: use direct instrument/strategy relevance and user-stated reason, but no affected-book claim.
• Weekly market read: select at most one driver cluster connected to an existing diagnosis/condition. Keep the review's frozen observation window.
• Generic market/news question: remains host informational behavior and does not create kernel state.

What not to copy

• no daily persistent Morning Note product;
• no scheduler, email or background monitor;
• no bulk ticker wiki or private research ingestion;
• no requirement to scan every macro category for every route;
• no per-position news walk-through;
• no agent-computed exposure or weight;
• no durable event store without a named later reader.

Smallest next research step

Extend #776's synthetic trace with a candidate-set exercise:

1. one direct holding headline with no thesis/decision delta;
2. one indirect driver event affecting several holdings;
3. one near-dated catalyst linked to a condition;
4. one popular but portfolio-irrelevant story;
5. one source-conflicted event;
6. one item that only resolves a prior unknown.

For each, record selected/omitted and the explicit relation above. The first implementation should be opened only if this proves that current host selection misses or inconsistently ranks these cases.

[atomchung]

Unblocked — the risk definition is ruled (2026-08-02)

#781 is settled: risk includes what is about to happen to a position, and the owner calls the forward-looking catalyst the core concern. Current structure alone is an incomplete risk answer; the recorded book is the selector that decides which forward-looking events matter to this user.

Ruling recorded at #781 comment 5156514056. Two constraints it carries into this issue:

1. A dated published fact is in; a forecast or price target is out. Boundary 2 of AGENTS.md is unchanged and now carries most of the weight.
2. Deterministic first. Anything retrievable deterministically (scheduled earnings dates, index events, ex-dividend, lockup expiry) enters through the engine with a validator. The researched half waits on the live voice/answer gate owed by [process·voice·P2] A live consider answer passes through no voice check — three output-voice violations shipped in one owner-live session with a fully green trace #782 — the engine's numbers pass gates, the agent's own sentences currently pass none.

Re-scope this issue's candidate shapes against that definition before proposing one; the shapes recorded here were written when the definition was still open.

[atomchung]

Convergence proposal — one forward-dated capability, measured against the provider (2026-08-02)

Written against origin/main@a33f315. Design only: no product code changed, no PR opened.
Supersedes nothing above; it re-scopes this issue's candidate shapes against #781's ruling and
its 5156525672 refinement, and folds in #772, #780, #683, #782.

The proposal in one paragraph

The engine gains one bounded forward-dated fact set — scheduled earnings, ex-dividend and
dividend-pay dates — acquired inside the existing market_data.resolve pass, on the same
instant, under the same gap vocabulary, through a six-key allowlist that structurally cannot
carry a forecast. The agent's only added job is the judgment #781 named: whether a dated event
is a surprise relative to what this user's own record already shows. That judgment is marked
and cited through the machinery that already exists (agent_judgment / engine_fact +
anchor), and the escape hatch that currently lets an answer skip that machinery is closed for
this one class of claim. No background news system, no second rule engine, no new taxonomy.

---

1. What the provider actually gives us

I measured rather than assumed. yfinance 1.3.0, 2026-08-02, against public tickers only (no
holdings involved). Probe scripts were throwaway, outside the repo.

Available, deterministic

Per equity, Ticker(sym).info carries:

Field	Meaning	Notes
earningsTimestampStart / End	next scheduled report	a real datetime, not a date
isEarningsDateEstimate	whether that date is confirmed or Yahoo's estimate	varies per symbol — false for NVDA/KO/TSM/ASML/SMCI, true for AAPL/MSFT/BRK-B
exDividendDate	next ex-dividend	UTC-midnight epoch
dividendDate	next pay date	UTC-midnight epoch; key absent for some non-US listings
lastSplitDate / lastSplitFactor	last split	retrospective
exchangeTimezoneName	exchange tz	needed to reason about the above

That is the whole deterministic forward surface. Coverage held for US, TW (2330.TW),
HK (0700.HK) and ADR (ASML) equities.

Not available — and this corrects the ruling's own list

#781 named "index events, ex-dividend dates, lockup expiries" as deterministic. Empirically:

• index rebalance / add-delete events — not in yfinance. Published by the index provider, not the quote API.
• lockup expiries — not in yfinance. They live in S-1/424B4 filings.
• ETFs and indices return nothing at all. QQQ, BND, VT, SPY, ^GSPC, ^VIX all return calendar == {} and a quoteSummary 404. There is no forward calendar for an ETF, including its distributions.

So the deterministic half is equities only, and covers exactly three event kinds. Index
events and lockups are researched facts (Layer 3), which means they wait behind #782 with the
rest of the researched half. That is a narrowing of the ruling's expectation and the owner
should see it explicitly.

Four traps, each of which would ship a silently wrong date

1. Ticker.calendar renders the earnings epoch in the host machine's local timezone. On this machine (Asia/Taipei) it reported AAPL 2026-10-30, NVDA 2026-08-27, SMCI 2026-08-12 — each one day later than the epoch's real value (2026-10-29 16:00 America/New_York etc.). The same code on CI in UTC would print different dates than on the user's laptop. calendar is unusable; the epoch in .info is the only safe input.
2. The two epoch families need different conversions. earningsTimestampStart is a real datetime whose UTC date matched the exchange-local date for all six symbols tested. exDividendDate / dividendDate are UTC-midnight epochs, so reading those in exchange-local time shifts them a day backwards (KO ex-div: UTC 2026-09-15, America/New_York 2026-09-14). One rule that is right for both: convert every forward epoch in UTC. Pin the raw epochs in the fixture so a provider change surfaces as a red test, not a silent shift.
3. earningsTimestamp (no suffix) is often a past date — AAPL 2026-07-30, KO 2026-07-28, BRK-B 2026-05-02, while earningsTimestampStart held the future one. A populated field is not a forward field. Use ...Start, and filter > today anyway.
4. The same call hands us the things boundary 2 refuses. .info returns 186 keys including targetMeanPrice, targetHighPrice, recommendationKey: "strong_buy", averageAnalystRating: "1.3 - Strong Buy", numberOfAnalystOpinions. Ticker.calendar likewise ships Earnings Average / Revenue High in the same dict as the dates. A price target and a buy recommendation arrive in the same response as the earnings date.

Trap 4 decides the acquisition design: the extractor takes an explicit six-key allowlist
(earningsTimestampStart, isEarningsDateEstimate, exDividendDate, dividendDate,
exchangeTimezoneName, quoteType) and nothing else crosses the boundary. A denylist over a
186-key bag that already contains "Strong Buy" is not a boundary.

Cost

Measured request counts (patched at YfData.get_raw_json):

• Ticker.calendar → 1 request (quoteSummary?modules=calendarEvents)
• Ticker.info → 2 requests (quoteSummary?modules=financialData,quoteType,… + /finance/quote)
• they do not share a fetch; ~1.5–2.9 s per symbol wall-clock

Ticker.get_earnings_dates() — the past-earnings table — raises ImportError: lxml. lxml is
not in requirements.txt, so the historical earnings-reaction table is not free. That
matters in §3: it bounds what "have you held this through a prior print" can be built from.

So: +2 requests per equity, on top of the existing 1/symbol in market_data.resolve. Given
#762's throttle work and #603's budgets, that is not free at book scale — which is why §2
scopes it to a handful of symbols, not the universe.

---

2. What the capability is

Layer 1 — acquisition, inside the existing boundary

MarketDataBundle gains one field group, forward_calendar, resolved in the same
resolve() pass as closes/splits/FX. Same as_of, same memoization, same disk cache, same
GAP_CODES vocabulary — including #762's symbol_rate_limited / unresolved, so a throttled
calendar is never read as "no events scheduled", which is the exact failure #687 already cost
us once on prices.

Shape, per symbol, nothing else:

forward_calendar["<sym>"] = [
  {"event_kind": "earnings"|"ex_dividend"|"dividend_pay",
   "date": "YYYY-MM-DD",            # UTC conversion of the provider epoch
   "date_status": "confirmed"|"estimated",   # earnings only; from isEarningsDateEstimate
   "source": "<provider>", "as_of": "<bundle as_of>"}
]

Bounded to the symbols the route will actually talk about, never the whole universe:
consider → the premise ticker plus the names in the concentration cluster it lands in;
a review card → the already-diagnosed names (#683 already caps that at three);
snapshot_review → the names inside the concentration finding the card already made.
That is #776's own "retrieve the smallest decision-relevant delta" principle, applied to keep
this at ~2–10 extra requests rather than 2×N.

quoteType != "EQUITY" produces no entry and one coverage fact, not silence (§5).

Layer 2 — projection

Trivial and engine-owned: days_until (from the bundle's as_of, recomputed on read, never
frozen as a number), plus event_passed when a frozen session outlives an event date. A frozen
forward calendar decays in a way a frozen price does not — resume a week later must not
present a date that has already passed. Deterministic, cheap, and a real defect if skipped.

Layer 3 — research, unchanged and still waiting

market-lookup.md's L1/L2 stay host-side and triggered, and per #781 they open only after
#782's gate lands. Index events and lockups (§1) join them there.

The two-path duplication this closes (#776 §Problem 2)

Today L0 instructs the host to fetch current price, recent-move readings and the 52-week range
while consider separately asks market_data for prices — two acquisitions, two instants, two
failure paths. L0's price/range half retires into Layer 2, sourced from the same bundle.
market-lookup.md keeps L1, L2, the source hierarchy, the stop discipline, and the
public_fact / agent_judgment / why_now role vocabulary — which is the part of that file
doing real work.

How one answer marks source and observation instant

Not by narration — through the envelope that already exists. Everything from the bundle is an
engine_fact with an anchor (forward_calendar.<sym>.earnings.date) resolving into the
frozen record; everything from L1/L2 is a public_fact carrying its own source/as_of;
everything the agent concluded is an agent_judgment, which _check_agent_judgment_claim
already forbids from carrying source or anchor. One bundle as_of for all engine facts is
the single observation instant this issue asked for.

---

3. The hard part: how "is this already reflected?" is supported, marked, and bounded

Per the 5156525672 refinement, listing dated events is not the capability. The capability is
the judgment of whether a dated event is a surprise relative to the record. Three
separations make that safe.

Supported — the judgment gets an engine-owned support set, or it is not made

The agent may form the anticipation read only from facts the engine already owns and that are
citable by anchor:

Support fact	Owner today
the event date + date_status (estimated means even the schedule is unsettled)	new, Layer 1
days_until, and whether the event falls inside the user's recorded horizon / a condition's due date	horizon.py, conditions.py
position weight, cluster weight, distance to a cap	consequence, portfolio_basis
entry date(s), cost basis, unrealized move since entry	ledger, portfolio_basis
range position (52w high/low vs current)	existing bundle
prior ex-dividend dates the position has been held through since basis_date	already in the actions frame resolve() fetches with actions=True
whether a recorded thesis/condition names this event class	thesis.py, conditions.py

Honest gap, and worth stating because it is the most tempting thing to fake: "you have held
this through N prior earnings prints" is not derivable today. The past-earnings table needs
lxml (§1). Do not add the dependency for this; the ex-dividend history above already supports
a weaker but true version of the same sentence, and the entry date plus mostRecentQuarter
supports "you entered after their last report".

Marked — one sentence-level rule, already enforceable

The anticipation read is an agent_judgment. It is not a new claim kind and needs no new
vocabulary. One addition, decidable: an agent_judgment claim in a case that carries a
forward event must be accompanied by an engine_fact claim anchored under forward_calendar.*.
A free-floating forward judgment with nothing anchored beside it is refused. This is the
existing cross-claim coverage check applied to one more path.

Bounded — the forecast line is held by absence, not by a word filter

This is the part I want the owner to weigh, because it is stronger than a prohibited-phrase list:

1. There is no consensus number in the fact space to anchor to. The allowlist (§1) means targetMeanPrice, recommendationKey, Earnings Average never enter the record. resolve_anchor therefore cannot return a consensus figure. The forecast is not refused after the fact; it is unreachable.
2. engine_fact numbers must match the resolved value — _numeric_claim_matches already does this. An invented date or figure fails at the anchor.
3. The line the agent may state: "this is scheduled and known in advance; what is not knowable is its content", and "relative to your own record, this is / is not a new kind of exposure". The line it may not state: anything about what the market expects, or how the event resolves. Concretely — "you are sizing up nine days before a scheduled print" is inside; "the print is already priced in", "expectations are low", "this should beat" are outside, because the first is a fact about the user's record and the last three are claims about market state with nothing to anchor to.

That reformulation matters: the agent judges anticipation relative to the user's record, not
relative to market consensus. The first is anchorable and inside boundary 2. The second is a
market forecast wearing a different hat, and it stays refused.

---

4. What three users see that they do not see today

A. Cold-start, holdings snapshot only (#772)

Today: the card finds the book is one bet. snapshot_adapter sets market_context = None
and ticker_diagnosis = [], so #683's companion is structurally unreachable — the user whose
whole diagnosis is concentration is the one user who can never get a market read. The card
raises the question and then declines to engage it, in silence.

After: the concentration finding gains one dated block, scoped to the names it already
named:

Your largest holding reports on 2026-08-27 — 25 days out, and it is 34% of what you
handed over. Your second-largest goes ex-dividend on 2026-09-15.
Two of your holdings are ETFs; no scheduled-event calendar is published for them, so this
list is not the whole book.
My read, not a fact: you gave me a position table and no history, so I cannot tell whether
you built this before or after their last report — which is the thing that would say whether
a print is routine for this position or the first one you have held through.

The last line is #782's V2 (nearest useful completion) applied on purpose: it names what the
missing data would buy, rather than narrating a gap. If the calendar comes back empty — an
all-ETF book — the card says so and names what unlocks it, satisfying #772's acceptance
criterion that market_context: None stop being an adapter accident.

B. Bringing one trade to consider

Today: correct post-trade weights and rule collisions, plus a host-side L0 packet fetched on
a second instant. Nothing about what is scheduled. A user adding to a position eight days before
its report gets a complete, correct answer with no mention of that.

After:

That takes it to 31% of the book, past your 25% cap. The company reports in 9 days
(2026-08-11, date confirmed).
My read, not a fact: the reason you gave me is [the user's own words], which does not
mention the print — so you would be sizing up into a scheduled event you have not factored
in. Whether that is deliberate is the one thing worth settling before the size, and it is not
something I can settle for you.

Refused, unchanged: whether the print will beat, any target, and any naming of what to buy.

C. Weekly review (#683)

Today: the companion fires on too_heavy × positive frozen VIX delta and speaks entirely
about the window that already closed. Its NextWeekWatch is a check with no date on it.

After: the same gate, the same frozen window, but the watch line acquires a date when the
engine has one:

Before your next review, the one dated thing in this book is [name]'s report on 2026-10-20.

That also gives #683's open acceptance question — is VIX.delta > 0 too noisy a trigger — a
second candidate that is a fact rather than a market reading: a dated event inside a
too_heavy name, within the horizon. I am explicitly not proposing to change that trigger;
#683 forbids tuning before its owner-live verdict. Recording the candidate so the verdict can
consider it.

What #780 is worth, stated as a price

This proposal groups forward events by whatever concentration unit the engine already computes.
With one taxonomy level, the strongest thing sayable is "two of your holdings report this
week". With #780's second level it becomes "two holdings riding the same cycle report in the
same week" — which is the sentence that actually changes a decision. #780 is not a
prerequisite here, and this proposal inherits its benefit automatically if it lands. That is
the concrete value #780's ruling has been missing.

---

5. The minimal gate (#782, product half only)

The mechanism, stated at the product level

The repository already built the gate that would catch this. answer_provenance.validate_agent_case
receives agent-authored claim text, requires anchor on engine_fact, source+as_of on
public_fact, forbids extra fields on agent_judgment, enforces required_coverage, and
fails closed — the row is never written and never returned.

And then references/trade-consequence.md:328 says:

This flag is entirely optional; a plain --premise call is a complete, valid use of consider.

and :338:

Fix the claim and resend, or drop --agent-case and present the case in plain prose instead.

Meanwhile AGENTS.md boundary 2 states the same obligation as non-negotiable: "A case that
misquotes the record, leaves an owed fact uncovered, or relabels the user's own words as an
outside source is refused, not stored."

A shared boundary says "refused", and the reference documents the refusal as opt-out. Under
this repo's own instruction-authority rule 4 that reads as a repository defect rather than a
design choice, and it is the product-level statement of #782's mechanism: the answer the user
receives goes through no check because the contract explicitly permits routing around the one
that exists. Flagging it for the owner rather than ruling on it.

The gate

Not a new judge, not a new command, not a voice checker. Close the escape hatch for exactly
one class of claim, and hang three deterministic rules on the validator that already runs:

1. Forward content makes the case mandatory. When the turn's forward_calendar is non-empty, consider puts those events on required_coverage and marks the payload case_required: true. Answering without --agent-case on such a turn is refused. Turns with no forward content are untouched — the fast lane keeps its single call.
2. Date closure. Every date token in the submission must resolve through an anchor into the frozen record. A date the engine never produced is, by construction, invented — and this is also what catches trap 1 in §1, since a one-day-off date fails to match.
3. Prohibited-token scan on the claim text — [process·voice·P2] A live consider answer passes through no voice check — three output-voice violations shipped in one owner-live session with a fully green trace #782's own stated minimum: rule identifiers, engine field names, gate/receipt vocabulary. A short, closed prohibition list. It is not a style checker and must never grow into one; it says nothing about what a good answer looks like, only what is never allowed. (Keeping it a prohibition list is what avoids the "pinning current wording as the correct answer" failure this repo has already shipped once.)

Why it is not a structural no-op

Cut-the-supplier, for each rule:

• Rule 1: delete the forward_calendar producer → the engine no longer holds the event → a fixture whose case omits the owed event is now accepted → red.
• Rule 2: delete the anchor resolver → a case citing an event the engine does hold no longer resolves → red. Feed a date one day off → red (the timezone defect, caught as a product failure).
• Rule 3: empty the prohibition list → the fixture containing a rule identifier passes → red.

Pinned extremes, because "all obligations discharged" is trivially true of an empty obligation
list — the exact trap in this repo's history: one fixture with an empty forward calendar
(a case with no forward claim must pass; a case asserting one must fail) and one with a
non-empty calendar (a case omitting it must fail). Plus the allowlist fixture: feed a provider
payload that contains targetMeanPrice / Earnings Average and assert those keys are absent
from forward_calendar and unresolvable as anchors — add a key to the allowlist and it goes red.

The residual, named rather than papered over

Rules 1–3 see the structured case, not the prose the user reads. #782's three recorded
violations were in prose. Two honest consequences:

• Extending the submission to carry the delivered text is the difference between catching zero and three of them — that is owner choice B2 below.
• Even then, a dateless, numberless forward sentence ("this could get choppy into the print") is caught by nothing here. That is a judgment problem the deterministic layer cannot own, and I am not proposing a model judge for it: three LLM judges in this repo currently run green with zero owner-ratified rulings, so a fourth buys nothing. Saying "the deterministic floor stops here" is the honest boundary.
• And presented_text is still "what I am about to show", not proof of what was shown — the same residual card-delivery.md already states about the card preview.

Where it lives: in engine/answer_provenance.py, on the live consider path. Not in a
Claude Code hook and not in a host adapter — AGENTS.md authority rule 3 says an adapter may
change tool mechanics only, and a gate on product semantics that lives in one client's config
does not exist for Codex or Cursor.

---

6. Sequencing against M1 — what can start now, what cannot

M1's execution authority is #27/#713 and its live blocker is the #579 rule-effect repair.
Nothing in this proposal may touch that.

Can start now (cannot change any answer, because no route reads it)

• Layer 1 acquisition: the allowlist extractor, UTC epoch conversion, date_status, gap/unresolved integration, and the offline fixtures including the allowlist and pinned-epoch cases.
• The route-scoped policy table ([research·architecture] One route-scoped market-context capability — shared observations, bounded research, no background news system #776 §B: observation mode / research mode / failure mode / persistence per route) written down as documentation.

Both are additive with no consumer. Land them behind zero call sites and no existing output
moves. One thing to verify at implementation time rather than assume: tests/test_consider.py
pins a literal evaluation_id digest, so confirm a new bundle field does not reach that seed.
(evaluation_challenge's docstring says presentation obligations deliberately stay out of it —
the same reasoning should apply, but it needs checking, not trusting.)

Must wait for M1 to pass

• Wiring forward_calendar into consider's payload, required_coverage, or the challenge block. [acceptance·P0] M1 vertical-slice reliability gate — repeatable completion before more capability #713/[QA·dogfood] Judgment-quality dogfood — does a real consider answer now carry a supported insight? #610 acceptance runs against a frozen SHA and counts must_state_total / required_coverage; changing them mid-acceptance invalidates the run in flight.
• Any card change — the snapshot card ([design·P1] The market read is bound to weekly_review, so the holdings-only cold-start user — the one its gate was written for — can never receive it #772 scenario A) and the weekly card. Card bytes are an acceptance surface.
• The [process·voice·P2] A live consider answer passes through no voice check — three output-voice violations shipped in one owner-live session with a fully green trace #782 gate itself, for the same reason: it changes what consider refuses.
• [feat·P1] A weekly review should read the week's market against the user's own holdings — prices, turning points, not only an index delta #683's trigger. Blocked on its own owner-live verdict, independent of M1.

Must wait for the #782 gate (per #781's ordering constraint)

• The researched half: L1/L2 forward events, and therefore index events and lockup expiries (§1), which are not obtainable deterministically at all.

---

7. Owner decisions

Four, with a recommendation on each.

D1 — Which provider accessor.
A: Ticker.calendar, 1 request/symbol. B: Ticker.info, 2 requests/symbol.
→ Recommend B. calendar renders the earnings epoch in the host machine's timezone (§1 trap 1) — the same book would show different earnings dates on the user's laptop and on CI — and it lacks isEarningsDateEstimate, which is load-bearing for the anticipation judgment (an estimated date means the schedule itself is unsettled, and it genuinely varies: AAPL/MSFT/BRK-B true, NVDA/KO/TSM false). Paying one extra request to not ship a timezone-dependent date is the right trade in a product whose numbers are its entire claim.

D2 — Does the gate see the prose, or only the structured case?
A: validate the --agent-case claims only. B: the same submission also carries the delivered text, and rules 2–3 run over it.
→ Recommend B. #782's three violations were all in prose; A catches zero of three. B costs no extra round trip — the resend already happens under rule 1, and it carries text the agent was about to show anyway. It also moves the delivered text into product code, which is the actual point of #782: the pairing exists today only in QA tooling, so a green QA trace coexisted with three violations.

D3 — What the user sees when the forward calendar is empty for their whole book.
A: say nothing. B: a disclosure key beside unclassified_drivers, and the card states it.
→ Recommend B. #772's acceptance criteria already demand it ("if the answer is nothing, the card says so and names what unlocks it"), and an all-ETF cold-start book is the common case, not the edge — every ETF and index tested returns a 404 (§1). Silence here reads as "nothing is scheduled", which is the same class of error as reading a throttled symbol as delisted (#687).

D4 — Scope of acquisition.
A: whole resolved universe. B: only the names the route will speak about (premise + cluster; diagnosed names; the concentration finding's own names).
→ Recommend B. At +2 requests/symbol, A roughly triples the acquisition pass for facts most of which no answer will mention. B keeps it at single-digit extra requests and is this issue's own stated principle.

Not offered as a choice, because they are already ruled: no background news system, no
second rule engine, no scheduler, no durable event store, no #683 trigger tuning before its
verdict, no model-graded judge on the live path.

---

Pointers

• [design·P1] The market read is bound to weekly_review, so the holdings-only cold-start user — the one its gate was written for — can never receive it #772 — scenario A is this issue's answer to yours: shape 2+3 combined, scoped to the names the card already named, plus D3 so market_context: None becomes a stated decision. Waits on M1 (card surface).
• [design·data·P2] The driver taxonomy has one level, so several holdings riding the same sub-driver inside one sector read as ordinary sector exposure #780 — not a prerequisite; §4 states what your ruling is worth in one sentence ("two holdings riding the same cycle report the same week" is unsayable without it) so the decision can be made on value rather than in the abstract.
• [feat·P1] A weekly review should read the week's market against the user's own holdings — prices, turning points, not only an index delta #683 — scenario C keeps your slice frozen. One new candidate trigger (a dated event inside a too_heavy name) is recorded for your owner-live verdict to weigh; nothing tuned.
• [process·voice·P2] A live consider answer passes through no voice check — three output-voice violations shipped in one owner-live session with a fully green trace #782 — §5 is the product half only: the gate lives in answer_provenance on the live path, three deterministic rules, cut-the-supplier tests, and the trade-consequence.md:328/338 opt-out flagged as the mechanism.

[atomchung]

Owner ruling — 2026-08-02: both halves ship together, and macro is not an ETF-only layer

Two decisions, the second of which changes the shape of the proposal.

1. Ship both halves together (option B)

The company-level dated facts and the macro calendar land as one capability, not as a company-first release with macro following. The owner rejected shipping the individual-stock half alone.

Consequence for sequencing: the live answer gate owed by #782 becomes a hard prerequisite for the whole capability, not for a later segment of it. Nothing forward-looking reaches a user before it exists.

2. Macro events are catalysts for individual holdings too — not an ETF fallback

總經也是個股的催化劑.

The previous framing split the world by holding type: company earnings for single names, macro events for broad-market ETFs which have no company calendar. That split is wrong. A rate decision or an inflation print moves a concentrated single-name position as directly as it moves an index fund — often more.

So the macro calendar is not the ETF branch of a two-branch design. It is a shared layer over every holding, and the ETF case is simply the one where it is the only layer available.

What this invalidates in the recorded design

• The three-scenario framing that assigned macro to the all-ETF holder is superseded.
• The ETF "no forward coverage" finding ([design·P1] What does this product mean by risk? Structure at one instant is the whole current answer, and the owner's definition includes what is about to happen to it #781 correction) stays true as a provider fact, but it stops being a user-facing scope limit: an all-ETF book still receives the macro layer like every other book.
• Any proposal shape that makes the macro layer optional, deferred, or segment-scoped no longer matches the ruling.

Open question this raises — deterministic or researched?

The design recorded macro events as researched, therefore behind #782. That may be wrong in the same way the index-event claim was wrong. FOMC dates and the statistical-release schedule are published annual calendars, not things that have to be found by search. If they can be carried as engine-owned dated data with a declared coverage window that fails closed past its end, the macro layer is deterministic and gets a validator like every other engine fact — which is strictly better than routing the product's most attention-getting content through its least-gated path.

This is to be measured, not assumed. It does not change ruling 1: the gate is a prerequisite either way, because the anticipation judgment on top of these dates is agent prose regardless of how the dates arrive.

[atomchung]

Revision 1 to the convergence proposal — owner rulings of 2026-08-02

Amends comment 5156586064; that comment stands as written and this records what changed
rather than rewriting it. Two rulings landed, and the second overturns the scenario framing I
proposed. A third thing I was asked to measure overturns a classification I made myself.

---

Ruling 1 — both halves ship together, and the gate becomes a prerequisite for all of it

Company-level dated facts and the macro calendar are delivered together. No "company layer
first, macro later".

Consequence, which is the part that changes the plan: #782's live-answer gate is promoted
from a prerequisite for the researched half to a prerequisite for the entire capability. No
forward-looking content reaches a user before the gate exists. §6's "can start now" list is
unchanged — the acquisition layer has no consumer and moves no output — but the whole
delivery surface now sits behind the gate, not just L1/L2.

---

Ruling 2 — macro is a shared layer over every holding, not the ETF branch

Owner's words: macro is a catalyst for individual stocks too.

My §4 split the world by holding type — equities get company events, broad-market ETFs have no
company calendar so they get macro. That split is wrong. A rate decision or an inflation
print does not hit a concentrated single-stock position less than it hits an index fund;
usually more, because the concentrated position has no diversification absorbing it.

So the corrected architecture is one layer over another, not two branches:

macro layer      — applies to every holding in the book, always
company layer    — additional, and only where the instrument has a published company calendar

An all-ETF book is not "routed to macro". It is a book where the macro layer happens to be the
only populated one. The §1 measurement that ETFs and indices return zero company-level
forward coverage stands as a provider fact — but it is no longer a limit on what that user
receives, only on which layer carries it.

Any shape that makes the macro layer optional, deferred, or segment-conditional is out of
compliance with this ruling, including the one I proposed.

---

Measurement — macro calendars are deterministic, and my classification was wrong

I had filed macro events as researched (Layer 3), which put them behind #782 for the wrong
reason. I was asked to test that rather than reason about it. Measured 2026-08-02.

FOMC — published ~17 months ahead

federalreserve.gov/monetarypolicy/fomccalendars.htm, HTTP 200:

• 2026: all 8 meetings published — Jan 27-28, Mar 17-18*, Apr 28-29, Jun 16-17*, Jul 28-29, Sep 15-16*, Oct 27-28, Dec 8-9*
• 2027: all 8 meetings already published — Jan 26-27 through Dec 7-8*, plus a footnote naming a January 2028 meeting
• * marks meetings carrying a Summary of Economic Projections — a published attribute, not an interpretation
• No ICS, JSON, CSV or XML link anywhere on the page. HTML only.

(An earlier parse of mine said 9 meetings for 2027. Re-checking the panel boundary showed the
9th was the footnote text. Recording it because it is the same class of error as everything
else on this list.)

BEA — machine-readable, current, but only ~5 months ahead

apps.bea.gov/API/signup/release_dates.json, HTTP 200, no key required, 31 series:

Release	Future dates as of 2026-08-02
GDP	2026-08-26, 09-30, 10-29, 11-25, 12-23
Personal Income and Outlays (PCE)	same five
International Trade in Goods and Services	2026-08-04, 09-03, 10-06, 11-04, 12-08
Corporate Profits	four

The payload carries its own provenance stamp — file_last_updated: 2026-07-13T08:00:42 —
which is precisely the field a coverage-window design needs. Furthest future release across
all 31 series: 2026-12-23. The horizon is calendar-year-bounded, so it is ~5 months now and
will be ~2 weeks in December.

BEA's own ICS feed is dead, and that is the most important finding here

The same page advertises /news/schedule/ics/online-calendar-subscription.ics. It fetches
200, parses cleanly, contains 49 well-formed events — and every one of them is 2025.
Range 2025-01-07 → 2025-09-29. Zero future events.

So one agency publishes two official feeds; the JSON is current to three weeks ago and the
calendar-native one is eleven months stale. A runtime fetcher that reasonably preferred "the
ICS calendar" would have returned an empty forward set and the product would have said
nothing is scheduled — the exact shape of #687, where a throttled symbol read as delisted,
transplanted onto macro. A well-formed response is not a live one.

BLS — feed documented, unverifiable from here

BLS documents an ICS at bls.gov/schedule/news_release/bls.ics. Every BLS URL I tried returns
403 — the schedule HTML, the 2027 page, and the ICS — under both curl and WebFetch, with
and without a browser UA. That is an environment/IP block, not evidence the feed is bad. I
could not verify its contents and am not going to claim otherwise. It does establish that
runtime fetching of macro schedules is environment-dependent in a way price fetching is not.

Verdict

Deterministic, not research. CPI/GDP/PCE release dates and FOMC meeting dates are published
annual calendars issued by the authority itself, 5–17 months ahead, with published attributes.
Nothing about them requires a search. My Layer-3 classification was wrong in the same way the
"index events are deterministic" line in #781 was wrong, and in the same direction: assumed
rather than measured.

But the acquisition mechanism is not a runtime fetch. Three measured reasons: no single
feed covers all three sources; the feeds are heterogeneous (HTML / JSON / ICS) and one is
silently stale; and one issuer is unreachable from some environments entirely. So the
coordinator's hypothesis is the right one, and the evidence supports it more strongly than
convenience would:

Ship a curated data file with an explicit coverage window; fail closed past it.

Coverage windows are per-source, not global

The measurement makes a single global window wrong. FOMC is covered to ~2027-12, BEA to
2026-12-23. A global window would either throw away a year of FOMC coverage or assert BEA dates
it does not have. So the file carries one covers_through per source, and the engine drops
that source's events past its own boundary while others keep answering.

Mechanically testable, and it fails in the honest direction: move the clock past a source's
covers_through and its events must disappear from output, not persist as stale dates. Cut
the coverage check and that test goes red. This also gives the freshness obligation a home that
is not human memory — see D5.

No precedent exists in this repo for a shipped data file with a coverage window (I grepped;
there is none), so this is a new pattern and should be reviewed as one.

The gate is still a prerequisite

Determinism changes where the dates come from. It does not touch the judgment layered on top
— "is this event a surprise relative to what your record shows" is agent prose either way.
Ruling 1 is unaffected, and §3's support/mark/bound structure applies to macro events
unchanged.

---

Revised scenarios

Replacing §4. Every scenario now has the macro layer; the company layer is additive.

A. Cold-start, holdings snapshot only (#772)

Today: the card finds the book is one bet and says nothing about what moves it.

After: the macro layer applies to the whole book regardless of what is in it —

Two dated things sit in front of this book before your next look: the FOMC decision on
2026-09-16 and the PCE release on 2026-08-26. Your largest holding also reports on
2026-08-27, and it is 34% of what you handed over.
My read, not a fact: a concentrated book does not get to average a rate decision away the
way a diversified one does — the same event lands harder here, and that is a property of the
shape you showed me, not a forecast about the outcome.

For an all-ETF book the first sentence is identical and the company sentence is absent,
with one narrow note: no company-level calendar is published for these instruments. That is
now a coverage footnote, not a reason the user gets less.

B. Bringing one trade to consider

Today: correct post-trade weights, no mention of anything scheduled.

After:

That takes it to 31% of the book, past your 25% cap. The company reports in 9 days
(2026-08-11, confirmed), and the FOMC decides on 2026-09-16, inside the horizon you
gave this position.
My read, not a fact: your stated reason mentions neither. Sizing up past your cap in front
of two dated events you have not accounted for is the thing to settle before the size — I
can tell you they are scheduled, not how either resolves.

C. Weekly review (#683)

Today: the companion fires on too_heavy × positive frozen VIX delta and its watch line
carries no date.

After: same frozen window, same gate, dated watch:

Before your next review: PCE on 2026-08-26, and [name] reports 2026-10-20.

Recorded for #683's owner-live verdict, not proposed as a change: the macro layer supplies a
trigger candidate that is a published date rather than a market reading, which is a second
option beside VIX.delta > 0 for that issue's noise question.

---

What this does to the owner decisions

	Status
D1 — .info over .calendar	Unaffected. Company layer only. Recommendation stands.
D2 — does the gate read the prose, or only the structured case?	Live, and now weightier. Ruling 1 makes the gate a prerequisite for the whole capability, so its scope decides the whole thing. Recommendation still B (read the prose): all three #782 violations were prose, so a case-only gate catches zero of three.
D3 — what the user sees when the forward calendar is empty	Retired by ruling 2. "Your book has no forward calendar" is no longer a state a user can be in — the macro layer always delivers. What survives is not a choice: a narrow, mandatory coverage note that no company calendar is published for those instruments.
D4 — acquisition scope	Survives, narrowed to the company layer. Macro is book-wide by construction and costs zero runtime requests as a shipped file, so it no longer trades against per-symbol cost. Recommendation unchanged for the company layer.

Two new decisions, both created by the measurement:

D3′ — how far ahead does the macro layer look?
A: everything inside the coverage window (up to ~17 months of FOMC).
B: a bounded horizon — the next occurrence per source, or events within the position's own recorded horizon, whichever is shorter.
→ Recommend B. Option A turns the card into a calendar dump and re-creates the news-feed shape #776 exists to prevent; the ranked-relevance principle in this issue's own Morning Notes audit says the same thing. B keeps it to a small number of dated items that can actually change a check.

D5 — what keeps the shipped calendar fresh?
A: fail closed at the coverage boundary; a maintainer notices and refreshes.
B: fail closed and a test that goes red when any source's remaining coverage drops below a threshold, so the refresh is forced before users silently stop seeing macro.
→ Recommend B. Under A the failure is invisible: the product quietly stops mentioning FOMC and nobody finds out, and BEA's window shrinks to ~2 weeks every December by construction. B is the agent-free maintainer guard this repo already prefers over remembering. The threshold is the owner-tunable number; 60 days is my suggestion.

---

Sequencing, revised

Can still start now (no consumer, moves no output): the company-layer acquisition from §1,
plus the macro data file, its per-source coverage windows, the fail-closed check, and the
offline fixtures for both. All of it is inert until something reads it. Unchanged from §6.

Now behind the #782 gate — all of it, per ruling 1: every delivery surface. Company layer,
macro layer, consider payload, cards.

Still behind M1 (#27/#713, with the #579 rule-effect repair on another line): anything
reaching consider's payload, required_coverage, the challenge block, or card bytes — the
acceptance run counts exactly those. And #683's trigger stays frozen pending its own verdict.

Removed from the plan: the "researched half opens after the gate" staging for macro. Macro
is deterministic, so it ships with the company layer under ruling 1. L1/L2 research, index
rebalance events and lockup expiries remain researched and remain last — those three were
measured as genuinely unavailable deterministically.

Unchanged: no background news system, no second rule engine, no scheduler, no durable event
store, no model-graded judge on the live path, and nothing in this proposal touches fomo QA.

[atomchung]

Correction — the "silently stale feed" finding does not reproduce; the conclusion survives on one pillar, not two

The revision above rests the shipped-file recommendation on two measured pillars. Independently re-measured by the orchestrator on 2026-08-02, one of them is wrong, and it is the dramatic one.

What does not reproduce

"BEA's own advertised ICS fetches 200 and parses cleanly into 49 well-formed events — all of them 2025, zero future … A runtime fetcher preferring 'the ICS' would have returned empty and the product would have said nothing is scheduled — #687's failure shape transplanted onto macro."

Fetching the ICS that bea.gov/news/schedule actually links (/news/schedule/ics/online-calendar-subscription.ics):

bytes: 31129 | VEVENT count: 119 | DTSTART parsed: 119
range: 2025-01-07 -> 2026-12-23
by year: {2025: 56, 2026: 63}
FUTURE (>= 2026-08-02): 21   first five: 2026-08-04, 2026-08-26, 2026-08-26, 2026-09-03, 2026-09-24

The feed is current, not eleven months stale. It carries 21 future events — including 2026-08-26, the exact PCE date the revision uses in its own consider scenario. Cross-check: the BEA JSON independently ends at 2026-12-23, the same horizon as the ICS. Two independent endpoints from the same issuer agree, which is what makes the null result here trustworthy rather than a second bad probe.

The #687 failure shape transplanted onto macro argument is therefore withdrawn. No measured evidence supports it.

What does reproduce

The FOMC pillar holds, and it was the stronger one:

federalreserve.gov/monetarypolicy/fomccalendars.htm  HTTP 200, 164427 bytes
machine-readable links (.ics/.json/.xml/.csv): NONE
years with meeting tables: 2021 … 2027

Zero machine-readable feeds on the page, and meeting tables published through 2027. BLS remains unverified from this environment (403), and is neither evidence for nor against.

What the correction changes

The recommendation stands, on this reasoning instead:

The single most decision-relevant macro source publishes no machine-readable feed at all while publishing roughly seventeen months ahead. That combination — must-scrape-HTML at runtime, versus a long stable horizon — is what favours a shipped file. Heterogeneity across three issuers and one unreachable issuer are supporting reasons.

Two consequences of dropping the false pillar:

1. Per-source windows survive, for a different reason. Not "sources differ in staleness" — measured, BEA is not stale. It is "sources differ in availability": FOMC has no feed, BEA has two good ones, BLS is unreachable here. A design that treats them identically is wrong either way, but the reason has to be stated correctly or the next reader re-derives a false risk.
2. D5 inverts. The revision framed staleness as an upstream risk the shipped file protects against. Measured, it is the opposite: the shipped file is the thing that goes stale, while BEA's feeds are current. That makes D5 (a test that reddens below a coverage threshold) more necessary, not less — it is the only thing standing between a shipped file and a product that silently stops mentioning FOMC.

Everything else in the revision — macro as a shared layer, both halves together, the #782 gate bounding the delivery surface, the marked-and-anchored surprise judgment, FOMC's 2027 horizon, BEA's keyless JSON through 2026-12-23 — re-measured or re-read as stated and stands.