Use Discovery Target Fingerprints for Drift-Aware QCDR Rules

A Target Fingerprint is advisory evidence captured from the selected DOM element when a Rule is prepared from Discovery. It helps Rule Health recognize whether the original target still looks the same later, without giving QCDR permission to rewrite the Rule automatically.

Fingerprints are most useful when visible wording alone is not a stable identity signal—for example, a button whose text changes but whose element ID, link, render region, and surrounding structure remain recognizable.

What a Fingerprint Captures

QCDR 1.1.05 stores a versioned fingerprint that can include:

  • element tag, ID, classes, and selected stable attributes such as href, src, alt, title, role, aria-label, and data-id;
  • visible element text and the selected find value;
  • parent element identity and nearby visible text before/after the target;
  • route context such as component, view, menu item, content record, and URL;
  • an exact component/module render boundary when Discovery observed one;
  • late-DOM timing evidence when Dynamic DOM Watch observed a change;
  • the strongest source-evidence candidate available when the Draft Rule is prepared.

How Rule Health Uses It

Rule Health compares the saved fingerprint with the current rendered page. An exact current candidate, matching render region, and unchanged route context can produce an exact-target pass.

If the original target is not exact but QCDR finds a sufficiently similar element, Rule Health reports a likely candidate as informational drift evidence. In the current runtime health check, a candidate scoring at least 35% can be reported as a likely match. A weaker or missing candidate fails the fingerprint check.

QCDR Never Adopts the Candidate Automatically

A fingerprint is not a self-healing selector. QCDR does not copy a similar element into the Rule, change the find value, or retarget page/extension scope. The health message explicitly tells you to review the candidate in Discovery before changing the Rule yourself.

Route and Render Drift Matter Too

Rule Health also compares component, view, content record, menu context, and the saved component/module render boundary when those signals exist. A visually similar element on a different route or after a render-region change is weaker evidence than the same element in the original context.

Refresh a Stale Fingerprint

  1. Open a fresh Discovery session on the current page.
  2. Select the intended current output again.
  3. Review the evidence and fingerprint identity signals.
  4. Create a new Draft Rule or deliberately update the existing Rule after comparison.
  5. Preview the saved result before enabling it.

Legacy or malformed fingerprint data is ignored safely and reported as informational. Recreate the Discovery handoff when you want current drift evidence.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDR feature? Visit the QC Dynamic Replacer Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.