What are the rules for Link Validity when the associated artifact is modified?
On a simple level - a change to an artifact's attributes (such as Title/Description/Text content) the Validity should (and does) revert to Suspect.
For example: If the Link Validity has been set to Valid for artifact 1001 - and the Text Content for artifact 1001 changes from "old text" to "new text" - the Link Validity will now be shown as Suspect.
What we've found, however, is that History plays a role - If the Link Validity for the new value is set to Valid and then the artifact is again changed back to a prior value where Link Validity was Valid (i.e. back to "old text") then Link Validity is NOT reported as Suspect - but is instead reported as Valid. Or - more accurately - setting the artifact data to a prior value for which a Link Validity state was assigned causes that earlier assigned Link Validity state to be reported for the artifact.
Is this behavior indicated above - what is Expected/Intended for Link Validity? The answer will affect how we plan to test Link Validity - it was not what we expected (our expectation did not encompass any 'history' contribution, rather - any change (even to an older value) would result in Link Validity being set to Suspect .. this seemed to be a safer choice (and less complicated) to ensure that the associated Links were always reconsidered by the team after a change..
Product Version/Patch: CLM 6.0.1 iFix002a
Accepted answer
Comments
Hi Geoff,
Note that baselining does not affect the behavior of the Validity Service (it doesn't care whether or not a particular version is captured in a baseline) ... that was just a way to set up the re-use example. So the sharing of the validity information is based solely on the content of the versions on each end of the link.
Also note that Validity Status is on the link between two artifacts ... not on an artifact. A particular link is flagged as "suspect" if no human has ever declared that the two linked artifact versions are valid for that link type. An artifact does have a "link validity summary status", which is the minimum Validity Status of all of the links from that artifact to an upstream artifact.
It appears that you are not looking for link validity information, but rather "what artifacts have change since some specific point in the past". In a versioned world, that information is not obtained from Link Validity, but rather by comparing your current configuration with the configuration at that specific point in the past (captured by a baseline). This is done with the "compare" command.
I am aware of the configuration comparison capability and acknowledge its value. And I recognize that Link Validity state is separate from the artifacts. Though I may have a different preference, I will ultimately accept the answer that it is working the way you, and the preponderance of users, intend for it to work (which, in summary, is that once a human has EVER set the Link validity state for the link between two artifacts that it will always be returned to that state regardless of the trajectory of changes made to the artifacts in the interim. If the trajectory again touches an earlier state matching one where validity had once been set - the link validity will, again, be reported for that state).
One way to think about it is that Link Validity is for a binary relationship with well defined semantics. So for example, if the artifacts are numeric formula, and the binary relationship is "equals", then if some human has asserted that the "equals" is valid for the two expressions "1+2" and "3", then any time you see the "equals" link type between the two artifacts whose content are "1+2" and "3", the system should tell you that this link is Valid". If you modify the content of the second artifact to be "4", the link will become "Suspect", but if you switch the second artifact back to "3", the link will again become Valid. You wouldn't want the system to respond by saying "you changed the second artifact, so the status must be Suspect".
In our domain, the artifacts are things like test cases and requirements, but with the same rationale ... if someone has stated that the content of this test case is a valid test for the content of this requirement, then if you make some modifications to either the test case or requirement, but then restore the test case and requirement to the valid content, the system should tell you that the test case is a valid test for that requirement.
Thanks Geoff - that explanation is helpful.