Validate changes and review model quality
Check a proposed edit before submission, then assess whether the recorded model can support your decision.
On this page
Choose the check you need
| Check | Question it answers |
|---|---|
| Draft validation | Does this change pass the available submission checks? |
| Model quality review | Which recorded facts or relationships need attention? |
| Owner verification | Does the model accurately describe the business and its systems? |
Use all three when the decision warrants them. A structurally valid change can still contain an incorrect assumption.
Validate a proposed change
When your enabled connection offers validate_changes, ask the client to validate the exact payload it intends to send to propose_changes. Validation creates no proposal and changes no records. Review each error and warning. Confirm the identity of records matched by name, and validate again after corrections. Access, governance and acceptance checks still apply at submission and review.
Validate this draft without submitting it. Show each error and warning, the affected record and the correction required. Ask me to resolve ambiguous matches.
Review the existing model
If your connection offers get_data_quality_summary, use it to begin a bounded review. Ask the client to explain what the result covers and identify the records behind each finding. Check the result in Atlas before proposing corrections. You can also review sources and gaps on individual records.
| Finding to investigate | Next action |
|---|---|
| Missing owner | Ask the business area to establish ownership |
| Conflicting sources | Record the conflict and obtain a dated confirmation |
| Unclear integration direction | Check producer and consumer with their owners |
| Unsupported lifecycle | Confirm the stage or date with the owner |
| Possible duplicate | Compare identity and linked records before proposing a correction |
Use the table as a review checklist. The quality summary’s coverage depends on available scores and access. The broader audit_workspace workflow is planned.
Finish the review
Separate confirmed corrections from open questions. Keep the source, affected record and reason for each proposed correction. Follow the workspace’s change process, then re-read the affected records after implementation. If the summary is empty, confirm its scope and your access, then inspect a sample of the records directly.