Review a client-delivery portfolio with a receiver

Choose the question together: “Can a receiver understand this scoped recommendation and continue one task from the supplied evidence?” Use the lesson's published criteria; do not introduce a hidden requirement midway through the review.

Portfolio revision / candidate / source packet:
Builder alias / reviewer role:
Review mode: peer practice / self-review
Question agreed before review:
Artifact or claim to inspect:
Receiving task to attempt:
Limits: local scripted / tabletop / implemented path actually available

Pick one supported path and one exception. If the packet lacks a required trace, keep it unresolved rather than asking the builder to narrate an imagined result. A review conversation can clarify intent; it cannot produce missing execution history or establish a participant's permission to release software.

Inspect enough evidence to identify the packet's strongest claim and its next gap. You are not required to run every optional lab in a short review. For each row, record the exact filename, section or evidence ID actually inspected.

Look for mismatched candidate or source revisions between artifacts. A result from a prior configuration may remain useful development history but needs a specific justification before it supports the current claim. Keep copied source examples, learner runs, authored observations and peer actions labeled.

The builder gives the packet, then stops explaining. Choose a task that the available practice implementation can actually support: locate the cited procedure, run one local case, inspect the first stopping stage or follow the manual steps on a synthetic request. A tabletop action stays labeled tabletop.

Task requested:
Candidate and evidence available:
Receiver's actual steps:
Where they paused or could not continue:
Builder assistance, if any:
Outcome reached / evidence ID:
What remains unknown:

Write observable actions rather than “understands the system.” Finding a link is not finishing the manual task; explaining a disable control is not operating it. Do not give a reviewer production permissions to make a training review easier. If the task requires unavailable access, record the dependency and choose a useful independent task within the available practice boundary.

Choose one finding with the highest consequence for the agreed review question. Use the observation, its effect on the decision, the requested change and the observation needed to confirm the repair. Keep the builder's explanation beside the finding; it may correct your interpretation without changing the source record.

Exact claim or step:
Observation and evidence reference:
Why it affects the receiving task or recommendation:
One requested revision:
What would demonstrate the repair:
Builder response / disagreement:
Owner of next evidence:

Example of feedback structure, not a review of your work: “The evaluation says the current candidate handles a deadline, but RUN-02 belongs to the earlier revision. Bind the claim to a current-case observation or mark it unresolved. The receiver should be able to identify the revision and manual outcome in the new record.” Avoid a general “make it more robust” request that has no observable end point.

Use this extension when the learner used a coding assistant or a worked example and the receiver needs to understand their own contribution. Agree to it before the review; do not quietly add an independence requirement after assistance was permitted. The purpose is to observe a bounded explanation and a changed-case decision, not to guess authorship from polished writing or assign a qualification. This adds fifteen minutes to the core twenty-five-minute review.

Identify the contribution, not the whole conversation (3 minutes)

The learner chooses one small change in the synthetic starter. Ask for its intended behavior, the before/after lines, the assistance used and the decision they personally accepted, changed or rejected. A short relevant excerpt or summary is enough; do not request an unrestricted chat export or private prompts. If no assistant was used, record that and use the same explanation exercise.

Ask the learner to trace one input through the changed branch to an observable result. Let them inspect the actual code; this is not a memory test. The receiver records what they can point to and any help supplied, rather than converting a fluent summary into evidence of understanding.

Write a first decision before opening the helper (4 minutes)

Choose one of the following declared prompts. Give the learner two quiet minutes to write the expected outcome and the enforcing control before consulting a coach, answer key or partner. Keep this first response even if it is wrong.

Use the original reference file and a separate practice copy if execution is available. Record their editions and exact commands. If code cannot run, retain the prediction as unexecuted; do not fill an Actual field from these notes.

Challenge one explanation with the observed path (5 minutes)

For the first prompt, the reference starter returns manual/ambiguous-source for both orders before adapter dispatch. A copy that admits multiple sources can select different instructions when the roster is reversed. Ask the learner to locate the first changed predicate and explain why an apparently valid citation cannot resolve the conflict. The procedure owner, not array order, must establish which instruction is authoritative.

For the second prompt, the reference denied case stops with location-not-authorized and an authorization-only trace. No procedure is fetched. The starter's fixed actor is a teaching fixture, not real authentication. Ask which trusted identity and scope evidence a receiving service would require; editing the fixture cannot authorize a real person or location.

The learner can now ask one bounded coaching question or compare with a peer. They then revise their explanation in their own words and name the evidence that changed it. Record the assistance accurately. Do not report the revised answer as the earlier unaided response or erase a useful disagreement.

Record the observation and the next practice (3 minutes)

Contribution and original assistance inspected:
Changed-condition prompt agreed before the attempt:
Learner's first decision / explanation reference:
Actual command, file edition and output, or explicitly unexecuted:
Control the learner identified / point where they needed help:
Coach or peer question used after the first attempt:
Learner's revision and the evidence behind it:
Observation: explained for this case / partly explained / not yet observed
One next practice and the observation to gather:
Reviewer role: peer practice / self-review

Keep the scope of the judgment: “located the source-count guard and explained the reversed-order result” is an observable contribution. “Independent FDE,” “job-ready” or “qualified” is not established by this exercise. A solo learner keeps the same record as self-review and leaves independent observation open. Use the platform's existing formal process for any actual assessment decision.

Use this extension after the agent-engineering labs. Bring one actual local run and one deliberately failing case; do not run every optional lab during this review. The learner gives the receiving engineer a packet that joins the client problem to the execution boundary. The existing labs are separate teaching implementations. Putting their reports together does not create an integrated service or establish that their state and identities interoperate.

Build the smallest useful evidence packet (7 minutes)

The synthetic Field Desk brief is a draft-only triage assistant for the north workspace. It may read an authorized source and propose a response for a human; it may not send a response, change a work order or access south records. The receiving operator needs a manual way to continue when the source is absent. Explain why a direct lookup or fixed workflow might meet this brief before proposing delegation. No client deployment or business result is supplied.

Fill the last column from your own work. A missing implementation remains a proposal, and a tabletop prediction stays unexecuted. Keep secrets and customer records out of the packet.

Use a file revision and an evidence ID, rather than a screenshot of a green status alone. Distinguish an authored observation packet from actual local program output and from an authenticated receiving-service observation. An SDK/tool logo, successful import or valid JSON cannot answer those questions.

Defend one changed condition (10 minutes)

Choose one row before the learner starts. Have them write an initial decision, then locate the enforcing control and explain which earlier evidence survives. They may inspect their code and notes. Preserve assistance and disagreement.

Adapter replacement and rollback remain tabletop decisions unless separately implemented and observed. For related local evidence, use the existing canary comparison, delegation trace and worker recovery walkthroughs. Choose the relevant case and retain your actual command/output; do not copy this table into an Actual result field.

Let the receiver continue without the builder driving (8 minutes)

Give the receiver a bounded available task: run one named local case, find the manual next step, or identify the first refusal in a retained trace. Start with the packet, not a narrated tour. If credentials, a deployment or permissions are missing, record that dependency and choose an independent local task. A peer review does not authorize a production permission change.

Packet / source / adapter / state-format revisions:
Question and changed condition agreed before the attempt:
Learner's first decision and evidence reference:
Receiver's actual task, steps and outcome, or explicitly unexecuted:
Builder or coach assistance supplied:
Enforcing control located / implementation still missing:
One revised decision and the evidence that changed it:
Next evidence owner and receiving environment:
Practice status: revise / evidence missing / ready for another practice review
Production authority and formal qualification: not granted by this exercise

Record what the receiver did, where they stopped and one repair they could verify. A smooth explanation is not an observed recovery. Keep the original packet beside the revision; this practice neither submits work nor changes platform progress, enrollment, permissions or credentials.

Practice status: revise named item / gather missing evidence / ready for another practice review
Reason and supporting references:
One next task / responsible role:
Original review retained at:
Revised packet location and revision:
Follow-up observation / date / reviewer role: [leave unobserved if pending]
Remaining uncertainty:

The builder retains the original attempt and makes one revision. The receiver checks the agreed repair rather than quietly increasing the requirements. “Ready for another practice review” does not mean production authorization or engineering qualification. Use the platform's existing authorized submission and formal review process when applicable; this local sheet does not submit, save, issue a credential or change course completion.

Keep this sheet with your editable portfolio. Continue to the enterprise rehearsal when you can explain which work is demonstrated and which next decision is open.