Identify the current starting point
Name the case, current design revision and governing reference before describing the edit. Include a marked view that belongs to that revision. A screenshot from an earlier proposal may ask the designer to change a feature that no longer exists.
Classify the request in ordinary language: correction against the existing brief, preference adjustment, new clinical instruction or replacement record. The classification helps both teams agree whether scope and dependent approvals need to be revisited. It should not be used to dismiss legitimate feedback.
Make the requested difference observable
Instead of “make it better,” identify the feature and the reference or receiving requirement it should follow. Use a view that shows the relationship in question, not an attractive angle that conceals it. Keep the note focused on the requested difference; unrelated comments can become separate items.
Illustrative wording: “Review revision C against reference R2 at the marked anterior segment. Confirm whether the proposed form follows that reference before replacing the review output.” This describes a review task without inventing a clinical setting or guaranteeing an outcome.
Record ownership and dependencies
| Item | Write down |
|---|---|
| Starting state | Case ID, design revision and named input/reference package. |
| Requested change | The marked location and intended difference, with approved evidence. |
| Decision owner | Who can clarify or approve this specific question. |
| Affected outputs | Design files, review views or dependent segments that need replacement. |
| Completion evidence | A revised view and note describing what changed or remains unresolved. |
If two instructions conflict, ask the responsible team to choose the governing instruction. A remote designer should not resolve that conflict by guessing which person has authority. Hold the affected work while preserving the last known state.
Close the revision loop
Return the revised package with a short response to each item: addressed, needs clarification or outside the agreed scope. Link the response to the new revision and retire superseded files using the release manifest. “Done” alone does not tell the receiver what changed.
Record recurring ambiguity in the exception log. If a request represents a new lab default, update the preference packet only after that default is approved; a one-case exception should not silently become a rule for future work.
Prepared by Pristine Dental Design · October 6, 2026. Guidance for professional case communication and review. Actual prescriptions, manufacturer requirements and receiving-team approvals govern design and production.