Operation Management

AI-powered root-cause analysis for "why was the system slow?" It cross-references Activity Reports with Audit Records, Data Management logs, Job Console executions and Application Stats to correlate slow windows with the rules, jobs, and users active at the time — and explains its findings in plain language, with the evidence behind the conclusion shown alongside.

• One timeline — Audit Records laid over the Activity Report metrics chart, with a scrollable event feed and the AI chat sitting on top of both.
• Windowed context — the agent works in a two-tier window it can re-scope itself; the active window is shown as a chip and can never exceed seven days.
• Jobs in the picture — a weekly digest, job runs with audit de-duplication, a job-execution section that bounds its own error logs, and scheduled-job awareness, so a slowdown that coincides with a scheduled job is named as such.
• Incremental audit — audit history syncs as deltas through the same local store the Audit Logs window uses, so a re-open does not re-download the month.

A hundred and twenty metrics from Oracle's own Activity Reports, charted over time with a forecast overlay. Growth becomes a trend you can act on, not a surprise at capacity review.

Every Calc Manager rule in the application, listed and worked with at a higher level:

• Analyze existing rules — graded for complexity, FIX-block structure and conformance to your house style, with logic issues and performance anti-patterns called out.
• Generate new rules from a plain-English description, written against the live outline and reusing the application's own runtime prompts and substitution variables — diffable, lintable, and exportable straight into Calculation Manager.
• Revise a deployed rule — say what should change and the whole rule comes back, with the same repair and lint pass.
• Translate any rule into a plain-English explanation of inherited code nobody documented.

View, edit and delete sub vars across the application in a single grid. Deleting a variable removes it from EPM, not just from the grid.

Downloads the job console execution records and reports how jobs actually ran over 7, 30 and 60 days — by rate, not raw count: runs per day, success rate, failures grouped by job with the reason attached, total run time and the timing trend per job. The history is kept locally and is what the Job History report module reads, so nothing re-runs on the pod.

Three more tools in this group have dedicated guides: the Job Console — now the Job Orchestrator, with runtime prompts answered through real member pickers and a sequence tray — Audit Logs, rebuilt on an incremental local store, and the Snapshot Manager, which now carries Archived Backups and the type-to-confirm Restore Environment.