Open navigation menu
Methodology
Evidence-led methodology for structured findings.
CertScore reviews public website signals and browser behavior, retains reproducible evidence, applies deterministic confidence rules, and surfaces structured findings rather than legal conclusions.
This page explains what CertScore tests, what “not detected” means, how evidence is retained, how confidence is assigned, and why the product avoids legal certification or legal pass/fail language.
How findings are surfaced
CertScore does not treat every raw detector output as a report finding. Observed signals are evaluated using evidence thresholds, support strength, contradiction checks, and scan-context limits. Depending on the retained evidence, an item may be surfaced as a finding, held for reviewer attention, used as supporting context, or suppressed.
What CertScore reviews
CertScore reviews public-facing website surfaces such as disclosure pages, privacy-choice interfaces, browser behavior after page load, and automated accessibility results on tested public pages. The system is designed to assess observable website signals, not to issue legal conclusions.
What counts as observable evidence
Observable evidence includes screenshots, retained DOM excerpts, timestamped network requests, cookie and storage changes, session interaction logs, and automated accessibility results on tested pages. Findings are expected to cite concrete, reviewable evidence rather than broad narrative statements.
How scans are run
Scans use a defined browser profile, test a bounded set of public pages and key flows, record methodology metadata, and retain timestamps for the evidence captured during the session. Repeatability is noted when behavior is rechecked across multiple pages or sessions, but scanning remains bounded by the tested context.
How privacy-choice testing works
Privacy-choice testing looks for publicly visible rights and opt-out surfaces, observes whether tracking appears before or after a tested choice interaction, and records control-state evidence where it is externally visible during the scan.
How browser-signal testing works
Browser-signal testing compares signal-enabled and control conditions when configured, then looks for observable confirmation, persistence, or behavior changes that may indicate the site reacted to the tested browser-level preference.
How accessibility testing works
Accessibility testing uses automated checks on tested pages and flags barriers that were directly observed. Automated testing can reveal many important issues, but it does not by itself determine WCAG conformance or legal posture. Manual review remains important for complete evaluation.
Confidence and severity methodology
Confidence is assigned by deterministic rules based on evidence type count, repeatability, and the presence or absence of contradictory signals. Severity reflects the materiality of the observed gap on tested flows, not a legal penalty estimate or official score.
What “not detected” means
Not detected means the expected public surface or behavior was not evident under the tested conditions. It does not mean the capability is absent in every environment, account state, jurisdiction, or page state.
Important limitations
CertScore observes only what can be seen from the tested public conditions. Internal processing, server-side controls, private dashboards, and region-specific behavior can differ. Authenticated, personalized, or geofenced flows may not be covered in the retained evidence.
Why findings are posture-based and not legal conclusions
Findings intentionally use conservative posture language because CertScore is not a legal conclusion engine. The product is built to support skeptical review with reproducible evidence, clear methodology, and explicit limits on what automated scanning can defensibly determine.
Deeper insights
Use scan evidence to support deeper review.
CertScore can do more than surface obvious findings. It helps teams connect runtime evidence to broken user controls, disclosure gaps, and broader public-facing trust signals.
Unexpected Vendor Signals
Surface tracking and vendor behavior that merits closer review.
Use retained runtime evidence to review scripts, requests, and vendor activity that appear outside the expected website stack.
Consent Flow Review
Identify when a "Privacy Request Form" or "Reject" path may be missing.
Spot consent journeys where user controls appear absent, incomplete, or inconsistent with the public-facing path the site presents.
Trust And Disclosure Context
Use public website signals to support broader trust and diligence review.
Use scan evidence as an early signal when weak consent, disclosure, or accessibility posture may be contributing to trust, diligence, or discoverability concerns.
Reviewer Notes
Additional reviewer-facing context
Reviewer-oriented methodology notes
Each scan stores browser profile settings, consent reset behavior, page-selection metadata, signal-testing conditions, and evidence-collection flags so reviewers can understand what was and was not tested before relying on a finding.
Evidence and contradiction handling
Claim-vs-behavior gaps are surfaced only when exact public claim text is retained, the claim is materially relevant, and concrete timestamped behavior evidence is also retained. Low-confidence items are held for reviewer attention by default.
Safety controls
All findings and customer-facing output pass through prohibited-language validation and sanitization before they can be persisted or displayed. Outputs that cannot be safely rewritten are blocked.
Need the product overview too?
This methodology explains how findings are produced. The product walkthrough shows how those findings appear in CertScore.ai.