Manager Review: Approving, Sending Back and Overriding

In Review is the state where the run’s output becomes a defensible record. The pipeline has screened the population, computed the range, and written the conclusion; the manager’s work is to stand behind that record — to verify the dispositions, to correct the ones that are wrong, and then to decide: approve it, or send it back with the reasons stated. This page is the state, the work surface, and the three actions it carries.

What lands in the state

The study arrives in In Review because the pipeline completed — it is the only thing that can put it there, and no role can push a study in manually. At arrival the record is settled:

• The comparables grid — the screened population with a verdict per company: accepted, rejected, flagged, or almost-accepted — and the recorded reason for each. The flags are the companies with no usable description, held for human review rather than silently kept or dropped.
• The statistical results — the arm’s length range for the chosen PLI, the tested party’s position inside it, the pool statistics that produce the range, and the conclusion.
• The supporting record — the parameters as configured, the dump and its column mapping, the per-comparable screening reasoning.

in_review_at is stamped at arrival; it starts the dump-retention clock that governs how long the raw dump is kept for report rebuilds.

In Review is also the responsible role’s state: MANAGER. The study sits there until a reviewer decides.

Arrival is pushed only in one case: when the study has an assigned manager, the pipeline completion emails them the ready-for-review hand-off. With no manager assigned — or when the creator is that manager — nothing is sent, and the study simply appears in the queue and on the In Review tab.

Who can review

Entering the review workspace, recording an override, approving and sending back are reviewer rights, and they are not the same set:

• Review workspace and overrides: Manager, Firm Admin, Superadmin. The workspace button does not render for anyone else, because the API refuses their edits with a 403.
• Approve and send back: Manager, Partner, Firm Admin, Superadmin. So a partner can decide a study in review but cannot re-cut the grid from here — the partner’s own state is further down the path.
• Analysts are read-only in this state. Their lever is the data and the configuration, exercised once the study is sent back.

The work surface

The reviewer reads the grid the way the record will be read:

• The accepts — the company is genuinely comparable against the tested party’s profile, and the reason says so with the evidence behind it.
• The rejects — the reason is specific and factual, and the company is genuinely out.
• The flags — the borderline companies with the difference stated and how it is handled.
• The range — the tested party’s position against the pool, with the statistics that support the conclusion.

The grid is where the study becomes defensible: the range is downstream of the dispositions, and the dispositions are the record.

Approving: what the approval actually does

Approval is not a rubber stamp and it is not instantaneous in what it produces. When the reviewer approves a study in review:

1. The study stays in In Review. The click writes a REPORT_REQUESTED audit entry — approver, role, timestamp, notes — and dispatches the Excel report job. It does not write a transition to Report Generated, because at that moment no report exists.
2. The workbook is built by a separate task, off the settled record: the grid with its effective dispositions, the statistics, the parameters, the conclusion.
3. The transition happens on success. When the file is stored, the report task sets REPORT_GENERATED and writes the real STATUS_TRANSITION entry against the approver. The approver also gets a best-effort email — report-ready or report-failed — with a deep link to the study.
4. A failed build changes nothing about the state. The study is still In Review, the job carries the error, and the approval can be re-tried. There is no half-advanced state to revert.

While a report job is active, a second approval on the same study is refused — duplicate dispatch is blocked under the row lock, not by the UI alone.

From Report Generated the study needs its formal document before sign-off; see Partner Sign-Off and Final Archiving.

Sending back: the rejection and its reasons

A send-back is the reverse transition In Review → Rejected, and it is the reviewer’s other decision:

• The notes are mandatory. An empty justification is refused with a 422; a blank reason would land blank in the audit log and in the analyst’s notification, which a defensibility product cannot carry.
• The record. The reasons are stored on the transition’s audit entry, and the audit taxonomy reserves REJECTION_REASON_CHANGE for amending them.
• The hand-off. The rejection sends a best-effort email to the assigned analyst — the creator if nobody is assigned — carrying the reviewer’s notes. It is skipped when the rejecter is also the recipient, and a failed send never fails the transition.
• The return path. Re-submission goes straight back to In Review (REJECTED → IN_REVIEW); no re-run is required, because the analysis exists. The reviewer sees the study again with the prior rejection and its reasons in the trail.

Overriding comparables during review

The reviewer does not have to take every verdict the screening produced. While the study is in In Review, a Manager, Firm Admin or Superadmin can override a comparable:

• ACCEPT or REJECT forces the effective verdict; clearing the override reverts the company to the screen’s recommendation. The single-row edit is a PATCH on the comparable; the batch is committed on Finish Review.
• Only in this state. The same call on a study that has already moved on is refused with a 409, as is a stale row — if another reviewer changed the comparable first, the version check fails and the grid reloads rather than clobbering their work.
• Every override is recorded. An REVIEWER_OVERRIDE audit entry names the comparable, the previous and new verdict, the reviewer and the reason, and a manager-override event appends to that comparable’s evidence timeline.
• The reason field is mandatory at the API. A verdict submitted without a reason, or without the row version you loaded, is refused rather than stored, so every override entry in the ledger explains itself.
• The record recomputes. Committing overrides recomputes the dependent values — effective verdicts, counts, statistics, conclusion — and the workbook rebuild applies the reviewer’s record, not the screen’s first pass. Rows the reviewer left undecided stay in their own buckets in the deliverable: they are excluded from the statistics, never rewritten as rejections nobody made.

The override discipline — what a defensible rationale is and the ledger it lands in — is in Overrides and Rationale.

The queue behind the state

Studies in In Review are the manager’s queue, and it is a filtered view of the same states, not a separate system:

• The dashboard approval queue for a manager is built from the studies sitting at In Review, scoped to what the manager can see.
• The study list’s In Review tab — reachable from My Tasks / Approvals — lists the same studies, and the tab set is identical for every role.

Details are in My Tasks and Approvals.

FAQ

Can an analyst override a comparable during review? No — the override right is a reviewer right (Manager, Firm Admin, Superadmin), exercised while the study is in review. An analyst’s lever is the data and the configuration, addressed when the study is sent back.

Can a partner override? No. A partner may approve or send back at In Review — those gates include the partner role — but the override endpoints do not, and the review-workspace entry follows the endpoints.

Does approving regenerate the analysis? No. The analysis is the settled record from the run; approval builds the workbook deliverable from it. Changing the analysis is a re-run, which happens on a study that has been sent back — not at approval.

Is there a notification when the report is ready? Yes, on a best-effort basis: the approver is emailed when the workbook build finishes or fails, with a link to the study. It fires regardless of the email preference toggles on the profile page — those are stored on the account but no send path reads them. Email is not a workflow gate: the state and the job record are the authority, and an undelivered mail leaves both intact.

What if the reviewer disagrees with the rejection reasons they wrote? The reasons live on the audit trail, which is append-only — they are not edited away. The history is the point.