JSON Schema fixtures

JSON Schema (User)

A draft-07 JSON Schema describing a user object — for testing schema validators and schema-aware tooling.

File: JSON · JSON · UTF-8
Use case: Schema validationJSON parsing

Product JSON Schema (draft-07)

A JSON Schema (draft-07) describing a product object, with required fields, types, and constraints — paired with a conforming and a deliberately non-conforming instance for testing validators.

File: JSON · Schema
Use case: Schema validationData import· Conversion set

Product Instance — Valid (JSON)

A product object that conforms to the product JSON Schema — the positive case for testing a JSON-Schema validator.

File: JSON · Schema
Use case: Schema validation· Paired fixture

Product Instance — Invalid (JSON)

A product object that deliberately violates the product JSON Schema in five ways (out-of-range id, empty name, non-positive price, wrong boolean type, an extra property) — the negative case for testing validator error reporting.

File: JSON · Schema
Use case: Schema validationError handling· Paired fixture

ISO 20022 Credit Transfer — pain.001 (XML)

A sample ISO 20022 customer credit-transfer initiation (pain.001.001.09) — a single payment with debtor/creditor parties, IBANs, BICs, amount, and remittance info. IBANs are published documentation examples; a fixture for testing payment-message parsers and bank integrations.

File: XML · Banking
Use case: Data importConversion testing+1

JSON Schema Edge — Additional Properties False

Minimal JSON Schema SAMPLE focusing on additional properties false constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — One Of Status

Minimal JSON Schema SAMPLE focusing on one of status constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Enum Currency

Minimal JSON Schema SAMPLE focusing on enum currency constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Pattern Sku

Minimal JSON Schema SAMPLE focusing on pattern sku constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Nullable Optional

Minimal JSON Schema SAMPLE focusing on nullable optional constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Array Unique Items

Minimal JSON Schema SAMPLE focusing on array unique items constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Dependent Required

Minimal JSON Schema SAMPLE focusing on dependent required constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Edge — Format Uri Email

Minimal JSON Schema SAMPLE focusing on format uri email constraints.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+1· Conversion set

JSON Schema Schema Evolution - Baseline

The baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

JSON Schema Schema Evolution - Backward-Compatible

The compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

JSON Schema Schema Evolution - Breaking

The breaking member of a JSON Schema 2020-12 customer contract. Breaking relative to baseline: id changes from string to integer and tenantId becomes required.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

OpenAPI Schema Evolution - Baseline

The baseline member of a complete OpenAPI 3.1 ticket endpoint contract. Reference API: string ticket IDs and required id/summary response properties.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

OpenAPI Schema Evolution - Backward-Compatible

The compatible member of a complete OpenAPI 3.1 ticket endpoint contract. Backward compatible: an optional priority response property is added and existing operations stay unchanged.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

OpenAPI Schema Evolution - Breaking

The breaking member of a complete OpenAPI 3.1 ticket endpoint contract. Breaking relative to baseline: ticket id becomes integer and status becomes a required response property.

File: JSON · Schema
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Protocol Buffers Schema Evolution - Baseline

The baseline proto3 Customer message for field-number and wire-compatibility testing. Reference wire contract: field 1 is string id and field 2 is string name.

File: PROTO · Schema · 3 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Protocol Buffers Schema Evolution - Backward-Compatible

The compatible proto3 Customer message for field-number and wire-compatibility testing. Backward compatible: existing field numbers/types are retained and optional email uses new field number 3.

File: PROTO · Schema · 4 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Protocol Buffers Schema Evolution - Breaking

The breaking proto3 Customer message for field-number and wire-compatibility testing. Breaking relative to baseline: field number 2 is reused with a different name and wire type.

File: PROTO · Schema · 3 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Avro Schema Evolution - Baseline

The baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.

File: JSON · Schema · 2 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Avro Schema Evolution - Backward-Compatible

The compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.

File: JSON · Schema · 3 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Avro Schema Evolution - Breaking

The breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.

File: JSON · Schema · 3 fields
Use case: Schema / OpenAPI testingSchema validation+2· Conversion set

Convert v2 Archive Member Manifest

JSON ground-truth manifest for the canonical compressed-TAR twins, publishing each safe path, byte count, and full SHA-256 digest. Stable P8 artifact p8-convert-archive-member-manifest.

File: JSON · P8 Convert · 2 members
Use case: Conversion testingSchema validation· Conversion set

webmanifest

1.1 KB

Web app manifest with icon edge cases

A web app manifest whose icon array is built entirely from the awkward cases: a duplicate declaration, an entry with no sizes, sizes="any" on an SVG, a multi-size ICO, a .webp declared as image/png, a cross-origin icon and a 0x0 entry. For testing icon selection and validation logic.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest with maskable and monochrome purposes

A manifest exercising every icon `purpose` keyword: any, maskable, the space-separated combination, monochrome for a notification badge, and the obsolete `badge` value. For testing purpose parsing and adaptive-icon safe-zone handling.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest - minimal installable set

The smallest manifest that still satisfies a browser's install criteria: name, start_url, a standalone display mode and two PNG icons, with every optional member left out. For testing installability checks against the floor rather than a fully populated document.

File: WEBMANIFEST · Pwa · 4 members
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest with no icons (deliberately invalid)

A deliberately invalid manifest: well-formed JSON with an empty icons array, so it parses cleanly and then fails installability. For testing that a PWA validator distinguishes a parse error from an unmet install requirement.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest with a share_target

A manifest declaring a Web Share Target that accepts a POST of multipart form data, including two file parameters with MIME-type and extension accept lists. For testing share-target registration and the parameter renaming a share handler must perform.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest with file, protocol and launch handlers

A manifest registering the desktop-integration members: two file handlers with MIME and extension accept maps, a custom web+ protocol handler alongside mailto, a launch_handler client mode list, an Edge side-panel width and handle_links. For testing OS integration and manifest members a validator may not know.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest with form-factor screenshots

A manifest with the members that turn a bare install prompt into a rich one: four screenshots split across wide, narrow and unspecified form factors, labels, categories and two shortcuts (one with its own icon). For testing rich-install eligibility rules.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

Web app manifest whose start_url is outside its scope (deliberately invalid)

A deliberately invalid manifest: start_url sits at /dashboard/ while scope is /app/, and a shortcut points at another origin entirely. Both are the kind of mistake that makes an installed app open in a browser tab. For testing scope-containment validation.

File: WEBMANIFEST · Pwa
Use case: Web assetsJSON parsing+1· Conversion set

oauth-authorization-server metadata (RFC 8414)

A fully populated RFC 8414 authorization-server metadata document for a fictional issuer: seven endpoints including PAR, introspection and dynamic registration, PKCE and DPoP algorithm lists, and policy URIs. Distinct from the minimal OpenID configuration already in this category.

File: JSON · Well Known
Use case: Web assetsJSON parsing+1· Conversion set

JSON-LD Product with Offer and AggregateRating

A valid Product record with a nested Offer carrying price, currency, availability, condition and shipping details, plus an AggregateRating. For testing rich-result validators and structured-data extractors against a document that should pass cleanly.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD NewsArticle with author and publisher

A valid NewsArticle with two authors, a publisher whose logo carries explicit pixel dimensions, three images at the aspect ratios news results expect, and both publication and modification timestamps. For testing article extraction and date normalisation.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD Event with offers and a location

A valid Event record for a hybrid event: both a physical Place with a postal address and geo coordinates and a VirtualLocation, plus a free Offer and a capacity. For testing array-valued properties and event date/timezone handling.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD Recipe with steps and nutrition

A valid Recipe with ISO 8601 durations, four ingredients, and instructions that mix flat HowToStep nodes with a nested HowToSection. For testing duration parsing and recursive instruction extraction.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD LocalBusiness with opening hours

A valid LocalBusiness (as a SportingGoodsStore subtype) with a postal address, geo coordinates, weekday and Saturday opening hours, and a 00:00-00:00 specification marking a holiday closure. For testing opening-hours parsing and the closed-all-day convention.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD @graph with @id cross-references

A single @graph holding four nodes wired together by @id rather than by nesting - the shape most CMS plugins emit - including a SearchAction, a breadcrumb whose last item has no URL, and one reference to a product node that lives on another page. For testing graph flattening and reference resolution.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD missing required properties (deliberately invalid)

A deliberately invalid Product record: no name, an Offer with a currency but no price, a brand with no @type, a Review with no rating, an AggregateRating with no ratingValue, and an availability given as a bare token instead of a schema.org URL. Valid JSON throughout, so the failure is semantic.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

JSON-LD with wrong value types and a relative context (deliberately invalid)

A deliberately invalid Recipe carrying six unambiguously wrong-typed values - a numeric datePublished, a prose prepTime where an ISO 8601 duration belongs, an object recipeYield, two non-numeric ratings and a misspelled @type - plus a relative @context that never resolves, an untyped image object and two ingredients crammed into one string. For testing the limits of type coercion.

File: JSON · Social · UTF-8
Use case: Web assetsJSON parsing+2· Conversion set

Coverage — LCOV Tracefile with BRDA Branch Records

The reference LCOV tracefile: one record per source file with FN/FNDA function records, real BRDA branch records (block, branch and taken count, with '-' for a branch never reached) and DA line hits, closed by the LF/LH, FNF/FNH and BRF/BRH counters. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura XML

The Cobertura serialisation of the same run, with packages, classes, per-method line rates and condition-coverage attributes on every branching line. Cobertura expresses coverage as rates rather than counts, so this is the file that catches converters rounding a percentage into a hit count. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo XML

The JaCoCo serialisation, which reports missed/covered pairs rather than found/hit and adds INSTRUCTION and COMPLEXITY counters no other format carries. Converters routinely swap missed for covered here, which inverts the whole report. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Clover XML

The Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Istanbul JSON Summary

The compact json-summary reporter output: a total block plus one block per file, each with lines, statements, functions and branches as total/covered/skipped/pct. This is what coverage badges and pull-request comments are generated from. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: JSON · Coverage
Use case: JSON parsingConversion testing+1· Conversion set

Coverage — Markdown Pull-Request Summary

The Markdown comment a coverage bot posts on a pull request: a headline percentage, a per-file table and the uncovered line numbers. Useful for testing Markdown table rendering and for checking that a bot's generated comment matches the machine-readable report it claims to summarise. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: MD · Coverage
Use case: Conversion testingEditor testing+1· Conversion set

Coverage — LCOV Without Branch Records

The same tracefile with every BRDA, BRF and BRH line removed — what a runner emits when branch instrumentation is off. A gate that reads branch coverage from this file must report it as unavailable, not as 0%, or an unconfigured project looks like a badly tested one.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Function Records Only

Records containing FN/FNDA/FNF/FNH and nothing else: no DA lines, no LF or LH. Merge tools that assume every record ends with LF/LH either crash here or invent a zero line count for a file that simply was not line-instrumented.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Two Test Runs Over the Same Files

Two TN: blocks — a unit run and an integration run — each carrying a full record for the same two source files. A correct merge sums the DA hit counts per line and recomputes LH; a tool that keeps the last record seen throws away the unit run entirely.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV at Zero Coverage

Every instrumented line present with a hit count of zero — the shape of a report from a run in which the tests never loaded the instrumented code. It is not an empty file, and conflating the two hides a broken test harness behind a missing-report warning.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV at 100%

Every line hit at least once, so LH equals LF exactly. The upper-bound control for a coverage gate, and the case that catches percentage formatting that renders 100% as 100.0% or, worse, rounds 99.95% up to it.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Several TN: Test Names

Three named test runs in one tracefile, each covering a different part of the tree, reported via the TN: record most tools quietly discard. Keeping the name is what lets a report answer which suite covered a given line.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura Condition-Coverage Attributes

Cobertura with a condition-coverage attribute on every branching line, written in the "50% (1/2)" form. The percentage and the fraction can disagree in real reports, so a parser should read the fraction and treat the percentage as derived.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura with One Package per Directory

The same coverage split into one package per source directory with dotted names, the layout a JVM project produces. Reports that key on class name alone collide as soon as two packages hold a class of the same name, which this file is shaped to expose.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura at Zero Coverage

A structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura with Several Source Roots

Three <source> roots with class filenames given relative to them, which is how Cobertura represents a multi-root project. A viewer must try each root in turn to resolve a file; one that assumes a single root shows "source not found" for most of the report.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo with Every Counter Type

All six JaCoCo counter types present at every level of the document — method, class, sourcefile, package and report. Tools usually read only the report-level LINE counter; this file is for checking that per-method and per-package rollups agree with it.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo with Several Session Records

A report merged from three separate JVM sessions, each recorded as its own <sessioninfo> with start and dump timestamps. The counters are already the merged totals, so summing per-session anything from this file is a mistake it exists to catch.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo Multi-Module <group>

The aggregate form a multi-module build produces: packages nested inside a <group> rather than directly under <report>. Parsers with a hardcoded report/package path find nothing here and report a module with no coverage at all.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo Method-Level Counters

Per-method INSTRUCTION, LINE, COMPLEXITY and METHOD counters for all 20 methods, 2 of which were never entered. This is the detail a "which functions are untested" report needs and the level at which most converters stop.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Gate Configuration (JSON)

The threshold configuration the three boundary tracefiles in this group are meant to be judged against: global minimums, one per-path override and an explicit >= comparison. Publishing the comparison operator is the point — leaving it implicit is what makes an at-the-gate report ambiguous.

File: JSON · Coverage
Use case: Config parsingJSON parsing+1· Conversion set

Cucumber Messages — Passing Checkout Run (NDJSON)

The machine twin of checkout.feature: the cucumber-messages envelope stream a runner emits, with meta, source, gherkinDocument, one pickle per expanded scenario, and paired testStepStarted/testStepFinished envelopes carrying nanosecond durations. Written as NDJSON because that is the format's actual wire shape — one envelope per line, not a JSON array.

File: NDJSON · Bdd · UTF-8
Use case: JSON parsingConversion testing+1· Conversion set

Cucumber JSON — Passing Checkout Report

The legacy cucumber.json report for the same run — the format nearly every BDD dashboard still ingests. Durations are in nanoseconds here and in a nested {seconds, nanos} object in the messages twin, which is the single most common unit bug when converting between the two.

File: JSON · Bdd · UTF-8
Use case: JSON parsingConversion testing+1· Conversion set

Requirements Traceability Matrix with One Gap (CSV)

Thirteen requirements mapped to the test cases that cover them — and one, REQ-PAY-02, deliberately covered by nothing. A coverage-gap report that does not surface that row is not working, which makes this the answer key for exactly that check.

File: CSV · Plans · 13 rows
Use case: CSV parsingData import+1· Conversion set

LCOV — Lines Hit Exceeds Lines Found (intentionally corrupt)

An intentionally corrupt LCOV tracefile: every record declares LH eight greater than LF, so more lines were hit than exist. The syntax is perfectly valid, which is the point — the contradiction is semantic, and a coverage gate that trusts the summary counters computes over 100% coverage and passes a build it should have stopped. Recompute LH from the DA lines and the real figure is 127/140.

File: LCOV · Corrupt · 4 records
Use case: Error handlingConversion testing+1· Conversion set

OTLP/JSON Trace — 13-Span Checkout Request (json)

A complete OTLP/JSON trace export: one checkout request across five services as 13 spans, four levels deep, with HTTP, database, RPC and messaging semantic-convention attributes, span events and a producer span. Trace and span IDs are fixed, so ingesting it twice produces identical output.

File: JSON · Traces
Use case: ObservabilityJSON parsing+1· Paired fixture

OTLP Trace — Duplicate Span IDs, Intentionally Invalid (json)

Two different spans share one span ID inside a single trace, which the specification forbids. Intentionally invalid: it is the fixture for the de-duplication path, where a naive store silently overwrites one span with the other and loses a subtree.

File: JSON · Traces
Use case: ObservabilityError handling+1· Conversion set

OTLP Trace — All-Zero Trace and Span IDs, Intentionally Invalid (json)

A trace whose trace ID and root span ID are all zeroes — the value an uninitialised context produces. Intentionally invalid: the specification defines all-zero IDs as invalid, so a conformant receiver must reject the spans instead of creating a permanent bucket that every broken service writes into.

File: JSON · Traces
Use case: ObservabilitySchema validation+1· Conversion set

OTLP Trace — Negative and Zero Durations, Intentionally Invalid (json)

One span ends 8.4 ms before it started and another has identical start and end timestamps. Intentionally invalid: negative durations poison latency aggregates — a single one can drag a p99 below zero — so this is the fixture for the validation that must sit in front of any duration metric.

File: JSON · Traces
Use case: ObservabilitySchema validation+1· Conversion set

OTLP Trace — Empty but Valid Batch (json)

A structurally valid OTLP export containing no spans at all — what an exporter sends when every span in the interval was sampled out. The empty-input case that ingestion code routinely mistakes for an error.

File: JSON · Traces
Use case: ObservabilitySchema validation+1

W3C traceparent — Valid and Invalid Header Cases (txt)

A labelled set of traceparent header values: four that must parse — including a future version with extra fields, which parsers are required to accept — and eight that must be rejected, covering all-zero IDs, version ff, short and uppercase trace IDs, and missing or trailing fields.

File: TXT · Traces
Use case: ObservabilitySchema validation+1· Conversion set

W3C tracestate — List Members, Limits and Rejects (txt)

tracestate header values covering vendor-prefixed keys, optional whitespace, the exact 32-member limit and a 33-member case that must lose its last member rather than its first — plus duplicate keys, uppercase keys, a bare key and an over-long key that must be rejected.

File: TXT · Traces
Use case: ObservabilitySchema validation+1· Conversion set

B3 Propagation — Single and Multi-Header Forms (txt)

B3 context propagation in both shapes — the compact single b3 header including the debug flag, a legacy 64-bit trace ID and the sampling-only form, plus the five X-B3-* multi-header fields — with two malformed values that must be rejected.

File: TXT · Traces
Use case: ObservabilitySchema validation+1· Conversion set

Prometheus Exposition — Duplicate Series, Intentionally Invalid (prom)

One label set exposed twice, a second pair that is only a duplicate once labels are sorted, and a repeated HELP line. Intentionally invalid: a scrape must fail rather than let last-write-wins decide which of two values for the same series survives.

File: PROM · Metrics
Use case: ObservabilitySchema validation+1· Conversion set

Prometheus Exposition — Broken Histograms, Intentionally Invalid (prom)

Two histogram families that are syntactically fine and semantically wrong: one has non-monotonic buckets and no +Inf bucket, the other reports a _count larger than its +Inf bucket. Intentionally invalid, because histogram_quantile over either produces a confidently wrong number rather than an error.

File: PROM · Metrics
Use case: ObservabilitySchema validation+1· Conversion set

OpenMetrics — Full Document with UNIT, info and stateset (prom)

A complete OpenMetrics document — the _total and _created series a counter really has, UNIT metadata, an info metric carrying build metadata and a stateset with exactly one active state — terminated by the mandatory # EOF. This is what the exposition format became once it was standardised.

File: PROM · Metrics
Use case: ObservabilityTime-series data+1· Conversion set

OpenMetrics — Missing # EOF Marker, Intentionally Invalid (prom)

A document that parses perfectly as Prometheus text and is invalid as OpenMetrics, because the mandatory # EOF terminator is missing. That marker is the format's only defence against a truncated response being accepted as complete — which is the exact failure this file reproduces.

File: PROM · Metrics
Use case: ObservabilitySchema validation+1· Conversion set

Structured Log — Schema and Type Drift Across Records (jsonl)

Six records that all mean the same thing and disagree about how to say it: status as a number, a string, a float and the text OK; user as a string, an object and null; tags as an array and a scalar; and the level and message fields renamed. The mapping conflict that stops an index mid-ingest.

File: JSONL · Logs
Use case: ObservabilityLog parsing+1· Conversion set

Prometheus Alerting Rules — Intentionally Invalid, Five Distinct Faults (yaml)

A rule file that is perfectly valid YAML and completely invalid as Prometheus rules: a rule that is both an alert and a recording rule, a PromQL syntax error, a duplicated group name, a rule with no expr and a duration written in prose. Intentionally invalid, with each fault labelled in place.

File: YAML · Alerts
Use case: ObservabilitySchema validation+1· Conversion set

Service Level Objectives — Two SLOs in One Multi-Document YAML (yaml)

Two SLOs — availability and latency — in one multi-document YAML separated by ---, each defined as a ratio of good events to total over a rolling 28-day window. The latency SLO measures the le="1" bucket against the count, which is the correct way to do it from a histogram.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

CycloneDX 1.6 Application SBOM (JSON)

A complete CycloneDX 1.6 SBOM in JSON for a fictional application and its nine dependencies, with purls, SHA-256 hashes, supplier records, external references and an explicit dependency graph. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingConversion testing+2· Paired fixture

CycloneDX 1.6 Application SBOM (XML)

The same fictional CycloneDX 1.6 SBOM serialised as XML against the cyclonedx.org/schema/bom/1.6 namespace — the JSON twin of this file carries identical components and edges, so a converter can be diffed exactly. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: XML · Sbom
Use case: Conversion testingSchema validation+1· Paired fixture

CycloneDX 1.5 Application SBOM (JSON)

A CycloneDX 1.5 SBOM of the same fictional tree, useful for spec-version migration tests: 1.5 introduced the object form of metadata.tools and this file uses it, while dropping the 1.6-only external references. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingConversion testing+1· Conversion set

CycloneDX 1.4 Application SBOM (XML)

A CycloneDX 1.4 XML SBOM of the same fictional tree — the version most long-lived tooling emitted first, kept for backwards-compatibility tests against the 1.5 and 1.6 documents in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: XML · Sbom
Use case: Conversion testingSchema validation· Conversion set

CycloneDX 1.6 Minimal SBOM (One Component)

The smallest CycloneDX document that is still valid: required metadata, one fictional component, and no dependencies array — for testing that a reader handles an SBOM with nothing optional present. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingSchema validation+1· Conversion set

CycloneDX SBOM With Embedded SAMPLE Vulnerabilities

A CycloneDX 1.6 SBOM that carries its own vulnerabilities array — four clearly-marked SAMPLE advisories in the invented NOVUS-SAMPLE namespace, with CVSS v3.1 vectors, CWE classes and affected version ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingSchema validation+1· Conversion set

CycloneDX SBOM With SPDX Licence Expressions

A CycloneDX SBOM that uses compound SPDX licence expressions — AND, OR, WITH and a LicenseRef — instead of plain licence ids, for testing compliance scanners that must evaluate the expression grammar. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingSchema validation+1· Conversion set

CycloneDX SBOM With Services and Compositions

A CycloneDX SBOM that declares external services and composition completeness alongside components — the sections tools most often skip. Both services are fictional endpoints on the .example domain. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingSchema validation+1· Conversion set

CycloneDX SBOM With Schema Violations — Intentionally Invalid

An intentionally invalid CycloneDX SBOM: the JSON parses, but bomFormat is missing, one component has no name, and a dependency references a bom-ref that no component declares. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: Schema validationError handling+1· Conversion set

SPDX 2.3 Application SBOM (JSON)

An SPDX 2.3 SBOM in JSON describing the same fictional tree as the CycloneDX documents in this category, with SPDXIDs, purl external references, SHA-256 checksums and DESCRIBES/DEPENDS_ON relationships. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingConversion testing+2· Paired fixture

SPDX 2.3 Minimal SBOM (Tag-Value)

An SPDX 2.3 tag-value document with only the mandatory document header and a single fictional package — no relationships, no files — for testing that a parser accepts a document with every optional block absent. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingSchema validation+1· Conversion set

SPDX 2.3 SBOM With LicenseRef and Compound Expressions

An SPDX tag-value SBOM that declares a non-standard LicenseRef with its extracted text and uses it inside compound expressions — the case that breaks compliance tools which assume every licence is an SPDX id. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingSchema validation+1· Conversion set

SPDX 2.3 SBOM With Snippet Ranges

An SPDX 2.3 JSON SBOM that uses the snippet section to attribute a fictional vendored fragment inside a file to a different licence, with both byte-offset and line-number ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingSchema validation+1· Conversion set

SPDX 2.2 Legacy SBOM (Tag-Value)

The same fictional tree as an SPDX 2.2 tag-value document — the version still produced by older toolchains — for upgrade and compatibility tests against the 2.3 twin in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingConversion testing+1· Conversion set

SPDX 3.0 Application SBOM (JSON-LD)

An SPDX 3.0 SBOM in JSON-LD — the element-graph model that replaced the 2.x document layout — describing the same fictional tree with software_Package elements and typed Relationship nodes. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Sbom
Use case: JSON parsingConversion testing+2· Conversion set

SPDX 2.3 Application SBOM (YAML)

The SPDX 2.3 SBOM in its YAML serialisation — the third form the specification defines alongside JSON and tag-value, and the one most often hand-edited in a repository. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Sbom
Use case: Conversion testingConfig parsing+1· Conversion set

npm package-lock.json (lockfileVersion 3)

An npm lockfile in the modern v3 layout: a flat packages map keyed by node_modules path, with resolved tarball URLs and sha512 subresource integrity for nine fictional dependencies. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Lockfiles
Use case: JSON parsingConversion testing+1· Conversion set

npm Lockfile With Integrity Mismatch — Intentionally Invalid

An intentionally invalid npm lockfile: two fictional packages carry sha512 integrity strings that cannot match their resolved tarballs — one derived from the wrong version, one a padded placeholder. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Lockfiles
Use case: Error handlingJSON parsing+1· Conversion set

pnpm-lock.yaml (lockfileVersion 9)

A pnpm v9 lockfile with its three-section layout — importers for declared specifiers, packages for resolution metadata and snapshots for the resolved edges — pinning the same fictional tree. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

pip requirements.txt With Pinned Hashes

A hash-pinned pip requirements file with two sha256 hashes per fictional package (wheel and sdist) and line continuations — the form `--require-hashes` installs demand. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

poetry.lock (TOML)

A Poetry lockfile: TOML array-of-tables entries with per-artifact sha256 hashes, a [package.dependencies] table per package and the content-hash that binds the lock to pyproject.toml. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

Cargo.lock (version 4)

A Rust Cargo.lock in the version 4 format — TOML [[package]] tables with a registry source, a sha256-shaped checksum and a name-only dependencies array that resolves against the other tables. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

Trivy Filesystem Scan Report (JSON)

A Trivy-shaped filesystem scan report with four SAMPLE findings against a fictional npm lockfile, one per severity band, each with a CVSS v3.1 vector, CWE class and fixed version. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

Trivy Container Image Scan Report (JSON)

A Trivy-shaped image report with three result blocks — OS packages, language packages and a Dockerfile misconfiguration — so a parser must handle a Results array whose members have different keys. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

Trivy Clean Scan Report (Zero Findings)

A clean scan report — the case dashboards get wrong. Trivy omits the Vulnerabilities key entirely rather than emitting an empty array, so a reader that assumes the key exists throws on a passing build. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingError handling+1· Conversion set

Scanner SARIF 2.1.0 Report

The same four SAMPLE findings expressed as SARIF 2.1.0 — the format code-scanning dashboards ingest — with a rules array, security-severity properties and physical locations. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

Grype Scan Report (JSON)

A Grype-shaped report of the same four SAMPLE advisories, with the match detail block that explains WHY each package matched — the field that makes false positives diagnosable. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

OSV Vulnerability Record (JSON)

A single OSV-schema advisory record for a fictional package, with a SEMVER range expressed as introduced/fixed events rather than as a version string — the part naive parsers get wrong. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

OSV-Scanner Report (JSON)

An OSV-Scanner report that nests full OSV records under each affected package and adds the groups array that collapses aliases into one finding — the structure de-duplication depends on. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

OSV Record With Schema Violations — Intentionally Invalid

An intentionally invalid OSV record: the JSON parses, but the required id is missing, modified is not an RFC 3339 timestamp, the SEMVER range has a fixed event with no introduced event, and severity.score is a number where the schema demands a CVSS vector string. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: Schema validationError handling+1· Conversion set

npm audit Report (auditReportVersion 2)

An npm audit v2 report keyed by package name, with the via chain, the effects list showing which fictional parents are impacted, and npm's own severity vocabulary where MEDIUM is spelled 'moderate'. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

cargo-audit Report (JSON)

A cargo-audit report that shows three findings while a fourth is on the ignore list, plus an unmaintained-crate warning — so a gate must decide whether warnings count against it. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingConversion testing+1· Conversion set

OWASP Dependency-Check Report (JSON)

A Dependency-Check-shaped JSON report, including the evidence-collection block that records how a package was identified and the confidence attached to that identification. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Paired fixture

OWASP Dependency-Check Report (XML)

The XML twin of the Dependency-Check report — the form most Maven and Jenkins integrations consume — carrying the same four SAMPLE findings inside a namespaced analysis element. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: XML · Vulnerability
Use case: Conversion testingSchema validation+1· Paired fixture

CycloneDX VEX Document

A CycloneDX VEX document asserting a different analysis state for each of the four SAMPLE advisories, so a suppression pipeline can be tested against every branch at once. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

OpenVEX Statement Document

An OpenVEX document covering all four status values, with the justification and impact statement OpenVEX requires alongside not_affected and the action statement it requires alongside affected. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

CSAF 2.0 VEX Document

A CSAF 2.0 VEX advisory with the nested product tree that CSAF requires — vendor, product name, product version — and product_status buckets rather than a per-statement status field. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: JSON · Vulnerability
Use case: JSON parsingSchema validation+1· Conversion set

Vulnerability Suppression Policy (YAML)

A suppression policy that gives every waiver an owner, a reason and an expiry date — the fields that stop a suppression file becoming a permanent blindfold. All four entries are SAMPLE. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: YAML · Vulnerability
Use case: Config parsingConfig testing+1· Conversion set

in-toto Statement With SLSA Provenance v1

An unsigned in-toto Statement carrying a SLSA v1 provenance predicate for a fictional release: build definition, external parameters, resolved dependencies with digests, and run details naming an invented builder. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

in-toto Statement With SLSA Provenance v0.2

The predecessor predicate: SLSA v0.2 uses invocation/materials/buildConfig where v1 uses buildDefinition/runDetails, so this file is the migration test for any verifier that must accept both. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingConversion testing+1· Conversion set

DSSE Envelope Wrapping a Provenance Statement

A DSSE envelope whose base64 payload decodes to the SLSA v1 statement in this family — the wrapper attestation tooling actually transports. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingJWT / JWKS testing+1· Conversion set

SLSA Verification Summary Attestation (VSA)

A VSA — the attestation a verifier issues so downstream consumers do not have to re-verify the whole chain — recording a PASSED result against a fictional SLSA L3 policy and the level distribution of dependencies. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

in-toto Link Metadata

An in-toto link file recording one build step: the materials that went in, the products that came out and their sha256 digests, wrapped in the signed/signatures envelope in-toto uses. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

in-toto Layout (Supply-Chain Policy)

The policy half of in-toto: a layout declaring which steps must run, which keys may sign them, and the MATCH/CREATE/DISALLOW artifact rules that bind each step's products to the next step's materials. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingConfig testing+1· Conversion set

Sigstore Bundle (v0.3 Shape)

A Sigstore bundle in the shape verifiers read: a SAMPLE certificate, a transparency-log entry with an inclusion proof and checkpoint, and the DSSE envelope carrying the provenance. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingCertificate & key testing+1· Conversion set

Rekor Transparency-Log Entry

A transparency-log entry keyed by its own UUID at the top level — a shape that breaks parsers expecting a fixed root key — with a base64 body that decodes to a dsse record. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

SBOM Attestation Envelope (cosign Shape)

An attestation that binds an SBOM to an artifact digest rather than shipping the SBOM loose — the pattern keyless signing produces, complete with the empty keyid that identity-based signing leaves behind. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

Attestation With a Full SPDX Predicate

An in-toto statement whose predicate is an entire SPDX 2.3 document — the nesting that makes attestation payloads large and that a size-limited verifier has to cope with. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingSchema validation+1· Conversion set

Reproducible Build Comparison Report

Two independent builds of the same fictional artifact on different architectures, both producing one digest — the evidence a rebuilder publishes, with SOURCE_DATE_EPOCH recorded as the thing that made it possible. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingVisual diff / regression+1· Conversion set

Attestation Verification Policy (YAML)

The policy an admission controller evaluates before an artifact is allowed through: required predicate types, an allowed-builder list, a minimum SLSA level, a transparency-log requirement and one dated exception. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Provenance
Use case: Config parsingConfig testing+1· Conversion set

Build Metadata Manifest (JSON)

The plain build record a CI job writes next to its artifacts — source ref and commit, builder identity, timings, toolchain versions and output digests — from which a provenance statement can be generated. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Provenance
Use case: JSON parsingMetadata testing+1· Conversion set

GeoJSON — Deeply Nested and Mixed-Type Properties

One feature whose properties mix every JSON type and nest three levels deep. Formats with a flat attribute table — shapefile DBF, most SQL layers — cannot represent this, so the fixture shows whether a converter flattens, JSON-encodes, or discards the nested values.

File: GEOJSON · Geojson · UTF-8
Use case: GeospatialJSON parsing+1· Conversion set

GeoJSON — Intentionally Invalid: Ring With Only Three Positions

Intentionally invalid: a ring of three positions that closes back on itself and therefore encloses nothing. RFC 7946 requires at least four positions for a linear ring, and this is the shape a simplification pass produces when it over-thins a small polygon.

File: GEOJSON · Geojson Edge Cases · UTF-8
Use case: GeospatialError handling+1· Conversion set

GeoJSON — Intentionally Invalid: Longitude Outside -180 to 180

Intentionally invalid: a point at longitude 200. It is a plausible-looking number that usually comes from adding an offset without wrapping, and it survives JSON schema checks that only test for `number`.

File: GEOJSON · Geojson Edge Cases · UTF-8
Use case: GeospatialError handling+1· Conversion set

GeoJSON — Intentionally Invalid: Latitude Outside -90 to 90

Intentionally invalid: latitude 95, five degrees past the north pole. This is the value that appears when longitude and latitude have been swapped somewhere upstream, so catching it early usually finds an axis-order bug rather than a data-entry one.

File: GEOJSON · Geojson Edge Cases · UTF-8
Use case: GeospatialError handling+1· Conversion set

GeoJSON — Intentionally Invalid: Coordinates as JSON Strings

Intentionally invalid: the file is perfectly good JSON but the coordinates are quoted strings, which RFC 7946 does not allow. It is exactly what a CSV-to-GeoJSON script produces when it forgets to cast, and a permissive reader will coerce it and hide the bug.

File: GEOJSON · Geojson Edge Cases · UTF-8
Use case: GeospatialError handling+1· Conversion set

KML — Typed SchemaData With a Declared Schema

The same five towns with a declared `Schema` and typed `SimpleData` values — KML's answer to untyped ExtendedData. Pair it with the untyped fixture to check that your importer prefers a declared type over a guessed one.

File: KML · Kml · UTF-8
Use case: GeospatialMetadata testing+1· Conversion set

WKT — Intentionally Invalid: Four Malformed Values

Intentionally invalid: four WKT strings that each break in a different way — a point with one ordinate, a line whose last vertex is ragged, a polygon missing a closing bracket, and a misspelled keyword. Good parsers report which line and which character failed.

File: WKT · Wkt Wkb · 4 records
Use case: GeospatialError handling+1· Conversion set

Measurement JSON Schema — Units as Annotations (.json)

A 2020-12 JSON Schema for the absorbance rows, carrying the physical unit and coverage factor as custom annotation keywords beside the standard type and range constraints. Annotations like these are ignored by validators and read by humans and tooling, which is precisely the contract being tested.

File: JSON · Measurements
Use case: Scientific dataSchema validation+1· Conversion set

Json Decoded-Result Reference For The Hdf5 Hierarchy And Its Normalisation Invariant

JSON decoded-result reference for the HDF5 hierarchy and its normalisation invariant, kept beside the binary source for semantic rather than byte-level comparison. Stable P8 artifact p8-convert-hdf5-expected.

File: JSON · P8 Convert
Use case: Conversion testingScientific data+1· Conversion set

Json Schema Reference That Validates The Hdf5 Decoded-Result Contract

JSON Schema reference that validates the HDF5 decoded-result contract, kept beside the binary source for semantic rather than byte-level comparison. Stable P8 artifact p8-convert-hdf5-schema.

File: JSON · P8 Convert
Use case: Conversion testingScientific data+1· Conversion set

GitHub Actions Over-Permissive Token (Policy Target)

A schema-valid workflow that should still be rejected on review: permissions: write-all at the workflow level plus three unused write scopes on the job. Nothing here is an exploit; it is the least-privilege finding a policy engine is supposed to raise.

File: YML · Github Actions
Use case: Config testingSchema validation+1

GitHub Actions Workflow, Intentionally Invalid

An intentionally invalid GitHub Actions workflow: well-formed YAML that breaks the workflow schema in four documented ways — no jobs mapping, a scalar `on`, a mapping `runs-on`, and a step carrying both uses and run. For testing that a validator rejects, and reports why.

File: YML · Github Actions
Use case: Error handlingConfig parsing+1

GitLab CI Config, Intentionally Invalid

An intentionally invalid GitLab CI config: valid YAML with a misspelled `stagess` key, a job naming an undeclared stage, a job with no script, and an `only:` given a bare scalar. For testing that a linter rejects it and names each fault.

File: YML · Gitlab Ci
Use case: Error handlingConfig parsing+1

CircleCI Config, Intentionally Invalid

An intentionally invalid CircleCI config: an unquoted `version: 2.10` that YAML loads as the float 2.1, a workflow referencing an undefined job, and a job with no execution environment. For testing that a validator rejects it and explains each fault.

File: YML · Circleci
Use case: Error handlingConfig parsing+1

Azure Pipelines, Intentionally Invalid

An intentionally invalid Azure Pipelines file: valid YAML that mixes top-level steps with a stages block, depends on an undeclared stage, and gives `pool` a bare string. For testing that a validator rejects it and reports all three faults.

File: YML · Azure Pipelines
Use case: Error handlingConfig parsing+1

Jenkinsfile, Intentionally Invalid

An intentionally invalid Jenkinsfile: an unclosed stage block so braces never balance, a steps block outside any stage, and a bare identifier where the agent directive needs any, none, or a block. For testing parser error recovery and reporting.

File: JENKINSFILE · Jenkins
Use case: Error handlingConfig parsing+1

Kubernetes CustomResourceDefinition with OpenAPI Schema

A CustomResourceDefinition carrying a deep structural OpenAPI v3 schema with a regex pattern, an enum, a default, and array minItems. Useful both as a CRD fixture and as a nested JSON-Schema-in-YAML validation target.

File: YAML · Kubernetes
Use case: Schema validationJSON parsing+1

Kubernetes Manifest, Intentionally Invalid

An intentionally invalid Kubernetes manifest: a removed apiVersion, a quoted string where replicas needs an integer, a selector that does not match the pod template, and containers as a mapping instead of a list. Four documented faults for a validator to report.

File: YAML · Kubernetes
Use case: Error handlingConfig parsing+1

Helm values.schema.json

The values.schema.json that validates the paired Helm values files: a 2020-12 JSON Schema with $defs, $ref, enums, quantity patterns, and additionalProperties: false on nested objects. Validates the defaults and rejects a values file with an unknown image key.

File: JSON · Helm
Use case: Schema validationJSON parsing+1· Conversion set

Pipeline DAG with a Cycle (JSON), Intentionally Invalid

The shared topology plus one back edge, making it intentionally invalid as a DAG. The document publishes the cycle it contains, so a scheduler or graph validator can be tested on both detecting the cycle and naming it.

File: JSON · Airflow
Use case: Error handlingConfig parsing+1

CWL Workflow, Intentionally Invalid

An intentionally invalid CWL document: a nonexistent cwlVersion, an unknown class, a step consuming an output no step produces, and outputs given as a bare string. Four documented faults for a CWL validator to report.

File: CWL · Cwl
Use case: Error handlingConfig parsing+1

Terraform Configuration, Intentionally Invalid

An intentionally invalid Terraform configuration: an unclosed resource block, a colon where HCL needs an equals sign, a reference to an undeclared resource, and a resource block missing its second label. Four documented faults for a parser to report.

File: TF · Terraform
Use case: Error handlingConfig parsing+1

Terraform Plan JSON

A Terraform plan JSON document with create, update and delete changes, after_unknown markers, sensitivity annotations, and a configuration section. This is the artifact policy engines read before anything runs, which is why it sits with pipeline definitions rather than with run reports.

File: JSON · Terraform
Use case: Schema validationJSON parsing+1

HCL2 Document, Intentionally Invalid

An intentionally invalid HCL2 document: an unclosed block, a colon assignment, a half-quoted block label, and a heredoc whose terminator is misspelled so it swallows the remainder of the file. Four documented faults, each a distinct recovery test.

File: HCL · Hcl
Use case: Error handlingConfig parsing+1

Docker Compose File, Intentionally Invalid

An intentionally invalid Compose file: services as a list, a service with both image and an empty build, an unquoted 8080:8080 port that YAML 1.1 reads as a base-60 integer, and a depends_on naming an undefined service.

File: YAML · Docker
Use case: Error handlingConfig parsing+1

Makefile with Space Indentation, Intentionally Invalid

An intentionally invalid Makefile whose recipe lines are indented with four spaces instead of the required TAB. This is the most common Makefile defect there is, and it is invisible in most editors — which is exactly why it belongs in a fixture set.

File: MK · Build
Use case: Error handlingConfig parsing+1

YAML with TAB Indentation, Intentionally Invalid

An intentionally invalid YAML file indented with real TAB characters, which the spec forbids for indentation. The final key shows the legal case — a tab inside a quoted scalar — so a parser can be checked for rejecting one without rejecting the other.

File: YAML · YAML Edge Cases
Use case: Error handlingConfig parsing+1

YAML Unclosed Flow Collection, Intentionally Invalid

An intentionally invalid YAML file whose flow sequence is opened and never closed, so the parser consumes the rest of the document and fails at end of stream. A good error message names the opening bracket, not the last line, which is what this fixture measures.

File: YAML · YAML Edge Cases
Use case: Error handlingConfig parsing+1

Audio Workflow 01 — Evaluation Contract

JSON evaluation contract for podcast trailer kit 01; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-01-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 02 — Evaluation Contract

JSON evaluation contract for product demonstration kit 02; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-02-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 03 — Evaluation Contract

JSON evaluation contract for software tutorial kit 03; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-03-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 04 — Evaluation Contract

JSON evaluation contract for short documentary kit 04; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-04-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 05 — Evaluation Contract

JSON evaluation contract for recipe walkthrough kit 05; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-05-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 06 — Evaluation Contract

JSON evaluation contract for studio interview kit 06; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-06-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 07 — Evaluation Contract

JSON evaluation contract for event recap kit 07; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-07-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 08 — Evaluation Contract

JSON evaluation contract for course lesson kit 08; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-08-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 09 — Evaluation Contract

JSON evaluation contract for portfolio reel kit 09; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-09-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 10 — Evaluation Contract

JSON evaluation contract for non-profit story kit 10; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-10-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 11 — Evaluation Contract

JSON evaluation contract for independent game teaser kit 11; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-11-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 12 — Evaluation Contract

JSON evaluation contract for maker build log kit 12; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-12-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 13 — Evaluation Contract

JSON evaluation contract for travel field note kit 13; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-13-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 14 — Evaluation Contract

JSON evaluation contract for fitness instruction kit 14; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-14-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 15 — Evaluation Contract

JSON evaluation contract for book launch kit 15; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-15-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 16 — Evaluation Contract

JSON evaluation contract for community update kit 16; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-16-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 17 — Evaluation Contract

JSON evaluation contract for science explainer kit 17; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-17-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 18 — Evaluation Contract

JSON evaluation contract for music session kit 18; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-18-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 19 — Evaluation Contract

JSON evaluation contract for customer case study kit 19; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-19-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 20 — Evaluation Contract

JSON evaluation contract for behind-the-scenes feature kit 20; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-20-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 21 — Evaluation Contract

JSON evaluation contract for local news brief kit 21; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-21-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 22 — Evaluation Contract

JSON evaluation contract for design critique kit 22; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-22-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 23 — Evaluation Contract

JSON evaluation contract for fundraising appeal kit 23; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-23-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 24 — Evaluation Contract

JSON evaluation contract for museum audio guide kit 24; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-24-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Audio Workflow 25 — Evaluation Contract

JSON evaluation contract for conference highlight kit 25; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-audio-kit-25-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 01 — Evaluation Contract

JSON evaluation contract for podcast trailer kit 01; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-01-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 02 — Evaluation Contract

JSON evaluation contract for product demonstration kit 02; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-02-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 03 — Evaluation Contract

JSON evaluation contract for software tutorial kit 03; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-03-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 04 — Evaluation Contract

JSON evaluation contract for short documentary kit 04; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-04-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 05 — Evaluation Contract

JSON evaluation contract for recipe walkthrough kit 05; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-05-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 06 — Evaluation Contract

JSON evaluation contract for studio interview kit 06; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-06-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 07 — Evaluation Contract

JSON evaluation contract for event recap kit 07; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-07-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 08 — Evaluation Contract

JSON evaluation contract for course lesson kit 08; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-08-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 09 — Evaluation Contract

JSON evaluation contract for portfolio reel kit 09; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-09-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 10 — Evaluation Contract

JSON evaluation contract for non-profit story kit 10; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-10-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 11 — Evaluation Contract

JSON evaluation contract for independent game teaser kit 11; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-11-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 12 — Evaluation Contract

JSON evaluation contract for maker build log kit 12; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-12-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 13 — Evaluation Contract

JSON evaluation contract for travel field note kit 13; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-13-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 14 — Evaluation Contract

JSON evaluation contract for fitness instruction kit 14; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-14-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 15 — Evaluation Contract

JSON evaluation contract for book launch kit 15; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-15-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 16 — Evaluation Contract

JSON evaluation contract for community update kit 16; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-16-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 17 — Evaluation Contract

JSON evaluation contract for science explainer kit 17; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-17-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 18 — Evaluation Contract

JSON evaluation contract for music session kit 18; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-18-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 19 — Evaluation Contract

JSON evaluation contract for customer case study kit 19; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-19-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 20 — Evaluation Contract

JSON evaluation contract for behind-the-scenes feature kit 20; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-20-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 21 — Evaluation Contract

JSON evaluation contract for local news brief kit 21; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-21-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 22 — Evaluation Contract

JSON evaluation contract for design critique kit 22; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-22-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 23 — Evaluation Contract

JSON evaluation contract for fundraising appeal kit 23; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-23-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 24 — Evaluation Contract

JSON evaluation contract for museum audio guide kit 24; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-24-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit

Video Workflow 25 — Evaluation Contract

JSON evaluation contract for conference highlight kit 25; it publishes readability, timing, comparison, and edge-report assertions. Stable P8 artifact p8-video-kit-25-evaluation-contract.

File: JSON · Workflow Kits
Use case: Prompt testingAgent workflows+1· Workflow kit