Submission begins with a URL, HTML, JSON-LD or supported file. Classification and safety controls give each source unit a stable identity before processing.
Each independent JSON-LD block receives its own source identity, syntax diagnostics and processing outcome before graph assembly begins. Blocks that process successfully contribute to a normalised dataset, but the original document order and source boundary remain available. 1 malformed block therefore does not erase valid evidence recovered from another. This preserves partial evidence instead of turning a local syntax fault into a page-wide absence.
The result opens on a compact matrix of validation layers, not a global badge. Users can then move through findings, consumer profiles, entities, original source, raw-versus-rendered changes, page evidence and the recorded processing environment. The interface preserves context as technical detail changes.
01Source-linked findings
Findings are written to support action, not merely to expose a rule code. The visible record identifies the evaluation state and severity, names the governing source, shows the affected entity and property, and points back to the input view and source location. It also states what was observed, what the rule expected and why the difference matters.
Correction guidance stays strictly within the submitted evidence. It never fabricates a name, price, date, rating, identifier, currency, availability state, address or author. If the required fact is unknown, the finding identifies the information that a responsible owner must supply.
02Entity and graph navigation
The entity view brings together types, properties, inherited vocabulary, identifiers, relationships and contributing source blocks. When several blocks use the same @id, their statements resolve to one node while provenance remains attached to each contribution across the merged graph within that result. A user can inspect the merged meaning without losing the route back to the original text.
Blank nodes receive stable display labels only within the result and are never presented as global identifiers. Relationships remain navigable links between named entities, preserving the graph structure and source context that an undifferentiated text report would inevitably flatten.
03The business-level summary
The opening result states what was tested and which evidence views were available. It records the standards layers that completed, identifies the consumer profiles that met their published requirements and brings the highest-consequence findings forward for immediate review by the responsible business and technical owners. Unresolved evidence remains visible rather than disappearing behind a celebratory pass state.
A business or product owner can quickly place the problem: malformed source, JSON-LD processing, vocabulary usage, a consumer requirement or the surrounding page. The same result gives technical teams enough evidence to reproduce the finding and make a controlled correction.
04The states a check can return
- Passed. The evaluated source met the named requirement under the recorded bundle versions.
- Failed. The evaluated source violated a named authority requirement or verified product rule.
- Not applicable. The rule does not apply to the detected source, entity or selected profile.
- Not evaluated. A required upstream capability failed, preventing reliable dependent evaluation.
- Unverified. The available input does not contain enough page or network evidence for a conclusion.
- Indeterminate. An external dependency or ambiguous condition prevents a defensible result.
05A specimen finding
Each finding carries the same anatomy, whichever authority raised it. The specimen below is written to show the shape of a result, not to report a real page.
- Authority. Consumer profile, Google Search.
- Primary source. Google Search Gallery, product structured data.
- Affected location. Script block 2, source line 148, entity #product-a41.
- Observed. An entity of type Product with no offers property present in the expanded graph.
- Expected. A required property for the product result type.
- Consequence. The entity is ineligible for the product result. Schema.org conformance is unaffected, and the JSON and JSON-LD layers both pass.
- Correction route. Add the property at the source entity, then revalidate. Factual review is required before any change reaches a live page.
The same finding therefore reads as a failure in 1 layer and a pass in 3. Reporting it as a single verdict would be the error.
06Export and reproduction
The versioned JSON export preserves authorities, locations, entities, evidence states, rule-bundle versions and suppressed stages. Stable finding identities allow repeated validations to be compared without forcing unrelated page evidence into a narrower interchange model.
Reproduction depends on more than the submitted text. The result therefore records its engine, processor, vocabulary, consumer and advisory versions alongside the base IRI and input view. When those inputs and bundle versions are identical, the semantic findings remain identical apart from job-specific metadata.