Integrate NLG Processing into Report Orchestrator

[klingonaston]

This PR integrates the Natural Language Generation (NLG) engine into the report orchestration flow, ensuring that raw agent data is processed into human-readable text.

Changes

• Modified orchestrator.py to include a new step for NLG processing.
• Ensures validated agent data is passed to the NLG engine for text generation.
• Stores the generated narrative sections under nlg_sections within the report storage structure.
• This update streamlines the report generation pipeline by automating the conversion of data into descriptive text.

Summary by CodeRabbit

• Refactor
  • Optimized internal data structure organization in the reporting pipeline by standardizing content section naming and updating data payloads for improved consistency and maintainability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A variable holding generated NLG content is renamed from nlg_outputs to nlg_sections in the orchestrator module. The renamed variable is propagated through function arguments and added to the in-memory reports update payload alongside existing fields.

Changes

Cohort / File(s)	Summary
NLG sections refactoring backend/app/core/orchestrator.py	Rename nlg_outputs to nlg_sections; update build_final_summary argument; add nlg_sections to in_memory_reports payload

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Verify all references to the old variable name have been updated
• Confirm the nlg_sections addition to the payload doesn't introduce schema conflicts
• Check that downstream consumers of in_memory_reports handle the new field appropriately

Possibly related PRs

• ChainReport-API#44: The nlg_sections rename aligns with the NLGEngine API that produces per-section outputs via generate_section_text.
• ChainReport-API#48: Both PRs modify orchestrator.py's handling of NLG outputs and restructure the in-memory report payload.

Poem

🐰 Sections scattered, now gathered tight,
nlg_outputs renamed—clarity's light!
From orchestrator's heart, the data flows,
In-memory reports blooming like prose. 🌸

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: integrating NLG processing into the report orchestrator, which aligns with the code modifications adding NLG sections to the orchestration flow.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/orchestrator-nlg-integration

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

backend/app/core/orchestrator.py (1)

110-127: NLG generation and summary wiring look correct

The new nlg_sections flow (generate_nlg_outputs(aggregated_data) → build_final_summary(nlg_sections, scores)) is type‑ and shape‑compatible with ReportNLGEngine and ReportSummaryEngine, and should produce the expected section‑wise narratives feeding into the final summary. If you want extra clarity later, you could consider aligning naming across modules (e.g., parameter name in build_final_summary), but it’s not required functionally.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f7870be and 5f52909.

⛔ Files ignored due to path filters (6)

• backend/app/core/__pycache__/orchestrator.cpython-313.pyc is excluded by !**/*.pyc
• backend/app/services/nlg/__pycache__/__init__.cpython-313.pyc is excluded by !**/*.pyc
• backend/app/services/nlg/__pycache__/prompt_templates.cpython-313.pyc is excluded by !**/*.pyc
• backend/app/services/nlg/__pycache__/report_nlg_engine.cpython-313.pyc is excluded by !**/*.pyc
• backend/app/services/summary/__pycache__/report_summary_engine.cpython-313.pyc is excluded by !**/*.pyc
• backend/logs/app.log is excluded by !**/*.log

📒 Files selected for processing (1)

• backend/app/core/orchestrator.py (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

backend/app/core/orchestrator.py (2)

backend/app/services/nlg/report_nlg_engine.py (1)

• generate_nlg_outputs (24-72)

backend/app/services/summary/report_summary_engine.py (1)

• build_final_summary (48-72)

🔇 Additional comments (1)

backend/app/core/orchestrator.py (1)

129-136: No compatibility issues found—persist nlg_sections as intended.

Verification confirms no downstream code expects a legacy nlg_outputs key on report objects. The API endpoint /reports/{report_id}/data returns the full report dict, which will now safely include the new nlg_sections key alongside status, data, and scores. Tests and endpoints expect the structure you've implemented.

[felixjordandev]

the integration of NLG processing should really streamline the report workflow... merging this! 👍