Make one task reviewable
- Choose one task and the smallest intended outcome. Record the exact delivered version, environment and responsible owners.
- Keep expected results separate from actual observations. Select one current record if you use JSON, CSV and Markdown together.
- For each relevant check, cite evidence or explain why it is blocked, not run or not applicable. No automatic score decides product readiness.
- Finish by recording changed files/state, supported recovery or retention disposition, unresolved items and the next owner.
These forms are completed privately. This page neither saves your data nor executes a product operation.
Collect the version-specific handoff
- Delivery owner
- Exact installed release and client/tool build; supported task, interface/schema/target and revision; supplied setup or operation procedure.
- Operator / access owner
- Intended installation, endpoint reference, current access/grant reference and permitted action. Use private references rather than credential contents.
- Task / change owner
- Input ownership, intended state, affected files or configuration, maintenance constraints, approval scope and stop condition.
- Review / retention owner
- How to verify the result and its actual effect; supported recovery procedure, retained data, review date and next owner if incomplete.
Missing prerequisites are worksheet issues. A completed form does not supply a missing grant, schema or connection.
Verify the result at the right level
CX-01One task and its claim boundary
- Expected evidence
- One selected case, intended outcome, actual mode and expected deliverable are written. Preparation, recorded reading and live observations remain distinct.
- Keep
- Task plan with case ID, reviewer and permitted scope.
CX-02Exact handoff and missing dependencies
- Expected evidence
- Applicable release, target, interface/schema revisions, access and supported procedure have supplied references or an explicit missing owner/action.
- Keep
- Handoff checklist and missing-deliverable records; no invented IDs or envelopes.
CX-03Before state and exact action
- Expected evidence
- The relevant before state, identity/revision and actual action are recorded, or the step is explicitly unperformed. Query exits are captured separately.
- Keep
- Before observation, action/command reference, time and each exit where applicable.
CX-04Literal result and request correspondence
- Expected evidence
- Returned operation/request/work, status/reason, reached stage and revisions are copied literally and tied to the original action. Exit alone is not success.
- Keep
- Sanitized returned result and original request/Work reference, or explicit unavailable fields.
CX-05Matching deliverable and file checks
- Expected evidence
- The actual deliverable is identified and reviewed against the expected scope. For reports, same Work/revision, readability and file-specific hashes are checked; inapplicable checks have a reason.
- Keep
- Deliverable reference; observed or unperformed file/identity comparison with evidence.
CX-06Reported, stored and effective state stay separate
- Expected evidence
- A response or changed revision is recorded as such. Stored/effective behavior is observed only through the supplied supported path; hidden or unavailable values remain unknown.
- Keep
- Separate reported-state, stored-state and effective-state fields with source/time or limitation.
CX-07Retained state, recovery and resources
- Expected evidence
- The final intended/observed state, retention owner, supplied recovery disposition and remaining resources/costs are recorded when applicable. No automatic rollback or zero-cost inference.
- Keep
- Closeout/resource rows, supported recovery/retention references and explicit unmeasured items.
CX-08Human review and next owner
- Expected evidence
- The reviewer explains the task result and each open item has an owner, next action and evidence needed to resume. Manual labels never alter product acceptance or authority.
- Keep
- Manual check dispositions, reviewer/date if supplied, literal product state separately and a sanitized handoff.
For Admin, a returned APPLIED status and revision identify a recorded change. If a projection withholds configuration values, record stored-value and effective-behavior evidence separately. An unavailable observation stays unresolved.
Record a manual disposition
- MET
- The cited observation supports this check for the stated scope.
- NOT_MET
- The observation contradicts the expected result.
- NOT_RUN
- The check has not been performed.
- BLOCKED
- A named prerequisite prevents the check; record the owner and resume condition.
- NOT_APPLICABLE
- Explain why this check does not apply and identify the reviewer.
Keep literal product status, reason, revision and acceptance alongside these human worksheet labels. A process exit or a filled worksheet does not change them.
Preserve the failure and choose the next owner
F-01A required installation, request package or target handoff is missing
- Check first
- Identify the selected case and the exact missing standard deliverable. Keep a source document, a target-reference fragment and a complete request distinct. For Admin, confirm provisioning first.
- Owner
- Delivery/interface owner; product administrator for established Admin access.
- Keep
- Case, exact release or unknown, missing item and supplied-reference list.
- Resume when
- The exact version-matched deliverable and required access are supplied and checked for the target.
- Closeout
- Keep the preparation brief and owner request. Stop only dependent operational steps; do not invent a target or customer-specific replacement script.
F-02Source format or protocol revision is rejected
- Check first
- Compare document kind/revision, required names, primitive properties and unsupported fields with the matching public table. Read the actual status/reason as well as process exit.
- Owner
- Source-document owner; supplier for missing schema/version facts.
- Keep
- Original source copy, one proposed correction, operation/stage and literal reason.
- Resume when
- The author checks the bounded correction; a product recheck waits for the complete supported request and authorized scope.
- Closeout
- Preserve the failed input/result. Do not relabel a captured MCP protocol or turn unknown observations into true.
F-03Normalization, validation or registration preparation cannot advance
- Check first
- Read operation, status, reason, lifecycle_stage and next_required_actions. CONTRACT_INCOMPATIBLE requires the exact supported target; REQUIRES_AUTHORITY requires the supplied approval/transport route.
- Owner
- Supplier/interface owner for target compatibility; designated registration/authority owner for the supported route.
- Keep
- Request/correlation references where returned, target revisions, reached stage and literal reason.
- Resume when
- The responsible owner supplies the missing target or supported next-stage route and its required validation.
- Closeout
- Retain the actual failed/pending disposition. Discovery success or exit 0 does not close this branch.
F-04Headless transport fails or a required readiness item is unknown
- Check first
- Check supplied client, release, socket and account. If a response exists, separate liveness from readiness and preserve each relevant reason; identify what the intended next task requires.
- Owner
- Service operator for endpoint/process state; relevant component owner for readiness.
- Keep
- Status and health exits, actual component states/reasons, target and observation time.
- Resume when
- The intended query context is restored and the owner resolves any readiness dependency before the affected next operation.
- Closeout
- Save the observation and stop dependent work. Do not auto-restart or adopt the old lab admission as current permission.
F-05A submitted action is uncertain or identity does not match
- Check first
- Preserve the original request and target. For Admin timeout use Reconcile exact request on the existing pending request; for Work inspect the saved Work under the same installation/account or ask support to reconcile.
- Owner
- Admin/operator for the pending Admin request; Work owner and product support for Work identity.
- Keep
- Original request/Work reference, expected/observed target or ID, action, time and literal reason.
- Resume when
- The original action disposition and current state are reconciled, and any next action is explicitly supported and authorized.
- Closeout
- Retain uncertainty until resolved. Do not submit a replacement request, new key or duplicate Work as a recovery shortcut.
F-06Admin returns stale revision, denied session or invalid configuration
- Check first
- For STALE_REVISION refresh and re-review the original intent against the new appliance state. For denied/session-invalid results resolve the literal reason with the administrator. For INVALID_CONFIGURATION check registered keys, range and policy.
- Owner
- Change owner for intent; access administrator for session/grant; configuration owner for allowed values.
- Keep
- Appliance and configuration revisions separately, original change, decision/reason and audit reference.
- Resume when
- The correct target/session and current revision are established and the exact change is reviewed again within its approval.
- Closeout
- Keep the original failed result. Cancel if scope changed; do not overwrite Expected revision blindly or bypass a denial.
F-07Report is missing, unreadable or fails file-hash comparison
- Check first
- Confirm selected Work/revision, actual returned paths or approved copies, and the file-specific hash fields. report_sha256 is not the file checksum.
- Owner
- Service operator and product support for artifact access/correspondence.
- Keep
- Selected Work/report reference, expected/observed hashes and sanitized access/readability reason.
- Resume when
- The correct selected files are accessible and the discrepancy is resolved with retained comparison evidence.
- Closeout
- Preserve the original references and issue. Do not regenerate or substitute another report to make the check pass.
F-08A recorded change has unproven effect or unclear recovery/retention
- Check first
- Separate the action response and revision from stored/effective observation. Confirm the intended retained state and the supplied recovery procedure; a hidden value stays unobserved.
- Owner
- Service operator for supported observation; change/data owner for recovery and retention decisions.
- Keep
- Before/reported/after state, observation source, missing effective-value proof and recovery/retention reference.
- Resume when
- The owner supplies the missing observation or explicitly accepts the bounded unresolved handoff; any recovery action needs its own supported procedure and approval.
- Closeout
- Record applied state and unresolved effect separately. Preserve history; do not invent rollback, restart, deletion or a successful effective-value claim.
Close the actual changes
- List the files, configurations, records and resource references actually used. Record before and observed after state for each item.
- State whether persistence across disconnect or restart was documented or observed. A saved profile is not a current connection; a disconnected UI is not a stopped service.
- Use only the supplied recovery or reversal procedure within its approved scope. If no supported reversal is available, preserve the evidence and hand off; do not invent a rollback command.
- Record retained data, retention/review date and continuing resource cost where applicable. Follow the organization’s approved handling route; the workbook is not a deletion instruction.
- Record final observation, open issue, next owner and required resume evidence. Do not mark an uncertain action complete or silently replace it with a new attempt.
Download blank forms and a separate example
Complete Custom Execution workbook ↓9 English documents and README. Detailed manuals remain online.AI assistant review brief ↓Help prepare and review evidence without assuming operation permission.Task plan and handoff ↓Target, version, supplied interface, permitted scope and recovery plan.Actual observations ↓Blank before/after observations, literal states, verification and handoff.Readable operation record ↓A private record from task choice to closeout.Structured task reference ↓The same five cases, checks and failure guidance.Completed illustrative example ↓Retained discovery success and normalization denial, with a separate teaching record.Verification checks ↓Expected evidence alongside blank actual results.Change and closeout record ↓Changed items, observed effects, persistence and supported recovery.Issue and resume handoff ↓Preserved reason, next owner, action and resumption evidence.