# Make responsibilities and approvals clear

An approval is useful when it answers a specific question. Define who checks the facts, who accepts the learning, and who is allowed to release the result.

Updated October 26, 2026

## Separate the decisions

A source owner confirms that operating guidance is correct. A learning reviewer checks whether an exercise teaches and tests the intended skill. A release owner decides who receives the approved version. One person may hold several responsibilities in a small pilot, but the record should still distinguish those decisions.

## Describe what approval covers

Attach approval to a named artifact and version, an audience, and an action. Approving a draft explanation does not automatically approve distributing it to every employee. If a reviewer changes the target group or the underlying source changes, decide which checks must be repeated before that revised work can proceed.

## Show enough context to decide

A review request should state what is proposed, why it is needed, what material supports it, and what happens next. Include unresolved questions and meaningful changes since the previous review. The reviewer should be able to accept, request a revision, or decline without reconstructing the entire conversation that produced the draft.

## Agree on the response to silence or refusal

Decide who receives a delayed review and when the pilot owner intervenes. Silence must not become approval by accident. If a reviewer declines, preserve the draft and record the reason, then return it to the responsible author. This creates a workable path forward while keeping the release decision with its owner.

## Verify the intended product behavior

Before relying on an Elvina approval flow, test an authorized reviewer, a person without that authority, a rejected request, and a changed draft. Confirm what each can see and what can proceed. These are acceptance conditions for the intended experience; the guide does not assert that every permission control is already implemented.