Synthetic example Reviewable handoff anatomy
See the structure behind a reviewable handoff.
Follow one reviewer challenge from question to disposition.
DF-01 → AR-01 → SR-01 → HM-01 → RR-01. Fully fictional: no customer, asset, project, real model run, computed result, recommendation, promised deliverable, or claimed outcome.
DF-01 Decision frame
A fictional planning lead asks whether to authorize one bounded follow-up analysis when a limiting assumption may change the review boundary.
- Input / evidence gap
- No evidence establishes that the limiting condition remains stable across the fictional comparison cases.
- Reviewer challenge
- State the decision question before selecting a method, and keep authorization separate from analysis.
- Prior wording
- “Choose a preferred pathway.”
- Revised wording
- “Decide whether a bounded follow-up analysis should be authorized.”
- Disposition
- Changed — the request is limited to an analysis-authorization decision.
- Open item
- Define what evidence would be sufficient to test the limiting condition.
- Next owner
- Fictional planning lead.
AR-01 Model pathway
DF-01 is translated into an inspectable model pathway beginning with an assumption record, without running a real model or calculation.
- Input / evidence gap
- DF-01 · Stability support is missing across the fictional cases.
- Reviewer challenge
- Make the unsupported stability assumption explicit and testable.
- Prior wording
- “The limiting condition is stable.”
- Revised wording
- “Stability is an unverified assumption; compare a stable-condition case with a changed-condition case.”
- Disposition
- Accepted — the assumption becomes a named review item.
- Open item
- Agree the method, evidence source, and reviewer checkpoint before analysis.
- Next owner
- Fictional technical reviewer.
SR-01 Sensitivity record
AR-01 is challenged with two named teaching conditions so the reasoning change is visible without implying a computed result.
- Input / evidence gap
- AR-01 · No project evidence supports either teaching condition.
- Reviewer challenge
- Would the conclusion remain durable if the limiting condition changed?
- Prior wording
- “The conclusion is unchanged across cases.”
- Revised wording
- “The conclusion is conditional because the changed-condition case crosses the stated reasoning boundary.”
- Disposition
- Changed — unsupported durability language is removed.
- Open item
- A real engagement would require agreed inputs, validation, and reviewer acceptance.
- Next owner
- Fictional model-method owner.
HM-01 Handoff memo
SR-01 is converted into a conditional handoff that keeps the evidence gap beside the decision boundary.
- Input / evidence gap
- SR-01 · The fictional sample contains no project evidence or validated result.
- Reviewer challenge
- Do not turn a conditional observation into a recommendation.
- Prior wording
- “Proceed with the pathway.”
- Revised wording
- “Consider whether to authorize a separately scoped analysis of the limiting assumption.”
- Disposition
- Changed — no pathway or action is recommended.
- Open item
- No real conclusion, acceptance, quote, schedule, fee, or authorization exists.
- Next owner
- Fictional decision owner.
RR-01 Review record
HM-01 closes the trace by linking the reviewer challenge, resulting revision, open evidence item, and next authorization owner.
- Input / evidence gap
- HM-01 · Evidence for the limiting condition remains open.
- Reviewer challenge
- The original draft treated an unsupported condition as stable.
- Prior wording
- “Review complete.”
- Revised wording
- “Challenge accepted; language changed; evidence item remains open.”
- Disposition
- Changed — recorded with reason and cross-reference.
- Open item
- Authorize a bounded follow-up, request context, or stop.
- Next owner
- Fictional planning lead.
Authorization boundary: this teaching chain is evidence architecture, not evidence of an outcome. It is not a customer case, testimonial, validated result, recommendation, proposal, quote, formal engineering deliverable, certification, acceptance, or engineering, safety, regulatory, or operational sign-off.
Reference appendix · Artifact anatomy and review-record fields
Each conclusion keeps its reasoning trail.
These reference fields explain the reusable structure behind the completed synthetic sample. They do not contain project values or claim that analysis was performed.
Decision frame
Establish what must be decided before selecting a method or interpreting a result.
- Decision owner and reviewer roles
- Decision question and driving event
- System boundary, constraints, and exclusions
- Available evidence and known gaps
- Decision criteria and authorization boundary
Model pathway
Make the reasoning trail inspectable from agreed inputs through the chosen analytical method.
- Input and assumption register
- Model purpose, version, and ownership
- Method sequence and review checkpoints
- Validation evidence and unresolved limitations
- Excluded uses and required specialist review
Sensitivity record
Record how a conclusion should be challenged without presenting a single run as durable evidence.
- Assumption or condition being varied
- Reason the sensitivity matters to the decision
- Observed model response and evidence source
- Confidence, limitation, and edge-case notes
- Follow-up analysis or reviewer question
Handoff memo
Transfer the decision logic without separating a conclusion from its evidence and boundaries.
- Decision context and scope reminder
- Evidence-supported observations
- Options and trade-offs for review
- Limitations, open questions, and residual uncertainty
- Next authorization or decision checkpoint
Keep the challenge inspectable.
A review record connects each synthetic comment ID to a reviewer role, the section reviewed, the question raised, and its disposition—accepted, changed, deferred, or out of scope—with the reason recorded. It also identifies any resulting revision, open item, and next review owner.
Decision authorization and delivery acceptance are different. A decision owner determines whether to authorize a next action. Delivery acceptance checks agreed artifacts against the written scope; it does not validate system performance or transfer engineering, safety, regulatory, or operational sign-off. The separate written agreement controls acceptance criteria.