A dashboard count is only the beginning

A reconciliation dashboard can report archive-only records, live matches, multi-drawing lines, specification differences, or endpoint gaps. Those numbers are useful for orientation, but they are not enough for engineering review.

Every metric should lead to the exact population behind it. Reviewers need to see the logical-line record, the matching method, linked drawings, linked live objects, and the source attributes that produced the classification.

Use deterministic, named semantics

Terms such as matched, missing, complete, and ready can imply more authority than the underlying data supports. Reconciliation labels should describe the actual computation rather than the conclusion someone might infer from it.

  • Normalized live match: the current matching rule returned one or more linked live objects.
  • Archive-only candidate: the current rule returned no linked live object; this does not prove physical absence.
  • Potential endpoint gap: one or more stored endpoint values are blank; this is not a physical connectivity verdict.
  • No selected review flags: the chosen checks did not trigger; this does not mean approved or turnover-ready.

Protect the source system

A diagnostic client should use a read-only account, parameterized queries, a fixed query registry, bounded inputs, and server-side access. The browser should never receive database credentials or an arbitrary query console.

Static demonstration data must be clearly labeled and explicitly activated. Silent fallback from live data to a captured dataset can create false confidence about the current source state.

Design the review journey

The useful flow moves from command-centre indicator to table population, then to a scoped evidence sheet, and finally to drawing or object traceability. Data Quality and report surfaces should reuse the same canonical populations rather than implementing conflicting counts.

This design reduces the distance between an executive signal and the evidence an engineer needs to investigate it.

Software should not overclaim

A reconciliation diagnostic can organize source-derived evidence and prioritize review. It should not claim drawing approval, engineering verification, revision authority, physical completeness, or turnover readiness unless a separate governed process actually supports those decisions.

Clear boundaries are not a weakness. They are part of trustworthy industrial software design.