PoC Guide: plan, run, evaluate and close

Agree what the evaluation will teach you before spending or submitting.

Bring

• Named PoC owner and reviewer
• Non-confidential sample and intended use

Follow the sequence

1. Choose either reading the retained audit example or, if already eligible, reproducing the supported audit operation. CREATE_AUDIT_ARTIFACT creates a structured local audit artifact; it does not audit arbitrary attached documents.
2. Write acceptance criteria, budget, permitted actions and stop conditions. Separate a desired AI use case from this local audit example.
3. Assign cloud, AI, data, product access and service-operation responsibilities. One person may fill several responsibilities; each requires its own access.
4. Use the evaluation workbook to turn each criterion into an observable expectation, a check and an evidence reference. Agree any task-quality, time or cost threshold before execution; there is no default product pass score.

Keep for the handoff

• Planning worksheet and unresolved dependencies

Define observable criteria →

Avoid treating a recorded example as a customer installation procedure.

Bring

• Delivery version and environment, or an explicit unknown

Follow the sequence

1. New r232 customer: prepare the plan and request the matching Marketplace/deployment/first-administrator procedures. Stop administrator-dependent use at C7.
2. Existing authorized installation: obtain the handoff in step 4 and confirm the operation is supported for its exact release.
3. Read the retained local R234 example now even if operational prerequisites are missing. No account, endpoint or provider is needed to read it.

Keep for the handoff

• Chosen route, release, missing procedure and responsible contact

Recognize the action, outcome and limits of the retained example.

Bring

• Bundled Headless guide and six-step recorded-run reader

Follow the sequence

1. Open headless-worked-run-en.html; then read the tutorial sections of the Headless reference. This is selected actual output, not a live terminal.
2. Follow the successful wording create audit artifact through submission, list, show, report and file checks. Read the earlier rejected wording only as history; do not execute it as a test.
3. Notice the health exit 1/UNKNOWN observations and separately approved admission in that specific lab. That history is not permission to ignore your own missing readiness requirement.

Keep for the handoff

• Notes separating observed result, pending human acceptance and applicability to your installation

Make an eligible reproduction concrete without inventing setup commands.

Bring

• Matching installed client/service release
• Authorized local account and private writable working directory

Follow the sequence

1. Ask delivery for the installed packrctl location and exact service release. Ask the service operator for its absolute local socket and running-state confirmation.
2. Ask the product administrator to confirm CREATE_AUDIT_ARTIFACT permission; ask the Work owner for one unused approved key and a reviewer.
3. Confirm access to returned report files or an approved copy procedure. A local socket is not a remote connection; a desktop terminal does not automatically reach the appliance.
4. For a separate AI PoC, obtain supported model/location, identity/access, billing limit and storage/retention procedure. This audit example does not validate those connections or incur demonstrated AI usage.
5. List each missing handoff item in the issue sheet with its owner, required evidence and resume condition. Planning and recorded reading can continue independently.

Keep for the handoff

• Version, target, approved scope and non-secret handoff confirmation; keep private endpoint/account details local

Record the missing handoff →

Record actual status and component reasons before submission.

Bring

• Completed handoff
• Fresh private output directory

Follow the sequence

1. In the supplied local client environment, replace both absolute path placeholders, then use the baseline block. Keep the same shell/account/socket for following steps.
2. Read status.json and health.json locally. Record both printed status_exit and health_exit values, plus each relevant state/reason. The snippet captures each exit immediately after its command. A zero exit does not grant Work authority.
3. If requirements are unknown or non-ready, ask the component owner to resolve applicability before submitting; do not repeat the lab’s exception by assumption.

PACKRCTL="/ABSOLUTE/SUPPLIED/PATH/packrctl"
SOCKET="/ABSOLUTE/SUPPLIED/PATH/control-plane.sock"
"$PACKRCTL" --help
"$PACKRCTL" --socket "$SOCKET" status --json > status.json
STATUS_EXIT=$?
"$PACKRCTL" --socket "$SOCKET" health --json > health.json
HEALTH_EXIT=$?
printf 'status_exit=%s\nhealth_exit=%s\n' "$STATUS_EXIT" "$HEALTH_EXIT"

Keep for the handoff

• Sanitized baseline summary; raw response files remain private

Resolve a failed check →

Create one intentional Work and keep its returned identity.

Bring

• All operation-specific prerequisites resolved
• Unused approved key

Follow the sequence

1. Replace the key placeholder and keep the supported intent exactly as shown. Execute the submit block only for the separately authorized reproduction; reading this package does not submit anything.
2. Open work-run.json locally. Save result.work.work_id with your key and exit code.
3. The convenience command prepares and executes and writes records. Do not treat it as a read-only probe or generic AI prompt runner.

WORK_KEY="REPLACE_WITH_ONE_UNUSED_APPROVED_KEY"
"$PACKRCTL" --socket "$SOCKET" work run CREATE_AUDIT_ARTIFACT "create audit artifact" "$WORK_KEY" --json > work-run.json
RUN_EXIT=$?
printf '%s\n' "$RUN_EXIT"

Keep for the handoff

• Original key/request context, time, exit and exact returned Work ID

Prevent a second execution from being mistaken for recovery.

Bring

• Exact returned result.work.work_id

Follow the sequence

1. Paste your own Work ID in the query block; keep the original account and socket.
2. Compare works[].work_id in list with work.work_id, reports[].work_id and selected_report.canonical_report.work_id in show.
3. If absent from the last 10, show the saved ID directly or use the documented list limit up to 100. An empty scoped list is not proof of no Work anywhere.
4. If submission returned no ID, preserve request context and ask support to reconcile the original installation/principal before another submission.

WORK_ID="PASTE_EXACT_result.work.work_id_FROM_work-run.json"
"$PACKRCTL" --socket "$SOCKET" work list --limit 10 --json > work-list.json
"$PACKRCTL" --socket "$SOCKET" work show "$WORK_ID" --json > work-show.json

Keep for the handoff

• Work ID, chosen report revision and sanitized reconciliation result

Separate automated completion from human acceptance.

Bring

• Same-Work show response

Follow the sequence

1. Read selected_report.canonical_report: work_id, execution_count, final_result, validation_results, receipt and closure. Retain actual values, not the example’s expected values.
2. Read closure.disposition, closure.human_acceptance_required and closure.human_acceptance. Read replayed and execution_retry_allowed in the returned result.
3. PASSED is validation, not human acceptance. A replayed result is not a new execution. Missing receipt/closure needs support reconciliation.
4. Use the criterion observation sheet to distinguish the expected value from the literal value observed. Mark an unperformed check as not run; give a reason for non-applicability. These are human worksheet labels, not product status.

Keep for the handoff

• Sanitized outcome and pending reviewer decision

Review readable artifacts for the exact Work and revision.

Bring

• selected_report.json_path and selected_report.pdf_path
• Authorized local viewer or operator-supplied approved copies

Follow the sequence

1. Use your returned paths, never a guessed report directory. Confirm files exist, are readable and match the selected Work/revision.
2. On macOS the shared checksum block uses shasum; otherwise use the file verifier supplied for your platform. Compare JSON bytes to selected_report.projection.json_file_sha256 and PDF bytes to selected_report.projection.pdf_sha256, removing its sha256: prefix for comparison.
3. Keep report_sha256 distinct from file hashes. It is the report digest, not the checksum of the saved JSON or PDF.
4. Open the PDF in an authorized viewer and compare Work, execution count and validation with JSON. A server path is not proof of delivery to your computer.

REPORT_JSON="PASTE_EXACT_selected_report.json_path"
REPORT_PDF="PASTE_EXACT_selected_report.pdf_path"
shasum -a 256 "$REPORT_JSON" "$REPORT_PDF"

Keep for the handoff

• Report revision, comparison result and minimal approved references; raw reports stay private

Answer the original PoC question without changing product acceptance by implication.

Bring

• Plan criteria
• Retained-run notes or actual eligible reproduction results

Follow the sequence

1. The named reviewer compares the result with the agreed goal, permitted input, cost and retention boundaries. For the audit example, judge the structured artifact/report trace, not arbitrary content quality.
2. Record the human’s review separately from the product’s latest closure state. This guide supplies no product acceptance command.
3. If no provider was called or billing evidence was not collected, record not measured/not applicable with the reason; do not invent a cost or runtime result.
4. Complete the criterion-by-criterion evaluation and the final human review: what was learned, what remains blocked, which owner acts next and what evidence would change the decision. Do not reduce unresolved required criteria to an average score.

Keep for the handoff

• Reviewer, date, criteria result, open issues and product state
• Completed criterion observations and final human review, or an explicitly unresolved disposition

Write the final evaluation →

Preserve required results and leave resources in an agreed state.

Bring

• Exact resources used
• Data owner retention choices
• Operator’s supported stop/retirement procedure

Follow the sequence

1. Reading-only route: retain your worksheet; there is no product process to stop.
2. Operational route: ask the service operator to stop only an exercise-owned service when authorized by its supplied procedure. A closed GUI does not prove service shutdown.
3. Have cloud/data owners review VM, disks, objects, backups and continuing charges separately. This guide provides no deletion or credential-revocation command.
4. Send support the version, failed stage, expected/observed result, time, literal sanitized reason and minimal Work/report reference. Request a private channel before extra identifiers.
5. Complete one closeout row for each used resource. Record before/after state, retained data, owner, retention review date, remaining charges and evidence. Compare actual cost over a named billing period with the agreed budget; unknown or delayed billing remains unmeasured.

Keep for the handoff

• Cleanup confirmations, retained-report location kept private, outstanding owner/action

Close resources and remaining costs →