Why it matters
This is a strong bridge article between the two products because it explains how review and correction can sit in different tools without inventing a seamless magic story.
Section 1
Checking is the easy part
Most teams can produce a validation result. The hard part is deciding what to do with it before the exchange window closes. If fifty doors all fail the same property rule, the issue is not the count. The issue is whether the workflow can push a controlled correction back into the model fast enough.
Section 2
What breaks the loop
The loop breaks when checking and correction live too far apart. One team exports a report, another team interprets it manually, and a third team tries to repair values without a consistent write-back process. By then the original review context is gone.
Section 3
A more realistic split of responsibilities
A practical setup is to keep review, grouping, and issue packaging in ExyViewer, then move into ExyRev when the workflow genuinely needs model-side correction. IDS Spec supports the rule and checking side; IDS_Map supports the part where wrong or empty values have to be corrected against those expectations.
Section 4
No magic, just a shorter loop
That does not make IDS automatic. Someone still has to own the requirements, approve the corrections, and control the scope. But it does shorten the distance between “we found a problem” and “the values are now fixed in the model.”
Practical takeaways
- A validation result without a correction path has limited project value.
- ExyViewer and ExyRev solve different parts of the IDS loop.
- The goal is not automation for its own sake but faster controlled correction.
Reality check
- If the IDS requirements themselves are unclear, correction speed does not help. Bad rules only produce faster wrong edits.
Related commands and features
See the verified IDS commands
The toolbox guide now documents both ExyViewer IDS review and ExyRev IDS Spec / IDS_Map workflows.
Open IDS review commands
