# Pass the business receiving check after the technical tests pass

Manual worksheet; invented situation, no automatic product import.

## Owned work

- State production responsibility — Delivery lead — Engineering owns implementation without inheriting Finance’s acceptance role.
- Agree receiving examples — Finance reviewer — Full, zero and partial-refund examples exercise the actual business question.
- Return the bounded gap — Engineering owner — The partial-refund correction is linked to Finance’s evidence and recheck.

## Workflow questions

### Does naming a reviewer mean they own implementation?

No. Make production responsibility and acceptance responsibility explicit.

### Can the delivery owner also accept?

Sometimes, if the real process permits it; this example requires a separate Finance judgment.

### Where does this fit in TeamBoost?

Use the documented task assignment for delivery ownership and the task context to record the receiving role and agreed examples. Do not assume there is a separately configured native approval role.

## Job to be done

When technical tests pass but the business meaning remains unclear, I want the receiving expert to check specific examples so the implementation owner gets a bounded correction rather than a vague approval request.

An engineer owns a billing-view change and passes unit checks. Finance still needs to judge whether partial refunds are recognizable in the finished view.

### Recognizable symptoms

- One owner name is expected to cover production and receiving acceptance.
- Internal checks are treated as customer or business approval.
- A reviewer is involved only after the work is called done.

### Shortcut that fails

Adding more technical checks does not replace the receiver’s judgment about the required business meaning.

### Before

Engineering owns the billing view, so passing unit tests closes the work.

### After — invented worked answer

Responsibility agreement: engineering owns the implementation and technical checks. Finance reviews full, zero and partial-refund examples for recognizability. The partial-refund example needs clarification, so delivery acceptance remains open. Engineering keeps the delivery task; Finance supplies the receiving verdict rather than becoming an unrequested implementer.

### Conditional next moves

- If Delivery and acceptance require different expertise: Name both responsibilities. Technical completion and business suitability are different claims.
- If The receiver identifies one gap: Return that bounded correction. Do not transfer the whole implementation responsibility accidentally.
- If The real process permits one person to cover both: Record the permitted boundary. The workflow should reflect actual authority, not a universal separation rule.

### TeamBoost route — confirm account availability

- Assign the producing work: Keep the engineer responsible for the implementation task. Your check: Confirm the assignment reflects an agreed responsibility.
- Write the acceptance request: Record Finance’s receiving question and the three review examples. Your check: A human reviewer judges whether the result meets that meaning.
- Explain the remaining state: Report technical checks passed and Finance clarification still open. Your check: Do not summarize the two boundaries as an unqualified done.

### Success check

Finance can identify the partial-refund interpretation gap in specific examples, while engineering retains correction ownership and receives an agreed recheck.

### Editable draft facts

- Delivery owner [deliverer]: Engineering owner — Who produces the result?
- Acceptance reviewer [receiver]: Finance reviewer — Who judges the receiving meaning?
- Acceptance question [boundary]: Can full, zero and partial refunds be recognized? — Use a concrete question, not approve everything.
- Example or evidence [proof]: Three refund examples; partial-refund case needs clarification — Keep the actual receiving evidence.
- Return check [next]: Finance rechecks the clarified partial-refund example — Agree how the gap closes.

### Draft pattern — replace every placeholder

```text
Business receiving check
Implementation owner: {deliverer}.
Receiving expert: {receiver}.
Business meaning to check: {boundary}.
Worked examples and unresolved gap: {proof}.
Correction return and recheck: {next}.
Passing technical tests does not settle this separate receiving judgment.
```

### Limits

The example does not establish a TeamBoost approval-role feature or general governance rule. Confirm the actual receiving process.

Local text preparation only; no workspace read, task creation, send or approval. Source interfaces do not establish account availability or live feature completion.