Separate the model from the conversation
A coordination team often needs to communicate a small question about a large model. Sending a complete model for every comment creates avoidable version churn and forces recipients to rediscover the relevant view.
An issue exchange can carry a topic, viewpoint, component references, status, and discussion while the model remains managed through its own delivery process. This separation is valuable only when the references still point to the intended model revision.
Treat issue data as a navigable pointer and decision record, not as a substitute for controlled design information.
Give the issue a stable identity
Consider a hypothetical structural review in which a pipe sleeve appears near a column. An issue titled 'Check clash' says almost nothing.
A stable, concise title could identify the location and decision: 'Confirm sleeve offset at Grid D/7 before reinforcement release.' The issue should identify its author, creation date, responsible party, priority basis, and current status according to the project's agreed convention. Avoid inventing local meanings for status labels.
If 'closed' means accepted in one discipline and corrected in another, the tracker will report misleading progress.
Make the viewpoint reproducible
A viewpoint should show the condition from a useful angle and retain enough context to find it again. Include the affected elements, nearby grid or level cues, and a camera framing that does not crop the relationship. Where the format supports component identifiers, check that they survive export and resolve in the recipient's model.
A screenshot can be helpful for quick reading, but it may become detached from model objects. Test an issue by opening it in the receiving workflow, not only by inspecting the authoring screen.
Read diagram notes
- Topic
- ID, question, owner, status
- Model context
- Viewpoint, objects, revision
- Decision trail
- Response and closure evidence
Write the request, not a verdict
Issue text should describe the observation and ask for a defined response. 'Beam wrong' is a verdict without evidence. 'At Level 03, the 300 mm sprinkler main crosses the beam web; please confirm a compliant route or submit a designed opening detail' names the location, observed relation, and requested next step.
The language leaves the design decision with the responsible engineer. If the reviewer's evidence is uncertain, say so. A model issue is not the proper channel to direct an unverified structural alteration.
Keep discussion attached to evidence
Comments should record the reasoning that helps the next participant act: which model revision was reviewed, what constraint was checked, and what decision or information remains outstanding. Avoid using comments to approve a design beyond the author's authority. If the answer belongs in a calculation, drawing, or formal response, link or reference that controlled record.
A short, dated thread can preserve why an issue was resolved, but only if the project has agreed where the formal design decision lives and how it is approved.
Test exchange across tools
An issue that exports correctly from one application may not import correctly into another. Pilot the exchange with representative recipients and inspect title, status, assignee, viewpoint, component selection, and comment history. Check whether identifiers change when the source model is re-exported.
If a later revision invalidates a component reference, the issue may still be understandable through its view and location, but it must be relinked deliberately. A file extension or successful import message is not evidence that every field retained its meaning.
Manage duplicates and dispositions
Different reviewers may report the same condition. Before merging duplicates, verify they concern the same objects and requested decision; nearby but distinct issues can have different owners or consequences. When closing, choose a clear disposition such as corrected, accepted with rationale, superseded, or duplicate if those distinctions fit the project's process.
Preserve a link from a duplicate to the canonical issue. This makes dashboards more honest and lets later reviewers distinguish completed work from items that were simply removed from view.
Use the register to improve review
Issue data can reveal where the coordination process is struggling, but raw counts need context. A package with many issues may have more complex interfaces or may have been reviewed more thoroughly. Track age, recurrence, discipline interface, and reopen rate alongside totals.
For a hypothetical bridge model, repeated bearing-seat questions might indicate that the interface definition is incomplete. Feed that observation into the next review scope or delivery requirement. Issue exchange is most valuable when each item supports a concrete decision and the collection improves future reviews.