Build a record another person can follow
- Write one question, route and exact target. Assign an owner to each missing prerequisite.
- Select applicable criteria below. Put any agreed workload-specific threshold into your plan before running; keep a reason for non-applicability.
- Choose JSON, CSV or Markdown to record results. If you use more than one, name the current record and keep the copies consistent.
- Record each observation with its version, date and evidence reference. A blank or unperformed check is not success.
- Review costs and every resource used, including retained resources and delayed billing.
- Write a human conclusion and an owner/resume condition for each open issue. Keep product acceptance as a separate literal observation.
This page does not save inputs or calculate a pass score. Download the forms, complete them privately and use your organization’s review process.
Agree the evaluation criteria
These are suggested manual checks for the documented routes. Record applicability for your exact scope and add agreed business criteria where a supported task exists.
No criteria match. Clear filters or choose another term.
POC-01One question and one route
- Applies to
- retained-run, conditional-existing-operator, planning
- Expected observation
- One bounded question, one route, a supported input or a clearly pending use case, and a reviewer are recorded.
- How to check
- Write what decision the result will inform. For the audit route use CREATE_AUDIT_ARTIFACT with the exact intent create audit artifact; for reading identify the retained record.
- Keep as evidence
- Planning worksheet; agreed scope and input reference.
POC-02An eligible installation and operating handoff
- Applies to
- conditional-existing-operator
- Expected observation
- The operator confirms the exact release, matching client/service, supplied endpoint, operation permission, unused approved key and report access before submission.
- How to check
- Record non-secret references and the responsible contact for every handoff item. Mark missing items open; a retained run cannot fill them.
- Keep as evidence
- Delivery and administrator confirmations; approved procedure and request references.
POC-03Baseline and unknowns are visible
- Applies to
- retained-run, conditional-existing-operator
- Expected observation
- Reproduction records both status and health exits plus relevant component states and reasons. Reading records the published baseline and explicitly identifies observations that were not published.
- How to check
- Keep the same supplied service/account context. Copy actual states and reasons; assign any required unknown or non-ready prerequisite to its owner before a new submission.
- Keep as evidence
- Baseline observation reference; status/health exits and relevant literal reasons.
POC-04One Work stays identifiable
- Applies to
- retained-run, conditional-existing-operator
- Expected observation
- The saved returned Work ID agrees with the inspected list, show and selected report; no replacement execution is used to resolve uncertainty.
- How to check
- Compare each Work ID and the selected report revision. If no ID was returned, preserve the original request and use the support reconciliation route.
- Keep as evidence
- Original request reference, Work ID and same-Work comparison notes.
POC-05The product outcome is copied accurately
- Applies to
- retained-run, conditional-existing-operator
- Expected observation
- Execution count, validation, final result, retry/replay fields and closure are recorded as returned, including pending human acceptance.
- How to check
- Read the selected canonical report and returned result together. Leave unavailable fields unobserved; do not replace them with example values.
- Keep as evidence
- Literal selected report/result fields and their source reference.
POC-06Report files match the selected Work
- Applies to
- retained-run, conditional-existing-operator
- Expected observation
- Reproduction verifies readable JSON/PDF, same Work/revision and matching file hashes. Reading identifies what file verification the public record reports without claiming a new file check.
- How to check
- Compare JSON with json_file_sha256 and PDF with pdf_sha256; report_sha256 is a different digest. Review the PDF against the same JSON.
- Keep as evidence
- File comparison observation or the cited historical comparison statement; private paths remain local.
POC-07Usefulness receives a human review
- Applies to
- retained-run, conditional-existing-operator, planning
- Expected observation
- The reviewer records a decision against the original question, criterion results and remaining limits separately from product acceptance.
- How to check
- Use MET, NOT_MET, NOT_RUN, BLOCKED or NOT_APPLICABLE with an explanation for each criterion. These are manual worksheet labels. Write the human decision and next action; copy product acceptance separately if observed.
- Keep as evidence
- Criterion review rows and a separate final human-review record.
POC-08Cost and elapsed time have an evidence basis
- Applies to
- retained-run, conditional-existing-operator, planning
- Expected observation
- For each relevant cost/time item, record the agreed limit and measured value with period/source, or Not measured/Not applicable with a reason.
- How to check
- Distinguish software offer, compute, AI/provider, storage/backups and elapsed time. Compare observed values with agreed limits manually; an unread bill is not zero.
- Keep as evidence
- Budget owner/limit; billing or timing reference, or an explicit measurement limitation.
POC-09Every used resource has a closeout decision
- Applies to
- retained-run, conditional-existing-operator, planning
- Expected observation
- Each used resource has an owner, intended final state, retention decision, observed final state and continuing-charge disposition, or an explicitly open item.
- How to check
- List only resources actually used. For reading record that no product/cloud resource was created by that route; for operations obtain the supported procedure and verify each authorized transition.
- Keep as evidence
- Resource closeout rows, retention references and unresolved lifecycle items.
POC-10Open items have an owner and a resume condition
- Applies to
- retained-run, conditional-existing-operator, planning
- Expected observation
- Every unresolved item names a responsible role/contact, next action, evidence needed and the condition for continuing the affected step.
- How to check
- Prepare a sanitized handoff with version, stage, expected/observed result and original Work/request reference when available. Distinguish request reconciliation, service restart and a new submission.
- Keep as evidence
- Issue handoff rows and the agreed next-owner/resume record.
Record the result without changing its meaning
| Worksheet label | When to use it |
|---|---|
| MET | Observed evidence supports the agreed criterion for this exact scope. |
| NOT_MET | Observed evidence contradicts the agreed criterion. |
| NOT_RUN | The check has not been performed. |
| BLOCKED | A named prerequisite prevents the check. |
| NOT_APPLICABLE | The criterion does not apply; include the basis and responsible reviewer. |
These are manual worksheet dispositions. Keep literal product status, validation and human acceptance in their own fields. No worksheet label changes them.
When the observation does not match
Keep the original attempt and literal reason. Use the matching row to prepare a useful handoff.
F-01Fresh r232 customer cannot obtain the first product administrator
- Check first
- Confirm the exact delivered version and whether the supported initial-admin procedure has been supplied.
- Owner
- Delivery contact and product administrator; supplier support for the missing procedure.
- Keep
- Version, stage reached and missing-procedure request reference.
- Resume when
- The supported procedure for the delivered version is supplied and required product access is confirmed. Planning and reading can continue meanwhile.
- Avoid
- Do not use the isolated Admin demonstration candidate or a test initializer as customer bootstrap.
F-02Client is missing or the service cannot be reached
- Check first
- Check the supplied client path, exact release, local endpoint and account context against the handoff.
- Owner
- Service operator; delivery contact for installation mismatch.
- Keep
- Failed command reference, exit, sanitized transport reason and target/release reference.
- Resume when
- The operator confirms the intended endpoint/service and the same-context baseline can be observed.
- Avoid
- Do not invent a service startup, change accounts to bypass a denial or treat a desktop path as an appliance connection.
F-03Health is nonzero or a required component is UNKNOWN
- Check first
- Read each relevant state and reason; identify which prerequisites the intended operation requires.
- Owner
- Component owner with the product administrator and service operator.
- Keep
- Status/health exits and literal component reasons; affected prerequisite.
- Resume when
- The owner resolves the applicability and required readiness/authority is confirmed for that operation.
- Avoid
- Do not repeat the retained lab exception by assumption or restart automatically because health is nonzero.
F-04Preparation is rejected or the request is denied
- Check first
- Read the nested reason as well as the outer error. Check supplied intent/operation and authority; establish whether a Work was created.
- Owner
- Product administrator for permission; supplied-interface owner or support for input/preparation.
- Keep
- Original request reference, complete sanitized reason and same-context reconciliation result.
- Resume when
- The original attempt is reconciled and the responsible owner confirms the exact supported input and any authority needed for a permitted next action.
- Avoid
- Do not replay the historical failed wording as a test, assume no persisted metadata or bypass a denial.
F-05Submission times out, is interrupted or returns no Work ID
- Check first
- Preserve the original key and request context; inspect saved responses and reconcile the original installation/principal with support.
- Owner
- Work owner and product support.
- Keep
- Original key reference, observation time, exit/response state and minimal request reference.
- Resume when
- The original attempt has a resolved disposition and the exact authorized next action is documented; an execution_retry_allowed false result still forbids automatic retry.
- Avoid
- Do not create a new key or repeat work run as recovery. An empty scoped list alone does not prove that no Work exists.
F-06Work/report identity differs, show is denied or outcome is FAILED/PARTIAL
- Check first
- Compare the saved ID, account/installation scope, selected revision and literal outcome/closure fields.
- Owner
- Work owner and product support; administrator for a binding denial.
- Keep
- Mismatching references or literal failure, selected revision and sanitized reason.
- Resume when
- The same-Work result and permitted next action are reconciled by the responsible owner. Any repair or new execution requires its own supported procedure and authority.
- Avoid
- Do not substitute another report, switch principals to evade a denial or call a failed/partial result unchanged state.
F-07JSON/PDF is missing, unreadable or has a file-hash mismatch
- Check first
- Use the returned paths or supplied approved copies, same Work/revision and the correct file-hash fields.
- Owner
- Service operator and product support.
- Keep
- Work/report reference, expected and observed file-hash comparison, access failure reason; keep private paths local.
- Resume when
- The correct selected artifacts are available and the discrepancy is resolved with retained evidence.
- Avoid
- Do not regenerate silently, substitute another report or compare raw file bytes with report_sha256.
F-08Resource owner, retention effect or restart outcome is unclear
- Check first
- Identify the exact resource and in-flight Work; compare intended and observed state with the supplied lifecycle procedure.
- Owner
- Service operator for service state; cloud/data owner for resources, retention and charges.
- Keep
- Before/after states, resource reference, pending Work, retention decision and remaining-charge question.
- Resume when
- The responsible owner confirms the exact lifecycle action and retained-data effect; after an authorized restart, required health/readiness is checked before dependent work.
- Avoid
- Do not equate closing a GUI with service stop, VM stop with zero charges, or restart with permission to resubmit a Work.
Compare the budget with actual cost and time
- Before running: record software, infrastructure, AI-if-used, retained-storage and elapsed-time budgets with owner, currency or time unit and period. A plan is not a quote.
- After the exercise: record the observed amount, measurement period and source. Name anything excluded, such as tax, shared resources or delayed usage records. Keep elapsed time separate from monetary cost.
- No provider call in a reading exercise means no AI-call evidence from that exercise. It does not establish that your entire cloud account has zero charges.
- Keep unmeasured or pending billing explicit. Set the next billing review owner/date and link any continuing charges to the retained resource.
Close every resource you actually used
- Start with an inventory of actual resources. Do not treat example VM or storage sizing as resources that have been created.
- For each item, record the owner, before state, intended keep/stop/delete decision, approval reference and supported procedure. This worksheet provides no new deletion command.
- Record the observed after state, retained data, evidence, retention review date and ongoing cost reference. Leave unknown outcomes open.
- A closed GUI, a stopped VM and deleted data are different observations. Preserve an owner and next action for incomplete closure.
Make the next action concrete
Use one row per unresolved issue: failed step, expected and observed behavior, sanitized reason, minimal evidence reference, owner, next action, resume condition and review date.
A resume condition should say what evidence is needed, such as a supported administrator handoff or reconciliation of the original Work. It does not grant retry or execution permission.
Download issue handoff ↓Write a useful final evaluation
Answer the original question in plain language. Link the criteria and evidence that support it, list what remains untested and state the next action with its owner.
| Human conclusion | What it means |
|---|---|
| Objective supported for this scope | The named reviewer found supporting evidence for the agreed criteria; record limits and remaining operational prerequisites. |
| Further evidence needed | Name the unresolved criterion and the exact observation needed. |
| Objective not supported | Record which evidence failed the criterion and whether an approved next evaluation is worthwhile. |
| Evaluation deferred | State the blocking input, responsible owner and condition for reconsideration. |
Record reviewer and date when an actual person makes the decision. Keep the latest product acceptance field alongside the human conclusion. Neither the guide nor a completed sheet updates product acceptance.
Download blank forms and the separate example
Complete PoC workbook ↓11 English documents and README. Manuals remain online.Plan and operating handoff ↓Question, route, criteria, owners, budget and resource plan.Actual observations ↓Blank criterion, cost, resource, issue and final review records.Readable PoC record ↓A human-readable plan-to-closeout record.AI assistant brief ↓Preparation and evidence review; no automatic execution.Evaluation scorecard ↓One row per criterion; actual observations and decisions stay blank.Cost record ↓Planned and actual costs, period, source and remaining charges.Resource closeout ↓One row per actual resource; no pre-created resources assumed.Issue and resume handoff ↓Owner, next action and evidence required to resume.Structured journey ↓The same 11 steps and command references.Evaluation reference ↓Criteria, scenarios and failure guidance in structured form.Completed illustrative example ↓A labeled reading exercise; never import as your actual results.
Original R0 offline reference edition remains unchanged. Use the R1 workbook for the current criteria and corrected baseline reference.