After a prompt: find the output and use it
Course | Cowork method | Receipt
Do not stop at the chat answer. Each exercise now names the output you requested and tells you what to do with it.
Copy standalone prompt copies the complete request, including the source context behind DS/RULE/case/example references. Expand Read complete prompt to inspect it; the collapsed display does not omit evidence from copying. Later phases need actual reviewed outputs and your choices. If those are missing, HVE must ask for them rather than invent acceptance or guess a preferred model.
The label EX04-P3: Inspection schema options and recommendation, for example, identifies requested content for exercise 04, prompt 3. It is not a real run ID, artifact ID or guaranteed filename. The server owns actual artifact paths.
Find the right output
- Stay in the selected Cowork project. Confirm the project/folder you used for the request. Do not search a similarly named project.
- Read the run outcome. Working, a live question, operator gate, failed and completed are different states. Answer a question or ask the operator as directed; do not start duplicate work while waiting.
- Use the link Cowork returns to the actual available deliverable. The current plugin should also link the project's
START-HERE.mdstakeholder dashboard. This is a file inside your selected OneDrive/SharePoint project, not this course's orientation page. - If you need to browse the project: open that
START-HERE.md, look under Available deliverables and follow the relevant link. The full stakeholder view islibrary/deliverables.md. Supporting research/plans/reviews are separate from primary deliverables. - Match the requested output label and actual run. Open the original artifact containing that label/section, from the request you just made. Ask for its actual run ID, artifact identity/source version and canonical project-relative path if they are not visible.
- Check availability and review state. Use a verified current mirror. A retrieval-pending, stale or conflicting file is not the current verified version. An unapproved draft can be read for review; verified storage does not mean business acceptance.
- Record the exact reference in your receipt. Keep the label, actual run ID, artifact/version, original path/link and observed statuses. Do not copy a timestamp-shaped filename from an example.
The deliverable may be one file containing several sections, or a group of files. Open the section or files that actually meet the requested content. Do not assume the correct artifact is named artifact.md, the newest file, a BRD, or the first search result.
A label echoed in a request, activity journal or technical index is not the requested deliverable. Check that the linked original actually contains the substantive brief/design/handoff and belongs to the correct run.
If you used an earlier prompt without an output label, ask Cowork to locate its original by the real run and required content. You may record the course label as a worksheet mapping once provenance/content are verified; do not rename or rewrite the original merely to add the label.
The library is navigation to original files. It does not make a new copy of each deliverable. You should not have to manually inspect .copilot-tracking or tool transcripts to find the answer.
Ask Cowork to locate it for you
Use this retrieval request, filling the label from your exercise and the real run ID if it was returned:
[BEGIN STANDALONE CONTEXT]
STANDALONE-1.0 / General course setup, retrieval or guidance request
This request includes its static teaching context below. Do not assume access to course pages, local files, attachments or earlier chat. Source filenames and DS/RULE IDs identify the included evidence, not documents you must fetch.
Use the installed HVE Squad Cowork plugin and the actual authorized selected project. Confirm project identity before creating/adopting a project or starting managed work. New managed work uses the normal squad_run entry point; the server owns routing. Follow an existing working run rather than duplicating it. Do not invent project/run/question/artifact IDs, links or approvals.
If the task depends on reviewed needs, selected features, a preferred model, a handoff, a real run or runtime observations: retrieve the actual verified originals in the selected project, showing their real provenance and the human choices. Earlier exercise content labels can help locate substantive originals through project START-HERE.md and library/deliverables.md; labels echoed in journals are not deliverables. If inputs are absent, ambiguous or unaccepted, list precisely what is missing and ask me to supply the actual original/reference or make the needed workshop decision. Pause dependent work. Do not infer selected scope from candidate proposals or invent earlier acceptance. A missing learner decision cannot be filled by static scenario data.
The current task below defines the decision step. Use interview facts and applicable rules as evidence. Candidate proposals, future changes and supplied design-review findings are fiction to inspect, not approved first-release requirements or executed tests. Unverified licensing/capability/access facts remain open. Core work is feature/schema decisions, not code or designer repairs. Optional maker work requires a separately reviewed design, prepared environment/handoff and actual observations; an example recipe is not proof those exist.
Keep the requested output label in substantive original content. Preserve server-owned canonical paths. Return verified original links and distinguish run outcome, mirror state and document acceptance. Content labels are not filenames or real IDs. Workshop choices do not release operator gates. No production writes, real recipients, ERP actions, external publication or claimed deployment are authorized.
GUIDE CONTEXT: OUTPUTS.md
# After a prompt: find the output and use it
[Course](README.md) | [Cowork method](delivery-playbook.md) | [Receipt](client/offerings/lab-receipt.md)
**Do not stop at the chat answer.** Each exercise now names the output you requested and tells you what to do with it.
**Copy standalone prompt** copies the complete request, including the source context behind DS/RULE/case/example references. Expand **Read complete prompt** to inspect it; the collapsed display does not omit evidence from copying. Later phases need actual reviewed outputs and your choices. If those are missing, HVE must ask for them rather than invent acceptance or guess a preferred model.
The label `EX04-P3: Inspection schema options and recommendation`, for example, identifies requested content for exercise 04, prompt 3. It is **not** a real run ID, artifact ID or guaranteed filename. The server owns actual artifact paths.
## Find the right output
1. **Stay in the selected Cowork project.** Confirm the project/folder you used for the request. Do not search a similarly named project.
2. **Read the run outcome.** Working, a live question, operator gate, failed and completed are different states. Answer a question or ask the operator as directed; do not start duplicate work while waiting.
3. **Use the link Cowork returns to the actual available deliverable.** The current plugin should also link the project's `START-HERE.md` stakeholder dashboard. This is a file inside your selected OneDrive/SharePoint project, not this course's orientation page.
4. **If you need to browse the project:** open that `START-HERE.md`, look under Available deliverables and follow the relevant link. The full stakeholder view is `library/deliverables.md`. Supporting research/plans/reviews are separate from primary deliverables.
5. **Match the requested output label and actual run.** Open the original artifact containing that label/section, from the request you just made. Ask for its actual run ID, artifact identity/source version and canonical project-relative path if they are not visible.
6. **Check availability and review state.** Use a verified current mirror. A retrieval-pending, stale or conflicting file is not the current verified version. An unapproved draft can be read for review; verified storage does not mean business acceptance.
7. **Record the exact reference in your receipt.** Keep the label, actual run ID, artifact/version, original path/link and observed statuses. Do not copy a timestamp-shaped filename from an example.
The deliverable may be one file containing several sections, or a group of files. Open the section or files that actually meet the requested content. Do not assume the correct artifact is named `artifact.md`, the newest file, a BRD, or the first search result.
A label echoed in a request, activity journal or technical index is not the requested deliverable. Check that the linked original actually contains the substantive brief/design/handoff and belongs to the correct run.
If you used an earlier prompt without an output label, ask Cowork to locate its original by the real run and required content. You may record the course label as a worksheet mapping once provenance/content are verified; do not rename or rewrite the original merely to add the label.
The library is navigation to original files. It does not make a new copy of each deliverable. You should not have to manually inspect `.copilot-tracking` or tool transcripts to find the answer.
## Ask Cowork to locate it for you
Use this **retrieval request**, filling the label from your exercise and the real run ID if it was returned:
If no run ID was returned, ask Cowork to recover it from the current request's actual response/activity evidence. Do not fill the placeholder with the exercise label or guess it from a project-wide inventory.
You use normal Cowork conversation. The plugin performs the supported same-run history/status operations; you do not type guessed MCP parameters.
**Exercise 10, prompt 1:** a project read-back may be Cowork navigation over existing verified originals, not a new HVE deliverable. Record "no new work run" when appropriate and follow the originals it cites. If new baseline development was actually requested, record its separate real run/output. Never manufacture a run or server artifact just to satisfy the label.
## Which file is correct when there are several?
| What you see | What to do |
|---|---|
| Current request's verified original with the requested content | Open it and apply the exercise's review/action instructions |
| Older accepted version and a newer draft | Inspect the new draft as draft; preserve both references and actual supersedes/review evidence |
| Same title in another run | Do not assume it answers the current request; confirm provenance |
| Original draft plus Cowork summary | Use the original as the evidence; the summary is navigation/explanation |
| File missing the requested content | Name the missing section and request a bounded correction through normal HVE work |
| File retrieval/mirror pending or conflicting | Ask for retrieval/sync recovery of the existing run; do not request the work again merely to obtain a link |
| Failed/held run with a saved partial draft | You may inspect the draft, but do not call the prompt completed or the draft accepted |
If `START-HERE.md` or the library is missing, ask Cowork to refresh its stakeholder navigation from already verified project evidence without new HVE work. If the installed release cannot do that, ask the facilitator for the supported original-output retrieval path. Do not create a parallel deliverables folder.
## Find the decisions and next action
After reviewing an output, ask Cowork to show the selected project's `library/decisions.md` and `library/next-steps.md`.
- The decision view shows actual unresolved questions/findings, owners and supported response routes. Return to Cowork's native question flow for a live server question; editing a Markdown checkbox is not an answer submission.
- The next-step view shows the current action, its prerequisite, actor and evidence link. Compare it with the task you recorded in your receipt.
- Missing owners/dates remain Unassigned/Not set. Do not silently nominate yourself.
- Your planning disposition, document acceptance, operator blocker and synchronization issue must remain different entries/states.
These pages help you locate what to do. They do not authorize new HVE work, external writes or approval by themselves.
## Do something concrete with the content
Every prompt has a **Find this output / Do with it / Next** block:
It also names a **Decision step** (DS). Use the output to choose features, compare a model, test a relationship or decide a scope change. For example, a canvas inspection schema should explain how selected checklist, finding, evidence and remediation features are represented. The task is not changing a formula or designer property.
| Output type | Learner action | Where it goes next |
|---|---|---|
| Needs/feature hypotheses | Match proposed features to interview evidence and resolve unsupported assumptions | Feature choice |
| Feature priorities | Select included/deferred/rejected features and record value/technology dependencies | Schema alternatives |
| Schema options | Draw relationships, test sample records and challenge fields with no selected-feature purpose | Change impact |
| Changed design | Decide which feature/data consequences belong now versus later | Decision pack |
| Feature/schema pack | Have a partner explain rationale, alternatives, record walkthroughs and open decisions | Prototype/build brief and offering |
"Read and reflect" is not the deliverable. Your visible output is a receipt entry, a content-specific decision/question, a handoff or a next-task instruction.
## Tell Cowork what you decided
Use the actual artifact reference you recorded:
A worksheet disposition does not change the library's Accepted label. The library may show Accepted only with the actual server acceptance evidence and required human approvals. Editing a Markdown row is not submitting a server answer or releasing a gate.
If server review says revise/FAIL or a mandatory condition is unresolved, do not carry the artifact forward as approved. You may review a retained draft, then request the supported correction. A terminal run is not resumed by inventing a question ID; new work needs the normal authorized handoff.
## Worked example: inspection schema choice
**Illustrative content only, not an output from your run.**
Suppose the original schema comparison says:
- Feature: one visit can have zero or many independently owned findings.
- Option A: fixed Defect 1 through Defect 10 columns.
- Option B: a visit record related to repeatable finding records.
- Photo evidence is deferred until access/retention needs are resolved.
You should:
1. Find that content in the actual current-run artifact and record its real reference.
2. Walk a visit with no findings and a derived visit with twelve.
3. Explain which selected feature requires repeatable related records.
4. Record the preferred model, rejected alternative and unresolved photo decision.
5. Submit the change-impact request with that exact artifact reference and disposition.
The example is not a success certificate. If your actual output lacks these topics, ask for them rather than selecting an unrelated file.
## Final handoff
For the workshop, give the original decision pack to a partner through the approved project link. Ask them to explain one selected feature, its evidence and every entity/field/relationship it needs. Record unanswered design questions and any author help.
For real client work, use the approved sharing/engagement process. The course does not authorize sending files externally, creating work items or deploying the plan.
This is a general request, not an unspecified client-design task. If the task refers to an attached interview, selected lab, actual output, handoff or bracketed placeholder without supplying its value, ask me for that exact input first. Do not assume attachments exist or generate a client design without its evidence. The numbered exercise prompts include their full scenarios.
[END STANDALONE CONTEXT]
In this selected project, locate the original saved output containing
[the exercise's output label] from [the actual run ID].
Use existing-run retrieval, not a new HVE work request.
Show its actual title, run attribution, artifact identity/source version,
canonical path and verified link, plus run outcome, mirror state and
document review/acceptance state separately.
Open the complete original content. Do not substitute your chat summary,
another run's file or a native reconstruction of missing HVE work.
If provenance, retrieval or synchronization is incomplete, show the
specific blocker instead of inventing a link or completed output.
If no run ID was returned, ask Cowork to recover it from the current request's actual response/activity evidence. Do not fill the placeholder with the exercise label or guess it from a project-wide inventory.
You use normal Cowork conversation. The plugin performs the supported same-run history/status operations; you do not type guessed MCP parameters.
Exercise 10, prompt 1: a project read-back may be Cowork navigation over existing verified originals, not a new HVE deliverable. Record "no new work run" when appropriate and follow the originals it cites. If new baseline development was actually requested, record its separate real run/output. Never manufacture a run or server artifact just to satisfy the label.
Which file is correct when there are several?
| What you see | What to do |
|---|---|
| Current request's verified original with the requested content | Open it and apply the exercise's review/action instructions |
| Older accepted version and a newer draft | Inspect the new draft as draft; preserve both references and actual supersedes/review evidence |
| Same title in another run | Do not assume it answers the current request; confirm provenance |
| Original draft plus Cowork summary | Use the original as the evidence; the summary is navigation/explanation |
| File missing the requested content | Name the missing section and request a bounded correction through normal HVE work |
| File retrieval/mirror pending or conflicting | Ask for retrieval/sync recovery of the existing run; do not request the work again merely to obtain a link |
| Failed/held run with a saved partial draft | You may inspect the draft, but do not call the prompt completed or the draft accepted |
If START-HERE.md or the library is missing, ask Cowork to refresh its stakeholder navigation from already verified project evidence without new HVE work. If the installed release cannot do that, ask the facilitator for the supported original-output retrieval path. Do not create a parallel deliverables folder.
Find the decisions and next action
After reviewing an output, ask Cowork to show the selected project's library/decisions.md and library/next-steps.md.
- The decision view shows actual unresolved questions/findings, owners and supported response routes. Return to Cowork's native question flow for a live server question; editing a Markdown checkbox is not an answer submission.
- The next-step view shows the current action, its prerequisite, actor and evidence link. Compare it with the task you recorded in your receipt.
- Missing owners/dates remain Unassigned/Not set. Do not silently nominate yourself.
- Your planning disposition, document acceptance, operator blocker and synchronization issue must remain different entries/states.
These pages help you locate what to do. They do not authorize new HVE work, external writes or approval by themselves.
Do something concrete with the content
Every prompt has a Find this output / Do with it / Next block:
It also names a Decision step (DS). Use the output to choose features, compare a model, test a relationship or decide a scope change. For example, a canvas inspection schema should explain how selected checklist, finding, evidence and remediation features are represented. The task is not changing a formula or designer property.
| Output type | Learner action | Where it goes next |
|---|---|---|
| Needs/feature hypotheses | Match proposed features to interview evidence and resolve unsupported assumptions | Feature choice |
| Feature priorities | Select included/deferred/rejected features and record value/technology dependencies | Schema alternatives |
| Schema options | Draw relationships, test sample records and challenge fields with no selected-feature purpose | Change impact |
| Changed design | Decide which feature/data consequences belong now versus later | Decision pack |
| Feature/schema pack | Have a partner explain rationale, alternatives, record walkthroughs and open decisions | Prototype/build brief and offering |
"Read and reflect" is not the deliverable. Your visible output is a receipt entry, a content-specific decision/question, a handoff or a next-task instruction.
Tell Cowork what you decided
Use the actual artifact reference you recorded:
[BEGIN STANDALONE CONTEXT]
STANDALONE-1.0 / General course setup, retrieval or guidance request
This request includes its static teaching context below. Do not assume access to course pages, local files, attachments or earlier chat. Source filenames and DS/RULE IDs identify the included evidence, not documents you must fetch.
Use the installed HVE Squad Cowork plugin and the actual authorized selected project. Confirm project identity before creating/adopting a project or starting managed work. New managed work uses the normal squad_run entry point; the server owns routing. Follow an existing working run rather than duplicating it. Do not invent project/run/question/artifact IDs, links or approvals.
If the task depends on reviewed needs, selected features, a preferred model, a handoff, a real run or runtime observations: retrieve the actual verified originals in the selected project, showing their real provenance and the human choices. Earlier exercise content labels can help locate substantive originals through project START-HERE.md and library/deliverables.md; labels echoed in journals are not deliverables. If inputs are absent, ambiguous or unaccepted, list precisely what is missing and ask me to supply the actual original/reference or make the needed workshop decision. Pause dependent work. Do not infer selected scope from candidate proposals or invent earlier acceptance. A missing learner decision cannot be filled by static scenario data.
The current task below defines the decision step. Use interview facts and applicable rules as evidence. Candidate proposals, future changes and supplied design-review findings are fiction to inspect, not approved first-release requirements or executed tests. Unverified licensing/capability/access facts remain open. Core work is feature/schema decisions, not code or designer repairs. Optional maker work requires a separately reviewed design, prepared environment/handoff and actual observations; an example recipe is not proof those exist.
Keep the requested output label in substantive original content. Preserve server-owned canonical paths. Return verified original links and distinguish run outcome, mirror state and document acceptance. Content labels are not filenames or real IDs. Workshop choices do not release operator gates. No production writes, real recipients, ERP actions, external publication or claimed deployment are authorized.
GUIDE CONTEXT: OUTPUTS.md
# After a prompt: find the output and use it
[Course](README.md) | [Cowork method](delivery-playbook.md) | [Receipt](client/offerings/lab-receipt.md)
**Do not stop at the chat answer.** Each exercise now names the output you requested and tells you what to do with it.
**Copy standalone prompt** copies the complete request, including the source context behind DS/RULE/case/example references. Expand **Read complete prompt** to inspect it; the collapsed display does not omit evidence from copying. Later phases need actual reviewed outputs and your choices. If those are missing, HVE must ask for them rather than invent acceptance or guess a preferred model.
The label `EX04-P3: Inspection schema options and recommendation`, for example, identifies requested content for exercise 04, prompt 3. It is **not** a real run ID, artifact ID or guaranteed filename. The server owns actual artifact paths.
## Find the right output
1. **Stay in the selected Cowork project.** Confirm the project/folder you used for the request. Do not search a similarly named project.
2. **Read the run outcome.** Working, a live question, operator gate, failed and completed are different states. Answer a question or ask the operator as directed; do not start duplicate work while waiting.
3. **Use the link Cowork returns to the actual available deliverable.** The current plugin should also link the project's `START-HERE.md` stakeholder dashboard. This is a file inside your selected OneDrive/SharePoint project, not this course's orientation page.
4. **If you need to browse the project:** open that `START-HERE.md`, look under Available deliverables and follow the relevant link. The full stakeholder view is `library/deliverables.md`. Supporting research/plans/reviews are separate from primary deliverables.
5. **Match the requested output label and actual run.** Open the original artifact containing that label/section, from the request you just made. Ask for its actual run ID, artifact identity/source version and canonical project-relative path if they are not visible.
6. **Check availability and review state.** Use a verified current mirror. A retrieval-pending, stale or conflicting file is not the current verified version. An unapproved draft can be read for review; verified storage does not mean business acceptance.
7. **Record the exact reference in your receipt.** Keep the label, actual run ID, artifact/version, original path/link and observed statuses. Do not copy a timestamp-shaped filename from an example.
The deliverable may be one file containing several sections, or a group of files. Open the section or files that actually meet the requested content. Do not assume the correct artifact is named `artifact.md`, the newest file, a BRD, or the first search result.
A label echoed in a request, activity journal or technical index is not the requested deliverable. Check that the linked original actually contains the substantive brief/design/handoff and belongs to the correct run.
If you used an earlier prompt without an output label, ask Cowork to locate its original by the real run and required content. You may record the course label as a worksheet mapping once provenance/content are verified; do not rename or rewrite the original merely to add the label.
The library is navigation to original files. It does not make a new copy of each deliverable. You should not have to manually inspect `.copilot-tracking` or tool transcripts to find the answer.
## Ask Cowork to locate it for you
Use this **retrieval request**, filling the label from your exercise and the real run ID if it was returned:
If no run ID was returned, ask Cowork to recover it from the current request's actual response/activity evidence. Do not fill the placeholder with the exercise label or guess it from a project-wide inventory.
You use normal Cowork conversation. The plugin performs the supported same-run history/status operations; you do not type guessed MCP parameters.
**Exercise 10, prompt 1:** a project read-back may be Cowork navigation over existing verified originals, not a new HVE deliverable. Record "no new work run" when appropriate and follow the originals it cites. If new baseline development was actually requested, record its separate real run/output. Never manufacture a run or server artifact just to satisfy the label.
## Which file is correct when there are several?
| What you see | What to do |
|---|---|
| Current request's verified original with the requested content | Open it and apply the exercise's review/action instructions |
| Older accepted version and a newer draft | Inspect the new draft as draft; preserve both references and actual supersedes/review evidence |
| Same title in another run | Do not assume it answers the current request; confirm provenance |
| Original draft plus Cowork summary | Use the original as the evidence; the summary is navigation/explanation |
| File missing the requested content | Name the missing section and request a bounded correction through normal HVE work |
| File retrieval/mirror pending or conflicting | Ask for retrieval/sync recovery of the existing run; do not request the work again merely to obtain a link |
| Failed/held run with a saved partial draft | You may inspect the draft, but do not call the prompt completed or the draft accepted |
If `START-HERE.md` or the library is missing, ask Cowork to refresh its stakeholder navigation from already verified project evidence without new HVE work. If the installed release cannot do that, ask the facilitator for the supported original-output retrieval path. Do not create a parallel deliverables folder.
## Find the decisions and next action
After reviewing an output, ask Cowork to show the selected project's `library/decisions.md` and `library/next-steps.md`.
- The decision view shows actual unresolved questions/findings, owners and supported response routes. Return to Cowork's native question flow for a live server question; editing a Markdown checkbox is not an answer submission.
- The next-step view shows the current action, its prerequisite, actor and evidence link. Compare it with the task you recorded in your receipt.
- Missing owners/dates remain Unassigned/Not set. Do not silently nominate yourself.
- Your planning disposition, document acceptance, operator blocker and synchronization issue must remain different entries/states.
These pages help you locate what to do. They do not authorize new HVE work, external writes or approval by themselves.
## Do something concrete with the content
Every prompt has a **Find this output / Do with it / Next** block:
It also names a **Decision step** (DS). Use the output to choose features, compare a model, test a relationship or decide a scope change. For example, a canvas inspection schema should explain how selected checklist, finding, evidence and remediation features are represented. The task is not changing a formula or designer property.
| Output type | Learner action | Where it goes next |
|---|---|---|
| Needs/feature hypotheses | Match proposed features to interview evidence and resolve unsupported assumptions | Feature choice |
| Feature priorities | Select included/deferred/rejected features and record value/technology dependencies | Schema alternatives |
| Schema options | Draw relationships, test sample records and challenge fields with no selected-feature purpose | Change impact |
| Changed design | Decide which feature/data consequences belong now versus later | Decision pack |
| Feature/schema pack | Have a partner explain rationale, alternatives, record walkthroughs and open decisions | Prototype/build brief and offering |
"Read and reflect" is not the deliverable. Your visible output is a receipt entry, a content-specific decision/question, a handoff or a next-task instruction.
## Tell Cowork what you decided
Use the actual artifact reference you recorded:
A worksheet disposition does not change the library's Accepted label. The library may show Accepted only with the actual server acceptance evidence and required human approvals. Editing a Markdown row is not submitting a server answer or releasing a gate.
If server review says revise/FAIL or a mandatory condition is unresolved, do not carry the artifact forward as approved. You may review a retained draft, then request the supported correction. A terminal run is not resumed by inventing a question ID; new work needs the normal authorized handoff.
## Worked example: inspection schema choice
**Illustrative content only, not an output from your run.**
Suppose the original schema comparison says:
- Feature: one visit can have zero or many independently owned findings.
- Option A: fixed Defect 1 through Defect 10 columns.
- Option B: a visit record related to repeatable finding records.
- Photo evidence is deferred until access/retention needs are resolved.
You should:
1. Find that content in the actual current-run artifact and record its real reference.
2. Walk a visit with no findings and a derived visit with twelve.
3. Explain which selected feature requires repeatable related records.
4. Record the preferred model, rejected alternative and unresolved photo decision.
5. Submit the change-impact request with that exact artifact reference and disposition.
The example is not a success certificate. If your actual output lacks these topics, ask for them rather than selecting an unrelated file.
## Final handoff
For the workshop, give the original decision pack to a partner through the approved project link. Ask them to explain one selected feature, its evidence and every entity/field/relationship it needs. Record unanswered design questions and any author help.
For real client work, use the approved sharing/engagement process. The course does not authorize sending files externally, creating work items or deploying the plan.
This is a general request, not an unspecified client-design task. If the task refers to an attached interview, selected lab, actual output, handoff or bracketed placeholder without supplying its value, ask me for that exact input first. Do not assume attachments exist or generate a client design without its evidence. The numbered exercise prompts include their full scenarios.
[END STANDALONE CONTEXT]
I reviewed [actual artifact identity/version/path] for [output label].
My workshop planning disposition is [use for next request / revise / hold].
The source-backed reason is [fact or missing condition].
Carry forward [exact accepted scope/rule/choice], with [open question]
still unresolved. Preserve the original output and this disposition.
This is not operator gate approval, a passing server review,
customer authorization or evidence of a deployed component.
A worksheet disposition does not change the library's Accepted label. The library may show Accepted only with the actual server acceptance evidence and required human approvals. Editing a Markdown row is not submitting a server answer or releasing a gate.
If server review says revise/FAIL or a mandatory condition is unresolved, do not carry the artifact forward as approved. You may review a retained draft, then request the supported correction. A terminal run is not resumed by inventing a question ID; new work needs the normal authorized handoff.
Worked example: inspection schema choice
Illustrative content only, not an output from your run.
Suppose the original schema comparison says:
- Feature: one visit can have zero or many independently owned findings.
- Option A: fixed Defect 1 through Defect 10 columns.
- Option B: a visit record related to repeatable finding records.
- Photo evidence is deferred until access/retention needs are resolved.
You should:
- Find that content in the actual current-run artifact and record its real reference.
- Walk a visit with no findings and a derived visit with twelve.
- Explain which selected feature requires repeatable related records.
- Record the preferred model, rejected alternative and unresolved photo decision.
- Submit the change-impact request with that exact artifact reference and disposition.
The example is not a success certificate. If your actual output lacks these topics, ask for them rather than selecting an unrelated file.
Final handoff
For the workshop, give the original decision pack to a partner through the approved project link. Ask them to explain one selected feature, its evidence and every entity/field/relationship it needs. Record unanswered design questions and any author help.
For real client work, use the approved sharing/engagement process. The course does not authorize sending files externally, creating work items or deploying the plan.