URLs, remote contexts and referenced assets all cross 1 destination policy. Only supported HTTP and HTTPS requests are accepted. Credential-bearing URLs are rejected, each resolved address is evaluated, redirects are revalidated, and loopback, private, link-local, metadata and other non-public destinations are blocked. The decision and its address evidence are retained with the recorded retrieval outcome by policy.
Those network controls operate independently from the validation logic. They cover IPv4 and IPv6, alternative address forms, DNS rebinding, proxy behaviour and hostnames that resolve to several addresses. Browser navigation and subresource requests remain inside the same egress boundary.
Rendering takes place in dedicated non-root workers with Chromium sandboxing, read-only filesystems and isolated temporary storage. Each job receives a fresh browser context and narrowly controlled network access. The worker holds no database, cloud metadata or service credential that an untrusted page could retrieve.
Unneeded browser capabilities remain disabled, including downloads, clipboard access, notifications, cameras, microphones, geolocation, USB, serial devices, local files and persistent service workers. Resource limits cover memory, CPU, wall time, redirects, source size, decompression ratio, parser depth, graph size and concurrent work. Together, they contain both malicious input and accidental overload. The relevant limit and termination state become part of the job evidence, allowing operators to distinguish rejection from incomplete processing reliably.
Submitted HTML and JSON are rendered as inert text throughout the interface and its exports. Context-specific encoding, content security policy and dedicated attack tests protect source views, syntax highlighting, tooltips and downloadable output from script execution.
01Privacy and isolation
Transport and storage encryption protect active job material. Isolation prevents one validation job from reaching another job’s source, browser state, private cache content or result. The same separation covers temporary files and cache entries created during raw and rendered processing stages. That isolation boundary remains in force from initial intake throughout processing, result assembly and the controlled expiry or deletion of active job material.
Operational telemetry is limited to stage and queue timings, bundle versions, outcome counts and bounded failure categories. Complete source bodies are never retained within that telemetry. Crash reporting applies the same scrubbing standard and excludes complete rendered pages by default.
Ephemeral storage narrows the period in which submitted content exists. Any persistent result depends on a deliberate user action, and the data-processing notices explain remote fetching, browser execution, expiry, deletion and the handling of URLs that contain sensitive query parameters. Those notices also distinguish system-controlled expiry from user-initiated deletion clearly throughout the complete public validation journey.
02Data handling
Submitted source, raw and rendered HTML, resolved contexts and detailed results stay in encrypted ephemeral storage with controlled expiry. Service logs keep bounded operational facts such as identifiers, sizes, timings, bundle versions and failure categories. They do not store complete submitted source or unbounded literal values. This keeps active content available only for the work that requires it.
The public interface warns against submitting credentials or private data. Credential-bearing URLs are rejected, query strings receive secret-pattern checks, and active anonymous job material can be deleted immediately.
03Conformance and release assurance
A production release must pass the applicable RFC 8259 parser corpus and official W3C JSON-LD 1.1 test suite. W3C SHACL tests cover the constraint components used by consumer profiles. Separate Schema.org ingestion tests verify release-file integrity, hierarchy resolution, term status, domains, ranges and equivalence between HTTP and HTTPS identifiers.
Consumer rules carry passing, failing, boundary and regression fixtures derived from primary documentation. Extraction fixtures cover static, injected, removed, malformed and multiple script blocks in both the raw and rendered document.
Provenance testing follows expanded terms, merged nodes, graph constraints and consumer failures back to exact source locations or to an explicitly reduced level of precision. Security suites exercise SSRF destinations, DNS rebinding, redirects, malicious contexts, browser attacks, decompression limits, parser exhaustion, hostile output payloads and cross-job isolation, then record the expected containment outcome for each attack class.
Accessibility testing covers keyboard operation, screen-reader journeys, focus movement, code-editor behaviour, zoom, reflow and WCAG 2.2 Level AA contrast. Performance and resilience work covers pasted source, raw and rendered retrieval, large graphs, context-heavy inputs, concurrent demand, queue saturation and controlled dependency failure.
Some failures stop release promotion outright: broken source provenance, non-deterministic fixtures, private-network isolation failure, inadequate source scrubbing or incorrect suppression of dependent stages. Rollback can restore the preceding approved rule bundle without rolling back the public interface itself.
04Versioned authorities
Each production result names 1 immutable validation bundle. That record ties together the JSON parser, JSON-LD processor, Schema.org release, consumer profiles, page-policy rules and advisory rules. 1 aggregate identifier makes the complete environment available for reproduction and comparison.
Behind each finding sits a governed rule record containing its authority, source, observation date, scope, normative force and release history. The record also retains the condition tested, severity, message, consequence, correction template and associated fixtures. Once published, a bundle keeps its original meaning; a correction or source change enters a new version with a changelog entry. This controlled history makes a changed conclusion explainable later without silently rewriting an earlier result.
05Current vocabulary and consumer rules
Vocabulary evaluation is pinned to Schema.org release 30.0, published on 19 March 2026. The release model retains type and property hierarchies, domains, ranges, inverse relationships, supersession and term status within the vocabulary index. Both HTTP and HTTPS Schema.org identifiers are recognised.
Google Search requirements remain in dated consumer bundles derived from primary documentation, with required properties kept distinct from recommendations. Documentation changes enter review before altering production behaviour.
06Assured acceptance behaviours
- Duplicate JSON member. A fatal finding identifies both source locations before value loss occurs.
- Invalid JSON-LD context. JSON passes, JSON-LD processing records the normative error and dependent graph checks stop.
- Shared @id across blocks. 1 entity contains merged statements while preserving both source contributions.
- External vocabulary mapping. The expanded external IRI avoids a false Schema.org spelling failure.
- Missing Google required property. The named consumer requirement fails while JSON-LD and Schema.org outcomes remain independent.
- Missing Google recommended property. The consumer profile records a warning without changing required-property status.
- JavaScript-injected JSON-LD. Raw-versus-rendered comparison identifies the added source, graph statements and changed consumer outcome.
- Remote context redirect to a private address. The loader blocks the destination and records a controlled document-loading failure.
- Submitted script payload. The interface displays inert source and prevents payload execution.
- Googlebot crawl restriction. The page layer records the robots restriction without rendering a blocked Google view.
- Identical repeated request. Finding identities, states, authorities and semantic locations remain stable under identical versions.
- Source-linked keyboard journey. Focus moves to the relevant source location and exposes its finding state.
The complete technical assurance document, carrying the full processing contracts and the rule-governance record, is released on request to technical assessors, security reviewers and procurement teams. Request the technical assurance document.