Guide baseline: v0.9.11
Review remediation and evidence
Start with the original findings, inspect what was delivered, and decide whether the saved file is ready for use.
1. Open the document’s Review workflow
History and Issues link to Review. Wait for scan and remediation jobs to reach their own terminal states. A completed original scan does not mean that remediation finished or that a saved file is available. For API submissions, follow the authenticated progress/result lifecycle in the API guide.
| Record | Meaning |
|---|---|
| Original findings | Issues Found counts the original findings, including any since fixed. It is not the current unresolved total. |
| Applied changes | An attempted or recorded change is not automatically a delivered, verified fix. Check publication and per-issue outcomes. |
| Verified fixes | Use the recorded verification evidence for the saved bytes. A confidence value or approval decision alone does not prove the original issue was fixed. |
2. Check whether output was delivered
Partial output is withheld. When this safeguard applies, every original finding remains unresolved; changes inside a withheld candidate are not delivered fixes. Manual-required and failed outcomes still need work. An unreported per-issue outcome means evidence was not recorded, not that the issue passed. Older jobs are not assigned invented outcomes.
A missing download can be the correct result. For managed Office output, publication requires at least one fix, zero manual and failed issues, an output file and passed verification. Review remaining work, preserve the original and correct or re-run the document as appropriate. Do not publish an unavailable or superseded file.
3. Read the measured scores
Supported comparisons scan original and saved bytes using the same deterministic settings. A lower after-score is allowed when that is the measured result. A missing comparison stays unavailable; it is not zero or an estimated improvement calculated from fix counts. PDF comparisons need complete paired checks, including supported semantic evidence.
The result fields score_verified, score_provenance and score_measurement describe the evidence. The measurement records method_version, source_sha256, output_sha256, source_score and output_score. These identify the scoring method and exact files; they do not certify conformance.
If the after-score is unavailable, inspect score_verification_reason:
| Reason | Next step |
|---|---|
| original_file_missing | Recover the original from your source system, upload it and scan again. |
| original_scan_failed | Check scanner availability and whether the original can be fully read. |
| output_file_missing | Re-run remediation from the retained original. |
| output_scan_failed | Inspect the saved document and scanner availability. |
| incomplete_comparison | Some required evidence or reproducible source findings are missing; review and rescan. |
| baseline_mismatch | The newly measured original differs from the recorded baseline; create a fresh original scan. |
| unsupported_scan_type | This path has no compatible source/output comparison; perform the appropriate manual verification. |
| legacy_unverified | The historical result has no verified measurement record; re-run from the original. |
| artifact_mismatch | The file differs from the measured bytes; investigate and re-run before relying on the comparison. |
Historical estimates remain historical. Re-run remediation from the retained original to obtain new evidence. If the source findings cannot be reproduced, create a fresh original scan. If the original is missing, recover and upload it again. Scanning a previously remediated file establishes its current score, not the missing before-score.
LaTeX and static HTML/CSS/JavaScript comparisons use source scanners. Static source checks cannot certify a rendered website or Canvas browser finding. Multimedia companion outputs without a comparable verifier remain unverified.
4. Compare the original and saved PDF
Choose Show comparison, select a page and switch between Original PDF and Saved PDF. Refresh comparison re-reads the current artifact. The read-only panel shows actual page images and tagged text from independently checksum-verified bytes. It does not edit tags, save changes or approve the document.
The ordered list follows supported structure-tree and MCID/ParentTree references, including text alternatives. It does not substitute visual extraction order or a proposed change for saved-order evidence. Numbered highlights appear only for uniquely matched complete painted lines. Repeated, multiline or alternative text can remain in the list without a guessed highlight.
Missing originals and missing, expired, superseded or invalid saved artifacts are reported independently. Untagged or unresolved structures get no fabricated fallback order. Supported mixed table/text checks compare table placement and surrounding text; they do not certify internal cell order or table semantics. Ambiguous layouts require manual review and prevent complete verification.
PDF preview limits
The initial subset supports page-stream marked content, explicit or ParentTree-resolved page ownership, text alternatives and rotated/cropped geometry. Unresolved annotations and other content-stream scopes are unavailable. Non-PDF files are not visualized.
Bounds include 50 MiB per file, 500 pages, 2,000 returned text segments, 200,000 Unicode code points and a page image at most 1,200 pixels on its longest edge. Rendering checks cap page content at 1 MiB, cumulative stream invocations at 4 MiB, operations at 20,000 and cumulative image pixels at 20 million; repeated references count repeatedly.
Unfiltered streams, single-Flate streams and checked JPEG images are supported; other filter chains remain unavailable. Form XObjects, Type 3 fonts, patterns, shadings, soft masks and inline images are outside this preview subset. Parsing has no separate process isolation or hard execution deadline. These bounds are not CPU or memory guarantees.
5. Record review decisions
Inspect the actual saved file in its intended application. Check layout, meaning, navigation, links, tables, media and generated language with the validators and assistive technology required by your workflow. Review supports approve, reject and supported edit actions on fixes, with a recorded reviewer and audit history. A deterministic change does not guarantee approval.
Fix review and managed-artifact approval are separate. Inspect the current artifact’s approval_blockers and can_approve before an artifact approval action. Approval does not automatically write the file back to an LMS or cloud provider. Destination availability, permissions and the connector’s writeback workflow remain separate requirements.
A deferral records an unresolved finding with an owner, reason and future expiry including a timezone. It can be updated or revoked and becomes expired when due. Deferral is tracked work, not a verified fix or a waiver of an accessibility obligation.
Review reads, actions, queues, counts and exports preserve authenticated department and course restrictions. Course-scoped Review currently supports Canvas file bindings; other LMS course identifiers cannot substitute for a Canvas binding. Authorized administrators retain department-wide scope.
6. Export evidence and keep the original
The Review API supports audit exports in JSON, CSV and PDF containing bounded findings, changes, review history and validator evidence. The evidence package excludes source and output document bytes by default; include them only when needed and authorized. An export records available evidence and is not a conformance certificate.
Preserve the original and the reviewed output according to your retention policy. Hosted availability depends on the deployed release and configuration. Administrators should keep API, worker and dashboard on the same release and check queue readiness and provider authorization before re-running work.
Review actions and export contractsArtifact approval contractCurrent outcome and preview changesTroubleshoot missing evidence