JSON Schema documents describing a data shape, for testing validators and schema-aware tooling.
UBL 2.1 invoice XML for Alder Table Bistro. OASIS UBL 2.1 Invoice for INV-BST-5001 with 3 InvoiceLine elements, a TaxTotal of 10.38 on a taxable amount of 207.60, and a PayableAmount of 217.98 CAD. OrderReference names PO-BST-1001 and DespatchDocumentReference names GRN-BST-2001, both of which exist in this folder.
Factur-X CII invoice XML for Alder Table Bistro. UN/CEFACT Cross Industry Invoice for INV-BST-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 10.38 and a DuePayableAmount of 217.98 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Juniper Corner Cafe. OASIS UBL 2.1 Invoice for INV-CAF-5001 with 3 InvoiceLine elements, a TaxTotal of 16.53 on a taxable amount of 330.69, and a PayableAmount of 347.22 CAD. OrderReference names PO-CAF-1001 and DespatchDocumentReference names GRN-CAF-2001, both of which exist in this folder.
Factur-X CII invoice XML for Juniper Corner Cafe. UN/CEFACT Cross Industry Invoice for INV-CAF-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 16.53 and a DuePayableAmount of 347.22 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Copper Oven Bakery. OASIS UBL 2.1 Invoice for INV-BAK-5001 with 3 InvoiceLine elements, a TaxTotal of 8.27 on a taxable amount of 165.41, and a PayableAmount of 173.68 CAD. OrderReference names PO-BAK-1001 and DespatchDocumentReference names GRN-BAK-2001, both of which exist in this folder.
Factur-X CII invoice XML for Copper Oven Bakery. UN/CEFACT Cross Industry Invoice for INV-BAK-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 8.27 and a DuePayableAmount of 173.68 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Ember Lane Pizza. OASIS UBL 2.1 Invoice for INV-PIZ-5001 with 3 InvoiceLine elements, a TaxTotal of 12.19 on a taxable amount of 243.81, and a PayableAmount of 256.00 CAD. OrderReference names PO-PIZ-1001 and DespatchDocumentReference names GRN-PIZ-2001, both of which exist in this folder.
Factur-X CII invoice XML for Ember Lane Pizza. UN/CEFACT Cross Industry Invoice for INV-PIZ-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 12.19 and a DuePayableAmount of 256.00 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Cedar Street Tacos. OASIS UBL 2.1 Invoice for INV-TRK-5001 with 3 InvoiceLine elements, a TaxTotal of 9.38 on a taxable amount of 187.70, and a PayableAmount of 197.08 CAD. OrderReference names PO-TRK-1001 and DespatchDocumentReference names GRN-TRK-2001, both of which exist in this folder.
Factur-X CII invoice XML for Cedar Street Tacos. UN/CEFACT Cross Industry Invoice for INV-TRK-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 9.38 and a DuePayableAmount of 197.08 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Willow Event Kitchen. OASIS UBL 2.1 Invoice for INV-CAT-5001 with 3 InvoiceLine elements, a TaxTotal of 14.79 on a taxable amount of 295.84, and a PayableAmount of 310.63 CAD. OrderReference names PO-CAT-1001 and DespatchDocumentReference names GRN-CAT-2001, both of which exist in this folder.
Factur-X CII invoice XML for Willow Event Kitchen. UN/CEFACT Cross Industry Invoice for INV-CAT-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 14.79 and a DuePayableAmount of 310.63 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
UBL 2.1 invoice XML for Harbour Kitchen Group. OASIS UBL 2.1 Invoice for INV-GRP-5001 with 3 InvoiceLine elements, a TaxTotal of 13.10 on a taxable amount of 261.93, and a PayableAmount of 275.03 CAD. OrderReference names PO-GRP-1001 and DespatchDocumentReference names GRN-GRP-2001, both of which exist in this folder.
Factur-X CII invoice XML for Harbour Kitchen Group. UN/CEFACT Cross Industry Invoice for INV-GRP-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 13.10 and a DuePayableAmount of 275.03 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
A draft-07 JSON Schema describing a user object, for testing schema validators and schema-aware tooling.
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.
A product object that conforms to the product JSON Schema: the positive case for testing a JSON-Schema validator.
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.
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.
Minimal JSON Schema SAMPLE focusing on additional properties false constraints.
Minimal JSON Schema SAMPLE focusing on one of status constraints.
Minimal JSON Schema SAMPLE focusing on enum currency constraints.
Minimal JSON Schema SAMPLE focusing on pattern sku constraints.
Minimal JSON Schema SAMPLE focusing on nullable optional constraints.
Minimal JSON Schema SAMPLE focusing on array unique items constraints.
Minimal JSON Schema SAMPLE focusing on dependent required constraints.
Minimal JSON Schema SAMPLE focusing on format uri email constraints.
The baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.
The compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.
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.
The baseline member of a complete OpenAPI 3.1 ticket endpoint contract. Reference API: string ticket IDs and required id/summary response properties.
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.
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.
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.
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.
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.
The baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.
The compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.
The breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.
Numeric expected results JSON for Alder Table Bistro. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 1452.72 CAD.
Numeric expected results JSON for Juniper Corner Cafe. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 1062.16 CAD.
Numeric expected results JSON for Copper Oven Bakery. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 1261.85 CAD.
Numeric expected results JSON for Ember Lane Pizza. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 1892.29 CAD.
Numeric expected results JSON for Cedar Street Tacos. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 488.57 CAD.
Numeric expected results JSON for Willow Event Kitchen. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 952.38 CAD.
Numeric expected results JSON for Harbour Kitchen Group. The exact numbers a test asserts: document counts, per-order and per-invoice totals, both tax conventions for every invoice, declared and true ageing for both statements, the remittance reconciliation identity, the 5 three-way match outcomes and all 6 deliberate defects with the assertion that detects each one. The correct purchase order net at list price is 977.16 CAD.
Plate costing document for Alder Table Bistro. A nested JSON document with 4 dishes and 12 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Alder Table Bistro. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1736.91, purchases 2834.82, closing 2996.92, cost of goods sold 1574.81 CAD.
Plate costing document for Juniper Corner Cafe. A nested JSON document with 4 dishes and 8 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Juniper Corner Cafe. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1543.40, purchases 2159.69, closing 2164.95, cost of goods sold 1538.14 CAD.
Plate costing document for Copper Oven Bakery. A nested JSON document with 4 dishes and 11 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Copper Oven Bakery. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1479.58, purchases 2420.01, closing 3276.15, cost of goods sold 623.44 CAD.
Plate costing document for Ember Lane Pizza. A nested JSON document with 4 dishes and 18 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Ember Lane Pizza. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 3388.69, purchases 3636.18, closing 3914.44, cost of goods sold 3110.43 CAD.
Plate costing document for Cedar Street Tacos. A nested JSON document with 4 dishes and 18 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Cedar Street Tacos. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1911.28, purchases 972.73, closing 324.44, cost of goods sold 2559.57 CAD.
Plate costing document for Willow Event Kitchen. A nested JSON document with 4 dishes and 19 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Willow Event Kitchen. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1100.18, purchases 1886.41, closing 879.96, cost of goods sold 2106.63 CAD.
Plate costing document for Harbour Kitchen Group. A nested JSON document with 4 dishes and 10 recipe lines, an ingredient block carrying the pack and reference purchase for every price, and an explicit roundingRules object naming the decimal places used at each step.
Cost of goods sold document for Harbour Kitchen Group. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 2124.44, purchases 1963.44, closing 846.80, cost of goods sold 3241.08 CAD.
Digital menu for Alder Table Bistro. One document holding the whole front of house: 3 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Alder Table Bistro. A schema.org Menu document with 7 MenuSection nodes, 5 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Juniper Corner Cafe. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Juniper Corner Cafe. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Copper Oven Bakery. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Copper Oven Bakery. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 30 MenuItem nodes carrying 30 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Ember Lane Pizza. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Ember Lane Pizza. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Cedar Street Tacos. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Cedar Street Tacos. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Willow Event Kitchen. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Willow Event Kitchen. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Digital menu for Harbour Kitchen Group. One document holding the whole front of house: 2 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
Menu as schema.org JSON-LD for Harbour Kitchen Group. A schema.org Menu document with 6 MenuSection nodes, 4 of them top level, and 27 MenuItem nodes carrying 27 Offer nodes, each with price as a JSON number and priceCurrency CAD. Modifiers are menuAddOn MenuItems and every declared allergen travels as an additionalProperty PropertyValue. This is the structured data shape a search engine reads, and it is rare as a downloadable fixture.
Annual return XML for Juniper Workspace Cloud. The same return as XML, with counts as attributes on the container elements and the member name as element text rather than an attribute, so a reader has to take values from both places. Each count attribute equals the number of child elements below it.
ISO 20022 pain.008 direct debit initiation for Harbour Kitchen Group. A customer direct debit initiation message with 8 payment information blocks, one per collection date, because every block carries a single required collection date. The group control sum is 4077.58 CAD and the number of transactions is 8; each block control sum is its own single amount. The service level and local instrument are proprietary domestic and PAD codes rather than SEPA, because the currency is CAD.
X12 837 professional claim batch for Juniper Fitness and Clinic Administration. One interchange, one functional group, one transaction set carrying all 16 claims and 18 service lines. The SE segment declares 225 segments from ST to SE inclusive, which is the count a receiver checks first. Every CLM02 equals the SV102 amounts below it, and the CLM02 values sum to 1,180.00 USD. Segments are terminated with a tilde and the file uses CRLF line endings, which is what an X12 interchange carries in practice.
X12 837 professional claim, single claim for Juniper Fitness and Clinic Administration. The same interchange structure carrying one claim, CLM-0006, with 2 service lines of 120.00 and 85.00 USD. CLM02 is 205.00, which is exactly those two SV102 amounts added. SE01 declares 27 segments.
X12 837 claim whose service lines do not add up to the claim total for Juniper Fitness and Clinic Administration. The same single-claim interchange with one element changed: CLM02 reads 225.00 instead of 205.00. The two SV102 amounts are untouched at 120.00 and 85.00, so they still sum to 205.00 and disagree with the claim total by 20.00 USD. Segment counts, envelope control numbers and every other element are correct, so a structural validator passes the file and only the balance rule catches it.
X12 835 remittance advice for Juniper Fitness and Clinic Administration. One interchange carrying 3 transaction sets, one per payer, because each payer sends its own payment. The three BPR02 amounts sum to 700.80 USD, the payer payment total in encounter-register.csv, and each CLP04 equals the SVC payment amounts below it. The denied claim carries CLP02 of 4 with a zero payment and a CO 97 adjustment for the whole charge, where every other claim carries CLP02 of 1 with a CO 45 contractual adjustment and a PR 2 coinsurance.
Bill of materials XML for Pine Assembly Workshop. The same structure as genuinely nested XML rather than a flat list with a level column, so a reader has to walk the tree and multiply quantities down the path to reach a leaf requirement. SCREW appears in two different branches with different quantities per parent, 8 under BASE and 4 under TOP.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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`.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
