Operations overview

Operations Overview is the app’s cross-organization feature page. It brings together the work package lifecycle, review backlog, recorded operations, planned versus actual task hours and an exception queue. Research Coordinator can use it to decide which package needs a review handoff. Operations Analyst can use the same context to investigate a receipt whose result needs attention. It is a way into the underlying records, not a substitute for reading the package and decision that explain a case.

Operation receipts sit under a work package. They retain an operation key, action, expected revision, result state and occurrence date, with external and effect references where present. A receipt can be Pending, Completed, Failed or needs review. When a result needs review, the failure reason and references give the analyst a starting point for reconciliation. The recorded operation should be compared with linked effects and any configured authoritative source before it is treated as complete.

• Lifecycle. Research Coordinator follows planned, active, review and accepted package work across organizations.
• Effort. Operations Analyst compares task hours to see which packages warrant a closer look.
• Exceptions. Operations Analyst inspects receipts marked Failed or needs review and traces their parent package and effect references.

Agree who watches the overview each day and who owns an exception once it is found. Define the operating meaning of a review backlog and the point at which a coordinator asks a reviewer to act. Use the same package number in meetings and follow-up notes so that an exception can be traced to the right parent. A task-hour difference is a prompt for investigation; acceptance still depends on the package review.

If an external source is used, agree which source is authoritative for each external reference and how an analyst can check it. An operation key should identify a guarded action consistently across retries. Review a discrepancy with the package revision and linked effect records before changing the result state.

An analyst sees a needs review receipt attached to a package that appears accepted. The receipt says which action ran, the expected revision and when it occurred. The analyst opens the package, checks its actual revision and acceptance date, then reads the review decision and relevant attachments. If an external reference is present, the analyst compares it with the configured source and the linked effects. The discrepancy stays visible until the evidence agrees.

The coordinator can examine the same package through the review backlog and task-hour comparison. If actual hours are still incomplete, the coordinator asks the owner to correct progress before requesting acceptance. This keeps the overview useful as a daily queue and preserves the underlying records as the decision trail.

• Operation Exceptions — Failed and review-needed receipts with parent package and reason.
• Active Work Packages — Lifecycle work that can be checked by owner and due date.
• Task Effort — Planned and actual task hours for investigating progress.

Use operation reconciliation and reports for the operating review.