Activation asks the owning product to make an exact independently reviewed release active. A preparation, queued command or lost answer does not establish the effect. Preserve the original request identity and read the product-owned result before continuing.
Prepare with current evidence
The Reviewer uses Prepare native activation for the approved central submission. Inspect the returned readiness and current target. Source revisions, dependencies, current roles, assurance and recovery generations can have changed since proof or review.
Resolve a refusal at its actual boundary. Do not create another release or command identity merely to make stale evidence appear fresh. Product-specific conditions remain authoritative, including its source observations, engineering approvals and unresolved operational work.
Activate deliberately
Choose Activate reviewed native release only for the checked submission and intended target. Wait for the retained outcome and inspect Recorded native requests. The result should establish the exact operation and current product release, rather than relying solely on a central notice.
Preparation and activation are separate operations. In a coordinated set, each product also has its own prepare and open steps. One target's acceptance does not imply every other member changed.
Check the original result after interruption
If a native change or lifecycle reply was not confirmed, the workspace holds further changes. Use Check recorded native change outcome or the matching recorded lifecycle outcome check. It reads the original result and does not resend the effect.
For a retained delivery request, use its Check outcome control. Follow any stated recovery hold or missing-result instruction. A timeout is not evidence of failure, so do not prepare a replacement operation with the same intended effect. Recovery must establish the original command first.
Worked handover: a reviewed native release with an interrupted answer
This is an illustrative release handover. It records no real product activation, model call, provider request or physical event. Suppose Brighouse works needs a change to one supported native policy. Its complete source-owned context, independent expected cases, exact draft revision and eligible target have already been supplied. No policy values or successful proof are invented to fill a gap.
Sarah Hughes holds Author in Automation AND the native product's authoring authority for that target. She opens the exact requirement and working plan, selects the source context and checks that it identifies the intended native draft. She supplies the complete independent cases and follows that product's required case review before creating its candidate. If the native product requires independent cases to be reviewed, James Whitaker performs that step as an eligible independent Reviewer with recent verification and the corresponding native authority. Neither person treats candidate output as the expected answer.
Sarah retains the case-set identity, candidate, verification and whole native release submission. Only an actual qualifying proof and current native prerequisites permit the next step. James has contributed to neither the draft nor its expectations. He checks the complete native release and records its native review. Sarah submits the exact eligible release manifest for central review against the current requirement revision. James then records the same decision and explanation centrally with recent verification. A different decision, reason, source revision or contributor set is a refusal to resolve, not a cue to substitute another apparently similar submission.
For the approved exact submission, James checks Prepare native activation and its current readiness with both central Reviewer and native activation authority. Suppose he then selects Activate reviewed native release but the answer is interrupted. The retained request is the handover: it identifies the original actor, submission, target and operation. The workspace holds further changes until its outcome is established. A missing reply proves neither acceptance nor failure.
James uses Check recorded native change outcome, or the matching original recorded lifecycle outcome where that is the pending request. This reads the original product-owned result without sending that effect again. If it confirms acceptance, he checks Recorded native requests and the exact active native release before telling Sarah which result to use. If it remains unconfirmed or reports a recovery hold, he retains those references and follows the stated reconciliation route. He does not replace the request merely to obtain a clearer answer.
Sarah hands the operating team the exact requirement, reviewed submission, confirmed native release and original operation outcome. They use their own native product permissions for subsequent work. A centrally approved or activated policy does not itself create stock, pass an inspection, confirm printing or perform a physical handover. If the target is FactorySpec, its deployed evaluation-only restriction still applies: no role or release here qualifies manufacture.