Skip to content

Q002 — Self-Audit

1. Eligibility Criteria

  • Were inclusion/exclusion criteria applied consistently? Yes. Sources were included if they directly related to the W3C Credible Web Community Group, Credibility Coalition, CCIV, or Credibility Signals specification. Sources about other W3C groups (Verifiable Credentials, ODRL) were excluded.
  • Were any borderline sources excluded that could change the finding? The survey on automatic credibility assessment (SRC-Q2-14) was included as it references the credibility signals work in an NLP context. Other NLP papers using credibility features were excluded as they typically do not reference the CredWeb specification directly. Including them might strengthen the indirect-adoption finding but would not change the core assessment of what the specification contains.

2. Search Comprehensiveness

  • Were searches sufficient to find disconfirming evidence? Partially. Search 2 explicitly looked for evidence of abandonment, and Search 3 looked for evidence of active participation. Both returned useful results.
  • Were there obvious search strategies not attempted?
  • Direct inspection of the W3C mailing list archives for public-credibility@w3.org could reveal more recent discussion activity.
  • Direct inspection of the GitHub repository (git log) would give precise last-commit dates.
  • Searching for presentations or publications by key participants (Sandro Hawke, credweb chairs) could reveal ongoing work not published through the group.
  • Assessment: The characterization of the group as "dormant with periodic check-ins" is well-supported by the combination of quarterly meetings (active) and no specification updates since 2020 (stalled), but direct mailing list inspection could refine this assessment.

3. Evaluation Consistency

  • Were supporting and contradicting sources evaluated with equal rigor? Yes. Evidence of activity (quarterly meetings) was given equal weight to evidence of stagnation (no spec updates, no GitHub commits). The assessment explicitly characterizes the middle state rather than defaulting to either "active" or "abandoned."
  • Was there bias toward finding the specification inadequate? RISK IDENTIFIED — The query specifically asks whether the specification includes four features (evidence quality scale, confidence language, bias assessment, source tiering). This is a checklist framing that inherently favors finding absences. The assessment mitigates this by noting what the specification DOES provide (valuable taxonomy, observable features, user-empowering design) in addition to what it lacks.

4. Synthesis Fairness

  • Does the synthesis give fair weight to all evidence? Yes. The partial presence of source reliability indicators is acknowledged rather than dismissed. The specification's design philosophy (descriptive, user- empowering) is presented as a deliberate choice, not a failure.
  • Is the researcher's bias visible in the analysis? The framing of the four features as a checklist matches the query structure. However, the assessment could be criticized for measuring the specification against criteria it was never designed to meet. The Credibility Signals specification was designed to be a vocabulary of observable features, not an evidence evaluation methodology. Judging it against GRADE-like criteria may be a category error. The assessment notes this in the "What the Specifications Actually Provide" section.

5. Source-Back Verification

  • Can every factual claim in the assessment be traced to a specific source? Yes. All claims reference SRC IDs with URLs.
  • Were any claims made without source backing? The characterization of meeting content (guest presentations, quarterly check-ins) is based on meeting titles and descriptions in the W3C group page, not on reading actual minutes. This inference is noted in the Gaps and Limitations section.
  • Were URLs verified as accessible? URLs were verified at search time. credweb.org pages and W3C pages were accessible.