Skip to content

feat(context): direct O&M messages + episodic history for notify judgment and staff/customer chat - #204

Merged
1vav merged 1 commit into
mainfrom
feat/om-episodic-grid-context
Sep 20, 2026
Merged

1vav merged 1 commit into
mainfrom
feat/om-episodic-grid-context

Conversation

@1vav

@1vav 1vav commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Grid-analysis chat only reached O&M Telegram chat via an on-demand, staff-only tool the model had to think to call — a real conversation showed alarm data surfacing first and the O&M-reported root cause only after being asked to check for it. Notify's alert-judgment prompt already direct-fetched O&M messages but had no episodic distillation at all, and it's a single-shot LLM call with no tool access, so a tool-based fix was never an option there.
  • New chat_orchestrator/orchestrator/services/grid_context_feeds.py, shared by both flows: O&M messages (staff-only, matching customer_get_grid_chat_chronology's own visible_to_customer=False) and episodic distillation (safe for customer scope too — reuses EpisodicProvider's own access gate) are now fetched directly and bounded by count/char caps, bypassing the knowledge-module system's shared token budget, which isn't wired into the notify flow at all.
  • O&M per-message truncation moves from 500 to 1000 chars in both flows (free-text field reports read worse cut off at 500 than bot-rendered prior-alert content, which keeps the original 500 cap).
  • providers_episodic.py gets reusable resolve_episodic_anchor/fetch_distillation_summary/fetch_episodic_summary functions so neither new call site needs a KnowledgeModule just to reach the same distillation EpisodicProvider already serves — EpisodicProvider.resolve() itself now delegates to fetch_episodic_summary, same behavior, less duplication.
  • Short prompt-text additions in staff.system, customer.system, and ticketing.correlation explaining the new context blocks. Note: staff.system and customer.system are live-served from a Google Doc / DB override respectively in production — these bundled-file edits are the fallback copy, not what's live. The live doc/DB versions need a separate update after this merges (tracked outside this PR).

Test plan

  • pytest — full chat_orchestrator suite (2539 passed; 1 pre-existing unrelated failure confirmed present on main too)
  • pytest shared/tests/ (921 passed; 1 pre-existing unrelated failure confirmed present on main too, caused by stale local .worktrees/ dirs)
  • New tests: test_grid_context_feeds.py, test_prepare_context_grid_feeds.py, plus additions to test_alert_judgment_context.py, test_correlator.py, test_notify_alert_delivery_repository.py, test_providers_episodic.py
  • prompt_checksums.json regenerated and diff reviewed — only the three touched prompts changed
  • ruff check clean
  • pre-commit run --all-files clean (test-wiring, loguru guard, operator-data scrub all pass)

🤖 Generated with Claude Code

…cess to O&M messages and episodic history

Grid-analysis chat only reached O&M Telegram chat via an on-demand,
staff-only tool the model had to think to call -- a real conversation
showed alarm data surfacing first and the actual (O&M-reported) root
cause only after being asked to check for it. Notify's alert-judgment
prompt already direct-fetched O&M messages but had no episodic
distillation at all, and runs as a single-shot LLM call with no tool
access, so a tool-based fix was never on the table there.

Adds shared grid_context_feeds.py, reused by both flows: O&M messages
(staff-only, matching the existing chronology tool's
visible_to_customer=False) and episodic distillation (safe for customer
scope too, reusing EpisodicProvider's own access gate) are now fetched
directly and bounded by count/char caps rather than the knowledge-module
system's shared token budget, which isn't wired into the notify flow at
all. Bumps O&M per-message truncation from 500 to 1000 chars in both
flows -- free-text field reports read worse cut off at 500 than
bot-rendered prior-alert content does, which keeps the original cap.

Extends providers_episodic.py with reusable anchor-resolution/fetch
functions (resolve_episodic_anchor, fetch_distillation_summary,
fetch_episodic_summary) so neither new call site needs a KnowledgeModule
just to reach the same distillation EpisodicProvider already serves.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@1vav
1vav merged commit 02a1b02 into main Sep 20, 2026
7 checks passed
@1vav
1vav deleted the feat/om-episodic-grid-context branch September 20, 2026 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant