Interpret QCDR Discovery Source Evidence and Confidence Levels

Discovery deliberately separates source evidence from ordinary page context. It ranks candidates as PROVEN, HIGH, MEDIUM, or LOW so an administrator can tell an exact runtime boundary from a plausible stored-source candidate.

Confidence describes the strength of the evidence QCDR has for that candidate. It is not a guarantee that QCDR identified an exact PHP file and line.

PROVEN: Exact Runtime Evidence

PROVEN is reserved for evidence QCDR observed directly in the private request. Examples include:

  • the exact Joomla component or module render boundary surrounding the selected DOM node;
  • an inert private-Discovery boundary around an exact standalone QCDR Token output;
  • a structured Token element carrying QCDR's runtime attribution;
  • Dynamic DOM Watch observing the selected element or an ancestor change after the watch began.

Even PROVEN late-DOM evidence proves browser-side timing, not the responsible JavaScript file, library, network response, or call stack.

HIGH: Strong Correlation or Stored-Data Match

HIGH evidence can include a QCDR Rule's recorded after-snippet containing the selected output, a resolved Token sample matching it, stored module data matching inside an exact module region, current article title/body/custom-field matches, an active menu title/link match, or an exact Joomla language-string value.

These are strong candidates, but some still describe correlation or stored data rather than element-level runtime attribution.

MEDIUM: Useful Context That Needs Confirmation

MEDIUM evidence includes cases such as the current article owning the route without containing the selected value, the active menu context, a template override that exists for the current component/view, the active template shell, a language string that merely contains the selection, or related stored QCDR Rule/Token definitions without exact runtime proof.

LOW: Weakest Candidate

LOW is the weakest supported confidence class. Treat it as a lead to investigate, not as a target authority. A low-confidence candidate should never be used by itself to justify changing a Rule's scope or find value.

How Stored Evidence Is Retrieved

When you inspect a selected element, the browser first adds local runtime evidence. QCDR can then perform a private same-session POST back to Administrator to compare the selection with Joomla records, custom fields, menu data, language files, template candidates, and stored QCDR Rules/Tokens. That lookup uses the same short-lived Discovery authorization and fails safely if the session has expired.

Read the Ranking Correctly

  1. Start with PROVEN runtime boundaries if present.
  2. Use HIGH candidates to identify likely stored data or transformations.
  3. Use MEDIUM/LOW evidence to guide investigation, not to skip verification.
  4. Confirm the eventual Rule with Preview and Rule Health before enabling it.

Discovery never turns a ranked candidate into an automatic edit, and it never silently retargets a Rule because one candidate appears stronger than another.

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.