Engineering review comments: cluster duplicates without closing decisions

The workflow should retain the original wording, reviewer, document identifier, revision, location, submission date, and attachment references. If comments arrive through several channels, preserve the source channel and source identifier too.

A spreadsheet row number is a fragile identity because rows can move. I would assign a stable internal identifier and retain the external reference. That makes it possible to merge imports without losing the relationship to the reviewer's original submission.

The location field also needs care. A page number, drawing grid, model element, and specification section are different types of reference. Preserve the type and value rather than flattening everything into a free-form note that is difficult to compare.

A model can suggest that comments concern the same issue and explain the shared subject. The review interface should show the candidate group, each original comment, and the relevant document revisions.

I would allow the coordinator to accept the grouping, split it, or leave comments independent. The model should not delete a supposed duplicate. Even genuinely overlapping comments may need separate responses because different reviewers must acknowledge the resolution.

For an illustrative group about access clearance, one comment may ask for a dimension and another may challenge the underlying arrangement. A shared keyword is not enough to establish that the same response resolves both. The grouping explanation should help the coordinator notice that distinction.

Routing a comment to an electrical, structural, mechanical, or coordination owner can reduce administrative work. It should not imply that the assigned person has accepted the comment or approved a proposed solution.

The organization should define what happens when a comment crosses disciplines. The workflow might assign a lead owner and supporting reviewers, or route it to a coordination queue. A model should not resolve an ownership dispute by choosing the first familiar discipline label.

Every assignment needs an accountable person or an explicit team queue with a defined owner. If a reviewer is unavailable, the fallback should come from the team's process. Automatically assigning work to an inactive account creates the appearance of progress without a usable handoff.

A response draft should refer to the specific comment and the proposed resolution evidence. If a revised drawing addresses the issue, link that drawing and revision. If the response explains why no change is proposed, retain the authorized rationale.

The model should not invent calculations, standards references, or technical justifications to make a response complete. Missing evidence should become a question for the responsible engineer. A plausible technical paragraph can be especially harmful because it may discourage further review.

I would label generated response text as a draft in the working interface and prevent it from being issued under an engineer's name without the required approval. The approval record should identify the exact response revision and supporting material.

A comment associated with revision B may need re-evaluation when revision C arrives. The workflow should show that relationship rather than assuming a new file resolves all open comments.

A document change can invalidate a proposed response or create a new coordination issue. I would compare the comment's referenced revision with the current review package and route stale responses for inspection. The software can identify the mismatch without deciding its technical significance.

For systems using Microsoft 365, Microsoft Graph delta queries provide a mechanism for tracking changes to supported resources. That can support synchronization, but the engineering meaning of a revision still belongs in the application and review process.

The close action should record who closed the comment, which response was accepted, and what evidence supported that decision. If a comment is reopened, preserve the prior closure and the reason for reopening.

A group-level action needs special care. I would show every affected comment and require confirmation that the response applies to each one. Where reviewers have separate acceptance authority, the system should retain separate acceptance states even when the comments share a response draft.

The dashboard should distinguish answered, awaiting acceptance, closed, and reopened. Counting every answered comment as closed can misrepresent the remaining review workload and cause teams to issue documents prematurely.

Reviewer attachments and comments are input data. They should not be able to change permissions, bypass approval, or instruct the system to hide other comments. The extraction component needs only the access required to prepare its suggestions.

OWASP's prompt injection guidance is relevant when external text is processed by a model. I would enforce assignment and closure permissions in the application, independent of any instruction embedded in a comment.

The audit trail should record operational events without copying unnecessary sensitive design material into broad logs. Keep source documents in their approved repository and link to them from the restricted review system.

I would create synthetic comments with similar wording on different revisions, different issues at the same location, genuine duplicates from separate reviewers, and a response that addresses only part of a group. Include an import replay and a document update during approval.

Acceptance should verify that no original comment disappears, that grouping can be corrected, and that closure requires the right authority and evidence. Measure incorrect grouping, reassignment effort, response-review time, and reopened comments.

The first release should make the queue easier to navigate while preserving the engineering team's judgment. A useful handoff includes the comment schema, state definitions, reviewer roles, import recovery procedure, and a test packet showing where the automation deliberately stops.

For the demonstration, I would create two synthetic comments about the same drawing location. One requests a missing dimension; the other questions whether the arrangement meets the project's stated requirement. The model may group them for navigation, but the system should retain separate decision states.

An engineer then supplies a revised drawing that adds the dimension. The first comment can proceed through its acceptance process. The second remains open until its own issue is addressed. Closing the group should not silently close both comments.

I would also import the same reviewer file again after a coordinator changes the assignment. The replay should recognize existing comment identities and preserve the authorized assignment. This checks a practical source of rework: repeated imports that reset a queue after staff have already organized it. The acceptance record should show the original comments, the grouping, the partial resolution, and the surviving open decision.