# Review portable workflow evidence at the receiving site

Inspect signed and local proofs without confusing review with signing or activation.

Source: https://help.smartfact.ai/manuals/labels/portable-workflow-review

Review edition: 25 October 2026

Roles: reviewer

These review pages are for a LabelRules Reviewer working on retained portable-workflow evidence. Some retained messages call the evidence an owner review, but the product permission is Reviewer. Review is separate from preparing or signing a package, installing it and activating it. Do not treat a review receipt as authority to perform those other actions.

## Open a retained evidence handover

Use **Imported workflows** or the exact export-review link supplied with the prepared evidence. Match the check/replay identity and digest, intended organisation/site and package lineage before inspecting the report. A similarly named package is not the same retained evidence.

The browser pages inspect already prepared checks and replays. They do not provide a general package uploader or a complete signing/activation console. Have the person responsible for that preparation supply the correct retained link through the private handover route.

If the page reports a changed runtime or blocked new review, preserve the historical evidence and request a current check/replay. Do not edit the link's identity or digest to bypass the refusal.

## Review export proofs and intended scope

On **Review export proofs**, inspect every offered rendered preview/PDF and the independent rule checks. Compare intended inputs, expected answers and actual results. A readable file alone does not prove that its labels or decisions are correct.

Under **Package destination and lineage**, enter the intended package id, destination organisation/site and lineage information exactly as agreed with the receiving team. Complete the offered predecessor/update information and expiry where required. Preserve exact identifiers rather than substituting display names.

Read each proof, expectation, destination and review acknowledgement before confirming it. Add the factual review note and retain the review through the offered action. If a required identity, predecessor or proof is unknown, obtain it from the preparation record rather than inventing one.

Inspect the resulting retained receipt and pass that exact receipt/reference to the authorised package-preparation process. A retained export review does not itself approve or sign the package.

## Review an imported local workflow

On **Review imported workflow**, compare the signed evidence with the local source checks and local rendered proofs. Check independent inputs, expected answers and actual results, including rule checks. Inspect the receiving site, station, source namespace and freshness policy.

A correct source package does not prove that its local binding or current receiver conditions are correct. Read the current limitations and blocked reasons. Resolve missing or changed local checks before approval.

Complete the four displayed acknowledgements only after reviewing proofs, expectations and binding and agreeing the exact local workflow. Add the required note, then choose **Approve local workflow**. Reopen the retained approval and inspect its identity.

## Hand over without assuming activation

The local approval explicitly leaves activation separate. Preserve package, local check, review and receiving-scope references for the responsible person. Never describe a retained approval as a published production release merely because its proofs passed.

Current eligibility can change after a runtime, station, source or recovery change. Historical proofs remain evidence of their original check; they do not grant current signing or execution authority. Keep physical printer qualification and the source product's operational permissions separate throughout.