Review evidence assertions and approve an exact document version

ProductTrust separates a document version from the assertions made from it. The version identifies the source being reviewed; each assertion records a value, its scope and citations. Use this workflow to inspect an existing registered version, hand prepared assertions to an independent reviewer and record the resulting decisions before version approval.

Before you start

Your governed intake process must already have registered the exact document version. For the review steps, it must have reached Review Required, with the candidate assertions and citations to be assessed already prepared. A document that only shows Upload Pending is not enough. This guide does not establish a native upload or new-assertion preparation workflow.

If the version is still Quarantined, a Compliance Manager can request processing as described below, provided your deployment has working, configured processing services. Installation alone does not establish that scanning, extraction or a particular provider is available. The reviewer also needs authorized access to the exact source material through your established protected-access process; metadata alone is insufficient for assessing a claim.

Person	Responsibility and access
ProductTrust Compliance Manager	Inspect the prepared records, request controlled processing when available, and send Candidate assertions for data review
ProductTrust Qualified Reviewer	Accept or reject assertions and approve a review-required version; assertion review must be independent of its proposer, extractor and uploader, while version approval explicitly excludes its uploader

Both need access to the evidence company and relevant linked records. Reviewer membership alone does not give access to every document. For a reviewer who is not the document creator and has no manager access, confirm a current assignment to the document's subject for evidence review or evidence reading. Assignment dates and company access must cover the review.

Inspect the registered version

1. Open ProductTrust → Evidence → Document Versions and find the exact document and version number. Check the company, uploader, predecessor, effective period and source identity. Use the version record as the reference throughout this review, especially when the document has several versions.
2. If its state is Quarantined, the Compliance Manager checks the document's extraction policy and selects Start Controlled Processing on the version. The action records a processing request and moves the version to Scanning. It does not confirm delivery, a clean scan or completed extraction. Wait for the configured processing service to return verified results; do not treat an outstanding request as review-ready evidence. If the version is already Review Required, continue with step 3.
3. Open Scan and Extraction. Inspect the scan result and time, detected media type, extraction details and candidate count. The governed path to Review Required requires a clean scan and matching processing evidence. Review Signature Inspection separately: scan completion and version approval do not establish a verified signature. If processing is rejected, incomplete or marked for reconciliation, stop here and ask the responsible processing operator to investigate.

Result: you have identified the exact version and established whether it is ready for human review. Manual Review Only is an extraction policy, not a way to skip governed scanning. A candidate count is processing metadata; inspect the actual assertion records before deciding what remains to be reviewed.

The Quarantine and Processing document queue is available to Compliance Managers; Review Required is available to Qualified Reviewers. These queues follow the document's current version. Use Document Versions when you need a specific historical or noncurrent version.

Request and perform assertion review

4. On the version's Assertions tab, open each prepared Candidate assertion. Check its exact document/version link, value and units, scope subjects, mapped requirements, effective period and Citations. Inspect Provenance and any anomalies. If preparation is incomplete or wrong, return it to the responsible manager before requesting a decision.
5. The Compliance Manager selects Request Data Review on a prepared Candidate. Confirm Data Review Required. This handoff does not accept the assertion; it also checks for overlapping accepted assertions and can flag a conflict.
6. The independent Qualified Reviewer opens Evidence → Assertions, uses Data Review Required, and narrows the list to the exact document version. Compare the proposed value with the authorized source and its citation locations. Check that the scope identifies the intended product or revision and that the requirements, dates and units support the intended use. An extraction confidence value does not replace this assessment.
7. Enter a review reason code in Anomalies and Review. Use a short code beginning with a lowercase letter, followed by lowercase letters, digits, underscores, periods or hyphens, up to 120 characters. For example, evidence_matches_source can describe a supported acceptance. Add a clear rationale explaining the decision; the rationale is optional in the application and limited to 2,000 characters. Save the review inputs.
8. Select Accept only when the assertion is supported. Acceptance requires at least one exact scope subject, at least one citation, no blocking anomaly and no unresolved overlap conflict. Select Reject when the assertion should not be accepted, recording an appropriate reason. Both decisions require reviewer independence and a current assertion record. A reviewer who only has the reviewer role can enter the decision inputs but cannot rewrite the proposed value or citations.
9. Reopen or refresh the assertion and check its actual state and Review Evidence. A completed decision shows Accepted or Rejected, with a recorded decision, reason, reviewer and time. If an overlap is detected during acceptance, the assertion can remain Data Review Required with a conflict flag. A completed button click alone is not evidence of acceptance.

Result: each decided assertion has a retained review record bound to its source and citations. Accepted and rejected assertions are frozen; do not plan to revise the decided row in place. If a governed successor assertion is accepted, its accepted predecessor becomes Superseded.

Approve the version and hand off the evidence

10. Return to the exact Review Required document version. Inspect all linked assertions and ensure none remains Candidate or Data Review Required. Resolve outstanding review work with its owner. Do not reject an assertion merely to clear an approval prerequisite.
11. A Qualified Reviewer other than the version's uploader selects Approve Version when the review is complete. Confirm Approved, the reviewer and review time, and the new entry in Custody. If its immediate predecessor was Approved, that predecessor becomes Superseded.
12. Record the exact approved version and the specific accepted assertions required by the next workflow. Evidence → Accepted Evidence lists documents whose current version is Approved; it is not a complete list of every approved historical version. Use Document Versions for that distinction.

Result: version approval records completion of the version review. It can succeed with rejected assertions, or with no assertions, once none is awaiting a decision. It therefore does not mean that every claim is accepted or that the document proves product compliance. A technical-file snapshot has its own requirements for approved exact versions and accepted assertions.

Practice with a prepared training record

Use a fictional FieldLink S1 connector report in an authorized training environment. Begin with an already registered Review Required version and one prepared Candidate assertion about the connector revision, with an exact product-revision scope and a citation to the relevant report location. Use an uploader/preparer and a separate qualified reviewer with current document access. Preparing these records and processing the source are prerequisites to this exercise.

1. As the manager, inspect the prepared assertion and select Request Data Review.
2. As the reviewer, compare the assertion against the training source, enter a reason and rationale, and accept it only if supported. Otherwise reject it with an explanation. Confirm the resulting state and Review Evidence.
3. When no assertion remains awaiting review, inspect and approve the exact version as a reviewer who did not upload it. Confirm the version's state and custody entry, then identify which assertions are actually Accepted.

The expected outcome is a traceable decision and a reviewed version, not a preset acceptance result. If the required prepared records, source access or processing results are missing, stop at that prerequisite.

Resolve common stops

What you see	What to check next
Document or assertion is inaccessible	Evidence company, current document-subject assignment and linked-record access; the reviewer role is not blanket access
Version stays Scanning or shows reconciliation required	The recorded processing request and configured service operation with the responsible operator; do not infer completion from the request
Accept or Reject is unavailable	Correct role, Data Review Required state and saved reason code; Accept also stays hidden for a blocking anomaly
Reviewer-independence error	Arrange an independent reviewer; assertion review excludes proposer, extractor and uploader, while version approval excludes uploader
Missing scope/citation, stale assertion or overlap conflict	Return the unresolved assertion to its responsible manager; inspect Anomalies and Conflicts and verify the actual state before another review
Approve Version reports unresolved candidates	Inspect every linked assertion on the exact version, including those still Candidate; all must have left the pending review states
Source cannot be inspected	Restore authorized source access through the established process before making a decision

This guide covers native review controls for existing governed records in Odoo 20.0 Community, reviewed on 29 October 2026. It is based on source, views and access rules; the workflow was not rerun for this article. It does not verify deployed processing services, certify product compliance or publish evidence externally.

For context and subsequent work, see Getting started, Supplier requests, Technical-file preparation and Engineering-change review handoff. An accepted supplier response does not replace this evidence review, and the engineering-change guide retains its prepared-proposal prerequisite.