This annex sets out externally assessable behaviour, processing boundaries and release controls. The disclosure is detailed enough to test the product’s claims, follow the authority behind a result and understand how failures are contained across the full path from initial intake through release governance.
This annex does not disclose the product's implementation recipe. Source code, repository structure, internal package names, private endpoints, database schemas and deployment manifests are excluded, as are complete rule definitions, constraint shapes, security thresholds, test fixtures and proprietary source-mapping logic. Instead, it describes observable contracts, evidence boundaries and release controls in terms that an independent assessor can test against actual results. Those exclusions protect the capability without weakening the assurances stated here.
01The processing sequence
- Intake. URL, pasted source or supported local text file. Classified job, input identity and recorded safety limits.
- Controlled retrieval. Public HTTP or HTTPS destination with revalidated redirects and bounded responses. Raw bytes, relevant headers, final URL, timing and retrieval findings.
- Extraction. Raw HTML, rendered document or direct JSON-LD source. Ordered JSON-LD source units with block identity and source offsets.
- Strict JSON parsing. 1 source unit containing JSON text. Parsed value, duplicate-name evidence, syntax findings and exact pointers.
- JSON-LD processing. Parsed values plus controlled contexts and base IRI. Expanded forms, RDF dataset, normative errors and processing trace.
- Graph normalisation. Merged RDF dataset with retained source provenance. Entity index, relationship map, node views and integrity findings.
- Vocabulary evaluation. Normalised graph plus pinned Schema.org release data. Recognised terms, status, hierarchy, domain and range findings.
- Consumer evaluation. Annotated graph plus selected Google profiles. Required and recommended requirement outcomes by feature.
- Page evaluation. HTTP evidence, raw document, rendered document and referenced assets. Confirmed, contradicted, unverified or indeterminate page findings.
- Result assembly. Findings, entities, sources and version metadata. Layer matrix, navigable result, source links and versioned export.
Processing stages are gated by the evidence they require. A fatal JSON failure stops JSON-LD and graph evaluation for that source unit, while extraction and page checks continue wherever their own evidence remains valid. If a remote context is blocked, the result records a document-loading outcome rather than inventing a Schema.org vocabulary error downstream.
02Strict source handling
RFC 8259 grammar is applied before ordinary object conversion can discard duplicate member names. The parser retains positions for invalid tokens and duplicate names, along with trailing content, malformed numbers, broken string escapes, unterminated structures, comments and encoding problems.
Exact locations include line, column, byte range and JSON Pointer wherever the source supports them. Expansion changes the document’s shape, so the processing trace carries provenance from compact keys and values into expanded IRIs, entities and later findings. If an operation cannot preserve exact precision, the result points to the nearest defensible source unit and states that limitation instead of implying a more exact location.
Deterministic content identity uses a canonical representation only after duplicate-name checks have succeeded. The submitted text remains authoritative for visible locations, excerpts and correction actions.
03JSON-LD processing and graph integrity
JSON-LD processing follows the W3C JSON-LD 1.1 Recommendation and its normative Processing Algorithms and API. The original W3C error names survive unchanged in the visible result and versioned export, without translation or product-specific renaming. They cover failures such as invalid contexts, protected-term redefinition, invalid keyword values or IRIs, malformed value objects, list errors, cyclic mappings, remote document failures and invalid HTML script elements.
Remote document loading always crosses a controlled network boundary. It restricts schemes to HTTP and HTTPS, revalidates redirects, enforces public destinations and applies limits for response size, content type, elapsed time, recursion and context count. Approved local resolution or controlled caching covers known contexts; other contexts use the same protected network path as URL retrieval.
Once processing succeeds, checks look for unresolved local references, conflicting statements attached to shared identifiers, duplicate blank-node structures, cycles and disconnected entities. Statements from several script blocks can form one dataset, while each contribution retains its source boundary for navigation and diagnosis.
Source appearance is not mistaken for graph meaning. Ordinary JSON-LD arrays remain unordered unless @list or another explicit ordered construct applies, so formatting and property-order changes can appear in a text comparison without becoming false semantic differences. This keeps comparison clear of visual noise while preserving explicit order wherever the data model assigns meaning to ordered values.
04Schema.org vocabulary evaluation
The Schema.org layer is built from official release data, not an inferred closed-world schema. It preserves type and property hierarchies, multiple inheritance, domains, ranges, inverse properties, supersession and the published status of core, pending or retired terms.
Evaluation can distinguish a compact spelling error from an unknown Schema.org identifier or a legitimate external-vocabulary term. It also follows inherited domain and range families, enumeration membership and declared data types across the full dataset. External terms still receive normal JSON-LD processing; they are not relabelled as misspelled Schema.org properties merely because they sit outside that vocabulary.
A domain or range mismatch remains a vocabulary warning unless a named consumer profile defines a narrower requirement. Pending terms carry their published status, while retired terms point to replacements only where the official release supplies one.
05Consumer-profile evaluation
Google Search profiles apply the requirements stated in published feature documentation and shared structured-data policies. Automatic detection works from expanded graph types and relationships rather than compact spelling alone. When the graph lacks enough type evidence, manual profile selection gives the user an explicit alternative.
Required properties produce profile-scoped errors; recommendations produce warnings. Neither result rewrites the generic JSON-LD or Schema.org outcome.
Each consumer rule retains its primary source, observation date, feature scope, normative force and release version. A removed feature leaves the current profile, but the historical bundle remains available to reproduce an earlier validation.
06Raw and rendered page analysis
URL mode keeps raw-response evidence apart from the rendered document. The raw extractor reads the decoded HTTP response without executing page scripts. A separate extractor opens the URL in a fresh, isolated browser context and examines the resulting document after bounded loading. The 2 evidence streams remain separate throughout later comparison and finding assembly for external audit.
Comparison works at 3 levels: source text, expanded JSON-LD and the RDF graph. It identifies added or removed script blocks, changed entities, statements and values, and any resulting change to a consumer outcome. Formatting and property order remain outside semantic comparison.
Page checks record the HTTP status and redirect path, final URL, robots directives, noindex, canonical references, markup presence in each view, referenced assets and visible facts that can be compared directly. The finding state distinguishes confirmed or contradicted evidence from an unverified condition or a question requiring human review, without assigning a stronger conclusion than the evidence supports.
07Result provenance and correction safety
A stable rule identifier locates a finding within the validation system, but it never replaces the visible external authority. The finding also records its input view, source unit and location precision, together with the affected entity or property, observed evidence, expected condition, consequence, correction guidance and exact bundle version.
Related findings are grouped only after their source, rule intent and correction action have been compared. If an upstream failure makes a dependent evaluation unreliable, those downstream findings are suppressed rather than repeated as a cascade of consumer errors.
Correction templates use established facts from the supplied evidence. When a value remains unknown, the correction names the missing information without manufacturing deployable content.
08Rule governance and reproducibility
Published rule bundles remain immutable, signed and content-addressed after release. Component versions can advance independently, while the aggregate identifier records the complete validation environment used for a result. That identifier stays attached to the exported findings and their source evidence across repeated validations.
Source monitoring covers Schema.org releases and term status, Google documentation and feature pages, W3C errata, processor releases and relevant security advisories. A detected change opens a governed maintenance record rather than altering production behaviour. That record captures the observation date, extracted requirement, interpretation, reviewer, fixtures and eventual release decision, with evidence retained through the whole decision.
Ambiguity is recorded and governed as a real state. A source change that does not support a defensible interpretation leaves the current rule untouched or marks the matter as unresolved until reviewed evidence settles it.
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.