- 01
Public data · read only
The sample manifest passes all ten contract filters for this permissive public-data fixture.
Run example - 02
Confidential · no retention
The sample blocks on privacy and availability because its declarations do not meet this narrower profile.
Run example - 03
Paid structured output
The sample blocks on price/payment, availability, and latency under this paid evidence-focused profile.
Run example
Three profiles. Three different questions.
The same service can be compatible with one declared need and blocked by another. These examples make the requirement profile visible so a pass never masquerades as a universal approval.
Expected outcomes below were verified with the repository evaluator on .
Run each fixture
What the difference teaches
A blocked result does not automatically mean the service is defective. It means at least one declaration falls outside this particular profile. The truthful response may be to change the service, improve evidence, correct an inaccurate manifest, or accept that the profile is not a fit.
A passing result is equally narrow. It is not a trust, safety, ownership, reachability, quality, capability-fit, or authorization decision.
Fixture provenance
The service declaration is copied from the Nexus free-service-chain valid fixture. The three search requests are complete v1 documents stored with this microsite. They are versioned examples designed to exercise real evaluator behavior.
No example represents a real provider, customer, industry norm, or endorsement.