> ## Documentation Index > Fetch the complete documentation index at: https://f4c7a9e2d8b1-docs.tenzo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Resume Review module > Work progress, retry behavior, and workflow handoffs for Resume Review V1 **Restricted Access**: This documentation is only accessible to @tenzo.ai and @salv.ai email addresses. ## Responsibility Resume Review owns the durable lifecycle for deciding whether an application can continue to AI Interview. Its **work runner** loads the workflow's configuration snapshot, evaluates the resume, persists the local result, and returns a typed handoff result to the workflow coordinator. It is not a private hop executor. See [Module and stage-orchestrator contract](/internal/modules/orchestrator-contract). The module must not start AI Interview or apply cross-module gates. Those actions belong to the coordinator. V1 `continue_handoff` still activates Interview today; TEN-1315 inverts that. ## Work progress Sit-able stages are on the compiled Resume Review module (`AWAITING_RESUME_REVIEW`, `RESUME_REJECTED`, and the non-sit-able Pass leave door). The values below are lease and work progress on the module run, not a second stage language. | Progress | Meaning | May move to | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | `pending` | The module exists and is ready to be claimed. No evaluation result is authoritative. | `evaluating`, `bypassed` | | `evaluating` | A worker holds a lease and is evaluating the snapshotted inputs. | `passed`, `rejected`, `review-requested`, `bypassed` | | `passed` | Resume Review permits the workflow to continue. | Terminal | | `rejected` | Resume Review closes the workflow with a negative decision. | `review_requested`, `overridden` | | `review-requested` | Automated evaluation cannot make the final decision and the workflow is held for human review. | `overridden` | | `overridden` | An authorized human decision resolves a rejection or review hold. The stored override outcome determines whether the workflow continues or closes. Direct Progress to Interview from a rejection is `rejected` → `overridden` (pass). | Terminal | | `bypassed` | Resume Review does not make a rejecting decision because policy disables it or an evaluation prerequisite such as a resume or requirements is absent. | Terminal | The progress value and the decision payload are separate. In particular, `overridden` records how the decision was reached, while its typed outcome records pass or reject. `bypassed` records an explicit non-rejecting outcome rather than treating a missing prerequisite as a successful score. ## Fixed V1 flow ```text theme={null} pending ────────────────> evaluating ─────> passed │ ├───────────> rejected ──┬──> review-requested ──> overridden │ ├───────────> review-requested ──┘ ▲ │ └───────────> bypassed │ └────────────────────> bypassed │ rejected ─────────────┘ (direct override) ``` `passed`, a continuing `overridden` outcome, and `bypassed` are eligible for the coordinator's handoff to AI Interview. `rejected` and a closing `overridden` outcome close the workflow. `review-requested` is a durable hold and produces no handoff until an authorized override is recorded. Before every continuing handoff, the coordinator re-evaluates global gates. A locally successful Resume Review result therefore does not guarantee that AI Interview starts. ## Evaluation input The orchestrator evaluates only inputs referenced by the workflow's immutable configuration snapshot. The snapshot fixes the applicable Resume Review policy, requirements, thresholds, and other versioned decision inputs for the life of this module execution. Evaluation output records enough provenance to identify the snapshot and source artifacts used for the decision. A retry uses the same snapshot. It does not silently adopt edits made after the workflow started. ## Lease and retry semantics Claiming `pending` moves the module to `evaluating` with a bounded lease. The claim is atomic, so only one worker owns the active attempt. The worker must still hold that lease when it commits the evaluation result. If the lease expires before publication, another worker may reclaim `evaluating` and retry from the persisted snapshot. Reclaiming does not create a new logical module execution and does not erase prior attempt diagnostics. A stale worker cannot publish after the lease has been replaced. Retries are safe at every boundary: * Evaluation is repeatable against the same snapshot and source-artifact identity. * Result publication rejects stale stage or lease expectations. * External effects use stable idempotency keys. * A completed handoff is recognized from durable state rather than repeated. An operational failure remains retryable in `evaluating`; it is not converted into `rejected`. Business outcomes and infrastructure failures stay distinct. ## Atomic state and history Every Resume Review transition updates the current module row and appends its history event in the same transaction. History includes the prior and next stage, actor or lease identity, reason, attempt, configuration-snapshot identity, and decision provenance appropriate to the transition. When a closing result is published, the same transaction projects onto `TenzoStage` (`RESUME_REJECTED` / `RE_REVIEW_REQUESTED`) and runs that stage's existing action phases: critical actions before commit, post-commit and best-effort after. A projection CAS miss rolls the module transaction back; a worker that has lost the lease or revision must not disqualify. Continuing outcomes persist first (`passed` / `bypassed` / passing `overridden`). The coordinator then activates the native AI Interview module, which writes `OUTREACH` or parks at `SKIP_OUTREACH` when AI interviews are disabled. That handoff is eventually consistent: there is no atomic next-module insert or separate global workflow row in V1. A failed Interview activate leaves the durable Resume Review terminal in place so a recovery scan can retry. Scoring terminals retry while CCI is still `AWAITING_RESUME_REVIEW`. A passing override may still be on `RESUME_REJECTED` or `RE_REVIEW_REQUESTED`. Repeating handoff is idempotent once CCI is already `OUTREACH` or `SKIP_OUTREACH`; activate still ensures the Interview run exists. ## `TenzoStage` projection Resume Review contributes to the existing `TenzoStage` view so current application lists, filters, ATS behavior, and automation continue to receive the stage vocabulary they expect. The projection is derived from durable module and global workflow state and may collapse multiple local stages into one compatibility value. Resume Review transition validation never reads `TenzoStage` as its local source of truth. `TenzoStage` is still used as a global concurrency fence: if a closing projection or continuing publication loses its expected-stage comparison, the module transaction rolls back and the stale worker cannot authorize a different transition. ## Operational checks When a Resume Review workflow appears stuck, inspect: 1. the current local stage and latest module-history sequence; 2. the active lease owner and expiry when the stage is `evaluating`; 3. the configuration-snapshot and source-artifact identities; 4. the typed terminal or override outcome; 5. the global gate and handoff history; and 6. the derived `TenzoStage` projection last. Do not infer module progress from queue delivery count or repair it by editing the compatibility projection.