# A clearer workshop handover

Live scoped review of three synthetic teaching cards. These findings are model analysis, not observed workshop results.

Thread: Can three cards turn an ambiguous handover into a useful, testable software brief?

What this supplied example actually establishes

- Minimal required fields and scope: The idea node defines the smallest digital data model as equipment label, issue, owner, next action, status and timestamp, plus an acknowledge action and JSON/CSV export (handover-concept).
- Illustrates the problem pattern and ambiguity: The sample handover shows repeated ambiguity about ownership, next action and review-closure (sample-handover). The sample is explicitly synthetic and not field-validated.
- A constrained implementation boundary: The candidate solution is explicitly single-device, local-browser, no integrations, no sign-offs, and no automated decisions; supervisors remain out-of-app authorities (handover-concept).

(References used: nodes: handover-question, sample-handover, handover-concept.)

Assumptions (explicit, potentially fragile)

- Staff will use a single shared tablet reliably at shift handover (derived from handover-concept). Assessment: tentative; origin: human.
- Supervisors will continue to make operational decisions outside the app and accept exported CSV/JSON as the audit (handover-concept). Assessment: tentative; origin: human.
- The six-field model (equipment, issue, owner, next action, status, timestamp) is sufficient to remove ambiguity in practice (sample-handover + handover-concept). Assessment: untested; origin: human/agent (canvas content).
- Paper validation before software will reveal whether software is justified (handover-question + handover-concept). Assessment: methodological assumption; origin: human.

Paper-checklist alternative (one-page validation instrument)

Create a laminated single-sheet form that strictly maps to the candidate software fields and an acknowledgement box. Checklist items:
- Equipment label (printed list or write-in)
- Short issue description (max 12 words)
- Current owner (name/initials)
- Next action (one-line, actionable verb + owner)
- Status (open / awaiting_review / closed)
- Timestamp and shift ID
- Next-shift acknowledgement (initials + timestamp)

Use: place with shift log and require next-shift initial acknowledgement. The paper checklist is the exact minimal test bed to validate the software hypothesis before engineering effort.

Smallest useful workflow and data fields (explicit, implementation-minimal)

Workflow (end-to-end, minimal):
1. End-of-shift: originating operator creates or updates an item with required fields.
2. System records timestamp and shift ID.
3. Next-shift opens the list (top-sorted by unresolved) and either acknowledges (claims) or updates the next action.
4. Supervisor reviews exported CSV/JSON periodically and marks closure outside the app.

Data fields (absolute minimum):
- item_id (system-generated)
- equipment_label (string)  [required]
- issue_short (string, <=140 chars)  [required]
- current_owner (string/initials)  [required]
- next_action (string)  [required]
- status (enum: open, awaiting_review, closed)  [required]
- created_ts (ISO timestamp)
- last_updated_ts (ISO timestamp)
- shift_id (string)  [optional but recommended]
- acknowledged_by (string) + acknowledged_ts (ISO)  [to record handover acceptance]

Three concrete acceptance checks (each labelled a pilot target)

Pilot target 1 — Field completeness: >=90% of entries during pilot include all required fields (equipment_label, issue_short, current_owner, next_action, status, timestamp). Measurement: audit the paper forms or app records. (pilot target)

Pilot target 2 — Acknowledgement latency: >=80% of open items are acknowledged by the next shift within 15 minutes of shift start. Measurement: compare acknowledged_ts to shift start times from the log. (pilot target)

Pilot target 3 — Ambiguity reduction: After two consecutive shifts, <=10% of items remain with ambiguous ownership or unclear next action (measured by an external reviewer checking entries against a short rubric). (pilot target)

Next experiment (single, explicitly defined action)

Action (one): Run a supervised paper-checklist pilot for one workshop for two weeks (covering at least 10 distinct shift handovers). Demand: ensure supervisor signs off on each pilot-day and collects the checklists for audit.

Data to collect during pilot:
- Completed paper forms (or app exports if already used)
- Timestamps/shift ids
- A short external-review log marking whether each entry meets clarity criteria (yes/no) and why

Decision threshold (explicit):
- Proceed to build the single-device prototype only if the pilot meets all three pilot targets above within the two-week run (>=90% completeness, >=80% acknowledgment latency, <=10% ambiguity after two shifts). If any pilot target is missed, do not commit to software: instead, iterate the checklist (refine fields, training, or shift process) and re-run the paper pilot.

Relationships I relied on and my assessment (must be explicit)

- sample-handover -> handover-question (compatibleConnections: flow/support/association): assessment = simulation (synthetic examples), origin = human (canvas content). Weight: low evidentiary strength because sample inputs are synthetic.
- handover-concept -> handover-question (compatibleConnections: flow/support/association): assessment = tentative design proposal, origin = human. Weight: design intent only; unvalidated.
- sample-handover -> handover-concept (compatibleConnections: flow/support/association): assessment = illustrative mapping (simulation), origin = human. Weight: supports hypothesis generation but does not validate it.

Notes on relationship coverage: scope.relationships contains no citable edges; all connections in the canvas are compatible/organizational and unassessed. I treated them as design-intent relationships, not as empirical evidence.

Small paper-checklist pilot costs and practical notes (brief)

- Low financial cost; main cost is supervisor time to audit forms and collect feedback.
- Training time: 10–20 minutes per shift for instructions; enforceability needs supervisor support.

Limitations (short)

- All sample handovers are synthetic; no observational field evidence is present to show real behaviour.
- Pilot sample (10 handovers/2 weeks) is small and may not capture rare but critical cases.
- Supervisor decisions and closure happen outside the app; closure consistency remains a managerial, not technical, risk.
- No safety, accounts, or integrations are tested in this scope.

Summary recommendation (one-line)

Run the supervised paper-checklist pilot (2 weeks, >=10 handovers) and require meeting all three pilot targets before approving work on the single-device prototype.

## Scope review

Marked scope contains the three cards (handover-question, sample-handover, handover-concept) and the skeptical answer: these supply the minimal data model, a constrained single-device boundary, and explicit paper-pilot targets. However, the marked items do not provide needed technical artefacts, exact evidence references, builder assignment, or export/schema details required to produce a precise light planning specification — the scope is therefore incomplete for a build package.

### Gaps preserved for review

- No specificationBasis candidate ids or documents: the package requires explicit specificationBasis candidates so requirement evidenceVersionRefs can exactly match them (missing entirely).
- No explicit IndexedDB schema and migration plan: exact objectStore names, key paths, field names, types, and versioning strategy are absent but required for precise acceptance tests and serialized storage edits. (essential)
- No JSON/CSV export schema examples: field order, header names, CSV quoting rules and example JSON records are not supplied but necessary to verify exports match requirements. (essential)
- No shift schedule or canonical shift_id format and authoritative shift-start times: required to measure ‘acknowledgement latency’ and implement shift_id storage and pilot measurement. (essential)
- No builder identity or assignment: the constraint requests ‘use one builder’ and serialize schema/storage edits; the package must name or identify the builder responsible for implementation and schema edits. (essential)
- No acceptance test harness definitions and data collection format for the pilot: exact audit checklist format, sampling plan (how 10 handovers are chosen), and procedures for external reviewer rubrics are missing but needed to operationalize the pilot targets. (essential)
- No device/browser support constraints and offline behavior spec: required to design a single-browser IndexedDB app (minimum supported browsers, expected storage capacity, offline/restore behaviour) — absent but needed for implementation planning. (useful)
- No explicit decisionRefs or approval mechanism and no supervisor sign-off artifact: the mandate forbids inventing approvals, so the package needs to record how decisions will be captured or left external (e.g., supervisor sign-off form) — currently unspecified. (essential)