Skip to main content
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. 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. 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

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.