Truth & Confidence Methodology

PolicyWatcher is a tracking and mapping tool, not a compliance certification body. The data presented on this platform:

• Evaluates public disclosures and terms of service text, not internal company operations.
• Does NOT certify that a company complies with its policies, or that the policies comply with applicable laws.
• Must not be treated as legal advice, formal auditing, or compliance validation.
• Is intended for risk screening, benchmarking, and policy lifecycle tracking.

To avoid fabricated data and expose source failures clearly, the ingestion pipeline uses a prioritized retrieval cascade:

• Primary source: direct HTTP retrieval of the configured policy URL with browser-like headers, redirect validation, retries, and timeout limits.
• Protocol fallback: explicit HTTP/2 retrieval is attempted for providers that reject HTTP/1.1 or return short SPA shells.
• Rendered fallback: when configured, a separate VPS renderer executes a headless browser fetch for script-rendered pages. It is protected by bearer auth and validates initial URLs, redirects, and subresource requests against SSRF rules.
• Provider-challenge handling: if an official page is protected by anti-bot or WAF controls, the renderer result is still treated as insufficient evidence unless usable policy text is retrieved. The source stays suspended until a verified baseline, official PDF, or traced admin review confirms it.
• Archive fallback: if live retrieval fails, the pipeline may try Wayback Machine and Common Crawl snapshots where available.
• Freshness guard: archived snapshots older than the last successful check are rejected so an old cached copy cannot be registered as a new policy change.
• Strategy diagnostics: each retrieval attempt records the strategy used, outcome, HTTP status where available, rejection/failure reason, and whether the system escalated to the next fallback.
• Host-drift guard: live redirects to a different host are marked for review instead of being accepted as baseline evidence.
• Path-drift guard: configured policy URLs that resolve to a same-host homepage or non-policy landing page are rejected instead of becoming baseline evidence.
• Completeness guard: over-cap extraction is marked Partial and suspended from public evidence instead of being stored as a complete policy text.
• Batch execution: administrative scans can be limited by company slug or policy count so the first source-verification run can be resumed safely on shared hosting.
• Honest failure recording: if a page remains unreachable, the system does not create a successful version record from missing data. It updates the policy status to "Unavailable" or "Needs Review" and writes a check-log row.
• Hash fingerprinting: retrieved text records are fingerprinted with SHA-256 so later integrity checks can detect mismatches between text and hash.

Automated reviews are processed using Google Gemini models. To prevent hallucination and ensure auditability, the AI is subject to strict engineering constraints:

• Direct grounding: summaries and bullet points are generated from the retrieved/versioned text record being analysed.
• No unsupported filling: prompts instruct the model to return "Not Specified" or "Unavailable" when the document does not support a field or KPI.
• Structured mapping: categorisations are normalized against the expected analysis fields used by PolicyWatcher.
• Audit trail: Every AI analysis is linked directly to the specific policy version records (old vs. new) from which it was generated.

Confidence is built on evidence, not trust. PolicyWatcher exposes the following forensic elements in the UI:

• Configured URL: Direct link to the source document monitored.
• Ingestion method: indication of whether the current record was seeded, directly retrieved, fetched via HTTP/2, rendered through the VPS service, or recovered through an archive source.
• Scan timestamps: both the Last Checked and Last Successful Fetch times are visible for every policy.
• Check logs: each scan result can be recorded with status, source, HTTP status, reason, final URL, hash, text length, and archive snapshot timestamp when an archive source is used.
• Public-evidence gate: policy snapshots and change records must be explicitly marked as public evidence before public APIs, sitemap, digests, reports, share pages, timelines, or benchmark views can expose them.
• Policy Signals Board: the public leaderboard ranks only source coverage, retrieval traceability, public baselines, and publicEvidence-gated movement. It does not certify companies, compliance, safety, internal conduct, or provider trustworthiness.
• Re-baseline protection: the first successful fetch after Seeded ingestion evidence establishes the real baseline only. It replaces seeded history for that policy and does not create a PolicyChange, AI score, or subscriber notification. A record is eligible only when it is still seed-only: Configured status alone is not enough, and existing source-evidence logs or public baselines route the scan into normal comparison instead of destructive re-baseline.
• Public suspension: when the latest fetch/update produces anomalies or insufficient evidence, the source is temporarily suspended and public views expose only the suspension notice, not the underlying analysis.
• Source remediation: official-but-blocked sources are repaired through market-specific URL mapping, official PDF/CDN evidence where available, or traced administrative review. PolicyWatcher does not promote anti-bot challenge pages, placeholders, or stale archive copies into public evidence.
• Administrator alerting: source suspensions can generate an internal operational email with metadata and a Dataset QA link, without including policy text, scores, diffs, KPIs, or AI interpretation.
• Dataset QA control groups: source fit, retrieval evidence, public evidence gates, seeded-record boundaries, hash consistency, check-log completeness, timestamp integrity, archive timestamp coverage, KPI coverage, regional impact coverage, access logs, and subscriber hygiene are inspected before release decisions.
• Review decisions: Dataset QA issues can be marked reviewed, ignored with reason, or reopened, with append-only review-log evidence.
• Version timeline: versioned policy records remain available for reproducible comparison.

Release 3.6.3 introduces a goal-oriented workspace layer without changing evidence rules.

• Adaptive Workspace: users can select a session intent (Citizen, GRC / Legal, Research, Builder) and evidence depth (Snapshot, Operational, Forensic).
• Presentation-only adaptation: density, module priority, dashboard emphasis, and URL parameters may change, but publicEvidence gates, source suspensions, and Dataset QA warnings remain active.
• Public exploration surfaces: Timeline, Policy Signals Board, Site Atlas, Roadmap, Press Wall, Showcase, Trust, and Infographics expose different views of the same evidence boundary.
• Site Atlas: maps public pages, trust surfaces, methodology pages, community pages, and protected admin boundaries as an entity relationship graph.
• Press and Roadmap: public references and community priorities are tracked for transparency; they are not treated as endorsements, certifications, or external validation of company compliance.
• Admin boundary: operational tools such as Cron Manager, Dataset QA, Review Log, Access Log, Company Registry, Database diagnostics, KPI Audit, and VPS Services remain protected by admin/auditor roles.

Users and legal teams must be aware of the following platform boundaries:

• Scraping latency: policies are monitored on a recurring or manual schedule. Updates may lag behind live provider releases.
• Extraction limits: blocked pages, consent walls, provider anti-bot challenges, script-rendered content, renderer outages, or archive gaps can reduce retrieval coverage. The VPS renderer improves coverage for script-rendered pages, but it does not guarantee source availability.
• LLM context limits: large documents may be analysed in reduced or structured contexts, which can miss highly specific clauses.
• Legal interpretation: legal terms can be ambiguous. Risk scores are analytical indicators, not court-validated conclusions or compliance determinations.