Data files are where parsers quietly break, so this category leans into the edge cases. The CSV set runs from clean to deliberately messy, quoted commas, embedded newlines, ragged rows, semicolon and tab delimiters, a headerless file, a ten-thousand-row file, and a Latin-1 encoded file. JSON comes flat, deeply nested, as JSON Lines, and intentionally invalid for error-handling tests. OpenAPI and JSON Schema twins, paginated API and webhook fixtures, and irregular time-series edges cover modern API QA. There's XML, YAML, and a real SQLite database with related tables, plus faker-generated user and order datasets with documented schemas. Each file spells out its exact quirks in the spec, so when your importer chokes you know precisely which case did it.
Filter data on Browse · 1255 files · 73 subcategories
Encoding matrix (UTF-8 BOM, UTF-16, CP1252, Shift-JIS, Latin-1), delimiter variants, fixed-width, ragged rows, quoted newlines, and domain mini-datasets (SaaS, POS, lab, marketing).
Schemas are documented and values are deterministic synthetic SAMPLE data, shaped like production exports without real customer PII.
Filter Browse by purpose encoding-detection or open the encodings subcategory under Data.
Yes, later waves add valid/invalid schema twins, pagination and webhook API fixtures, and irregular timestamp / DST-gap series. Filter by schema-testing or timeseries-testing.
Aged creditors summary for Alder Books Reconciliation. The 3 suppliers behind the 16 operating payments, grouped by expense category. The amounts due are 774.00, 617.00, 673.00 and they sum to 2064.00, which is the total of the three actual columns on the budget report.
Aged debtors report for Alder Books Reconciliation. 8 open receivables aged at 2026-09-08, each with 100.00 outstanding against an invoice of between 750.00 and 1275.00. The ageing buckets hold 0.00 current, 500.00 at 31 to 60 days and 300.00 at 61 to 90 days, summing to 800.00, the receivables line of the trial balance.
Balanced manual journal batch for Alder Books Reconciliation. 3 month-end journals of 2 lines each, 6 lines in total: an accrual, a reclassification and a prepayment release. Each batch_id balances on its own and the batch as a whole posts 339.75 of debits and the same of credits.
Bank reconciliation for Alder Books Reconciliation. All 24 statement transactions matched one for one to a cash-account ledger line, with a difference column that is 0.00 on every row. There are no unpresented items and no deposits in transit, so the book balance 10236.00 equals the statement balance 10236.00 and the reconciling difference is 0.00.
Bank reconciliation JSON for Alder Books Reconciliation. The same 24 matches as bank-reconciliation.csv with the reconciliation summary at the top: statement closing 10236.00, book closing 10236.00, nothing outstanding or unpresented and a reconciling difference of 0.00.
Bank statement CSV for Alder Books Reconciliation. 24 transactions from 2026-08-01 to 2026-08-24 in separate debit and credit columns, with a running balance. The statement opens at 5000.00 and closes at 10236.00; 8 credits total 7300.00 and 16 debits total 2064.00.
Budget versus actual for Alder Books Reconciliation. 3 expense categories for 2026-08 with budget, actual, variance and variance percent. Budgets total 4200.00 against actuals of 2064.00, leaving 2136.00 unspent. Every actual equals the sum of the ledger postings to that expense account.
camt.053 bank statement for Alder Books Reconciliation. An ISO 20022 camt.053.001.02 BankToCustomerStatement carrying the same 24 entries as bank-statement.csv. The OPBD balance is 5000.00 and the CLBD balance 10236.00; TxsSummry declares 8 credit entries totalling 7300.00 and 16 debit entries totalling 2064.00, and Ntry elements are present for all 24.
camt.053 whose entry count does not match its entries for Alder Books Reconciliation. Well-formed XML with the same header, balances and TxsSummry as bank-statement-camt053.xml, but the final Ntry, TXN-024 for 206.00 on 2026-08-24, has been dropped. NbOfNtries still declares 24 while only 23 Ntry elements are present, and the entries now sum to 10442.00 against a CLBD balance of 10236.00.
Chart of accounts for Alder Books Reconciliation. 9 postable accounts covering assets, liabilities, equity, income and expenses, with the normal balance side declared on every row. Codes run 1000 to 5200 and every account code used anywhere in the general ledger export appears here.
Chart of accounts JSON for Alder Books Reconciliation. The same 9 accounts as chart-of-accounts.csv as a JSON array under an accounts key, with the reporting currency declared once at the top level.
COBOL copybook for the GL feed for Alder Books Reconciliation. A COBOL record description for the same 120-character layout, with PIC clauses matching gl-feed-layout.json field for field: X(n) for the alphanumeric fields and 9(12)V99 for the two amount fields, which is where the two implied decimal places are declared. Comment lines carry the column ranges.
Fixed-width general ledger feed for Alder Books Reconciliation. 66 records of exactly 120 characters each, the shape a legacy banking or ERP feed still arrives in. Amounts are unsigned cents, zero filled and right justified in a 14-character field, so 5000.00 is written as 00000000500000. Text fields are space padded and truncated at their declared width. There is no delimiter and no header row; the column map is gl-feed-layout.json.
Fixed-width GL feed column map for Alder Books Reconciliation. The documented column map for gl-feed-fixed-width.txt: 7 fields with 1-based start position, length, end position and type, adding up to the declared 120-character record. It also states the padding rules and that amounts carry two implied decimal places.
Fixed-width GL feed with one record a byte short for Alder Books Reconciliation. The same 66 records as gl-feed-fixed-width.txt except that record 5 is 119 characters instead of 120: the final character of the 4-character currency field has been lost. Every other record is correct, so a reader that splits on newlines and slices by position reads USD as US on that one record and carries on silently.
General ledger export for Alder Books Reconciliation. 66 ledger lines in four journals: GEN carries the opening balance, SAL the 8 sales invoices, CSH the 8 cash receipts and PUR the 16 supplier payments. Debits total 22464.00 and credits the same, and every document_id posts a balanced pair of lines.
General ledger export JSON for Alder Books Reconciliation. The same 66 lines as general-ledger-export.csv with a totals object declaring 22464.00 of debits and the same of credits. The period runs from the earliest invoice date 2026-07-02 to the last bank movement 2026-08-24.
General ledger in the European CSV dialect for Alder Books Reconciliation. The same 66 ledger lines with a semicolon delimiter, decimal commas, dot thousands separators and dd/mm/yyyy posting dates. This is the shape a ledger export from a European accounting package arrives in.
General ledger with parenthesised credits and grouped thousands for Alder Books Reconciliation. The same 66 lines collapsed into one signed_amount column in accounting presentation: credits appear as (1,234.50) rather than -1234.50 and thousands carry comma separators. The first credit line reads (5,000.00). Summing the column requires stripping the separators and reading the parentheses as a negative sign.
ISO 20022 pain.001 payment initiation for Alder Books Reconciliation. A pain.001.001.03 CustomerCreditTransferInitiation paying the 3 suppliers on aged-creditors.csv. GrpHdr declares NbOfTxs 3 and CtrlSum 2064.00; the single PmtInf block repeats those figures and contains 3 CdtTrfTxInf blocks for 774.00, 617.00, 673.00, each with a creditor IBAN and BIC.
Journal batch with one entry out by 45.00 for Alder Books Reconciliation. The same 3 journals as journal-batch.csv except that line 2 of JB-2026-08-02 credits 19.50 where its debit line is 64.50. That one journal is out by 45.00; the other two balance exactly, which is what makes this the realistic case: a batch-level check catches it only because nothing else offsets it.
Ledger reconciliation assertions for Alder Books Reconciliation. The six identities this set claims with their figures: ledger totals 22464.00, trial balance 13100.00 each side, cash 10236.00, receivables 800.00, a 0.00 bank reconciliation and a pain.001 control sum of 2064.00. It also records the exact size and cause of all five deliberate defects in the set.
MT940 bank statement for Alder Books Reconciliation. A SWIFT MT940 customer statement with tags :20:, :25:, :28C:, :60F:, 24 :61:/:86: pairs, :62F: and :64:. Amounts use the MT decimal comma and dates the YYMMDD form, so the opening balance reads C260801USD5000,00 and the closing balance C260824USD10236,00. Line endings are CRLF, as the MT message format requires.
MT940 whose :62F: closing balance is out by 100.00 for Alder Books Reconciliation. Identical to bank-statement-mt940.txt in every tag except :62F: and :64:, which state C260824USD10336,00 where the 24 :61: movements applied to the :60F: opening balance give C260824USD10236,00. The file is out by exactly 100.00 and nothing inside the statement explains the difference.
OFX 1.0.3 bank statement for Alder Books Reconciliation. An OFX 1.0.3 bank download in the SGML form: nine colon-delimited header lines, a blank line, then unclosed tags inside <OFX>. It carries 24 STMTTRN records with DTPOSTED in YYYYMMDD form and TRNAMT signed, plus a LEDGERBAL of 10236.00 dated 20260824. Line endings are CRLF, as OFX 1.x files from banks are.
QIF bank statement for Alder Books Reconciliation. A Quicken Interchange Format export opening with !Type:Bank and carrying 24 records terminated by a caret on its own line. Dates use the ambiguous mm/dd/yyyy form QIF is notorious for, amounts are signed with no currency, and there is no balance field at all, so the 10236.00 closing figure can only be derived. Line endings are CRLF.
SAF-T style ledger extract for Alder Books Reconciliation. An audit-file extract structured after the OECD SAF-T 2.0 element names: Header, MasterFiles with 9 GeneralLedgerAccounts and 8 Customers, then GeneralLedgerEntries declaring NumberOfEntries 33, TotalDebit 22464.00 and TotalCredit 22464.00, with one Transaction per document and 66 Line elements in total.
Trial balance JSON for Alder Books Reconciliation. The same 9 accounts as trial-balance.csv with the totals lifted into their own object: debit 13100.00, credit 13100.00, difference 0.00. The TOTAL row is not repeated inside the accounts array, so summing the array cannot double count.
Trial balance out by 1250.00 for Alder Books Reconciliation. Identical to trial-balance.csv except that account 5200 Services expense is stated as 1923.00 instead of 673.00. Debits therefore come to 14350.00 against credits of 13100.00, a difference of exactly 1250.00. The TOTAL row is recalculated and agrees with the account rows, so the file is internally consistent and only the double-entry rule is broken.
Trial balance that balances for Alder Books Reconciliation. 9 accounts plus a TOTAL row. Debits and credits each come to 13100.00, so the difference is exactly 0.00. Cash carries 10236.00, which is the closing balance of the bank statement; receivables carry 800.00, which is the aged debtors total; and the two accounts with no movement are reported at 0.00 rather than omitted.
Batch API response mixing success and failure per sub-request.
Cursor-paginated SAMPLE API response page 1 with nextCursor metadata.
Cursor-paginated SAMPLE API response page 2 with nextCursor metadata.
Empty paginated response: edge case for UI empty states and merge logic.
A 404 error body in RFC 9457 (problem+json) form, with type, title, status, detail, and instance, for testing structured error handling and problem-detail parsers.
A 422 validation-error response with a machine-readable list of field errors, for testing form-validation surfacing and error mapping.
RFC 5988 Link header pagination metadata as JSON for HTTP client tests.
Nested pagination object for comments under a post. Tests deeply nested page tokens.
Offset/limit paginated SAMPLE response page 1 for list-merge tests.
Offset/limit paginated SAMPLE response page 2 for list-merge tests.
RFC 7807 SAMPLE problem document for HTTP 400 (Bad Request) client tests.
RFC 7807 SAMPLE problem document for HTTP 409 (Conflict) client tests.
RFC 7807 SAMPLE problem document for HTTP 403 (Forbidden) client tests.
RFC 7807 SAMPLE problem document for HTTP 410 (Gone) client tests.
RFC 7807 SAMPLE problem document for HTTP 500 (Internal Server Error) client tests.
RFC 7807 SAMPLE problem document for HTTP 406 (Not Acceptable) client tests.
RFC 7807 SAMPLE problem document for HTTP 404 (Not Found) client tests.
RFC 7807 SAMPLE problem document for HTTP 503 (Service Unavailable) client tests.
RFC 7807 SAMPLE problem document for HTTP 429 (Too Many Requests) client tests.
RFC 7807 SAMPLE problem document for HTTP 401 (Unauthorized) client tests.
RFC 7807 SAMPLE problem document for HTTP 422 (Unprocessable Entity) client tests.
RFC 7807 SAMPLE problem document for HTTP 415 (Unsupported Media Type) client tests.
Rate-limit header values captured as JSON for middleware testing.
Page 1 of a paginated JSON API response (users), with page metadata and a `hasMore` flag. Paired with page 2 for testing pagination and infinite-scroll logic.
Page 2 (the final page) of a paginated JSON API response. Paired with page 1 for testing pagination, `hasMore` handling, and list merging.
Paginated response where total count disagrees with items length. Tests inconsistency detection.
GraphQL error response with message and location: negative case for GraphQL clients.
Partial GraphQL introspection result for schema-stitching tests.
Sample GraphQL mutation success payload for testing mutation handlers.
Sample GraphQL query response with nested user and orders, for GraphQL client tests.
A GraphQL Schema Definition Language (SDL) file with queries, a mutation, object/input types, and an enum, for testing GraphQL schema parsers, linters, and code generators.
GraphQL subscription event payload for realtime client tests.
A small but complete OpenAPI 3.1 description (two paths, three schemas) in JSON, for testing API tooling, mock servers, client codegen, and docs generators.
The same OpenAPI 3.1 description in YAML: the format most API definitions ship in. Paired with the JSON twin for testing YAML↔JSON conversion and spec parsers.
Callback payload matching the Wave F webhook OpenAPI SAMPLE.
A proto3 Protocol Buffers schema with messages, an enum, and a repeated field, for testing protobuf compilers (protoc), codegen, and schema tooling.
Documented HMAC webhook signature SAMPLE: no real secret, for verifier unit tests.
SAMPLE github push webhook JSON body for signature-verification and parser tests.
SAMPLE slack message webhook JSON body for signature-verification and parser tests.
SAMPLE stripe payment webhook JSON body for signature-verification and parser tests.
A bank-transaction statement: 60 debits and credits across three accounts (masked numbers) with running balances, categories, and merchants. Synthetic data for testing statement parsers, categorisation, and reconciliation.
The bank transactions as a JSON array: the format twin of the CSV, for import and reconciliation testing.
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.
A reference list of well-known payment TEST card numbers (Visa, Mastercard, Amex, Discover, JCB, Diners) with sample CVV and expiry. These are published test values that pass the Luhn check but are not real accounts, for testing payment forms and card validators. Never use real card data.
Banking reconciliation identities for Alder Books Reconciliation. 5 named identities covering the amortisation, the unfinanced arrangement fee, the covenant directions, the direct debit control sum and the two different chargeback totals, with the figures behind each. The deliberate defect and its measured 36.15 USD closing balance are listed separately.
Credit application JSON for Alder Books Reconciliation. The same application as an object, with each financial summary row keeping the source string that names the file and column it came from. The connected facility is a nested object rather than a string, so a reader can tell that the existing borrowing belongs to a different entity.
Trade credit references for Alder Books Reconciliation. 3 trade references with credit limits, highest balance reached and average days to pay. Every highest_balance_usd is below its own credit_limit_usd, so a utilisation check passes on all three, and the two supplier names are the suppliers the inventory-manufacturing model actually buys from.
Chargeback evidence index for Fieldnote Supply Shop. 8 evidence items with the file and record each one points at and what it proves. Seven of the eight resolve into the wave-one ecommerce document set by filename and record identifier, so the packet is not a self-contained story but a set of pointers that either resolve or do not.
Chargeback reason code reference for Fieldnote Supply Shop. 5 reason codes with the category, the representment window and the evidence each one expects. The two codes the wave-one chargeback register uses, 10.4 and 13.1, are both here, so that register can be joined to this table to find out what evidence each open case needs.
Chargeback representment submission for Fieldnote Supply Shop. The whole case as one object: amounts, evidence pointers and timeline. The amounts object separates netExposure of 150.00 from cardholderTotal of 151.20, which differ by the 16.20 USD of tax, so a reader cannot confuse what the seller loses with what the cardholder paid.
Chargeback timeline for Fieldnote Supply Shop. 7 events in date order from the order on 2026-08-06 to the representment deadline on 2026-09-11. Three rows carry an empty amount because dispatch, evidence submission and a deadline move no money, so a reader that treats the amount column as always numeric has three rows to handle.
Direct debit collection schedule for Harbour Kitchen Group. 8 collections under mandate DDM-2026-0007, each 5 days after its invoice date with advance notice three days before that. The amounts are the supplier invoice totals the restaurant purchase ledger holds and sum to 4,077.58 CAD. The first collection carries sequence type FRST and the other 7 carry RCUR, which is the distinction a scheme rejects a file for getting wrong.
Direct debit mandate register for Harbour Kitchen Group. Two mandates for the same debtor account, one active and one cancelled. The active mandate has taken 8 of its 8 collections by the 2026-09-08 snapshot, 4,077.58 CAD of the 4,077.58 authorised. The cancelled mandate still shows the three collections it took before it was cancelled, because cancelling a mandate does not reverse what it already collected.
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.
Covenant test schedule for Pine Assembly Workshop. The 4 covenant tests as data, with required, actual and headroom in their own columns and a unit column, because two of the four are money and one is a ratio. Headroom is signed in the direction of compliance, so a minimum covenant and a maximum covenant both show positive headroom when they pass.
Loan amortisation schedule for Pine Assembly Workshop. 36 rows with opening balance, payment, interest, capital, closing balance and cumulative interest. Payment equals interest plus capital and closing equals opening less capital on every row. The closing balance on row 36 is exactly 0.00 because the final payment is adjusted to 1479.81, and cumulative interest ends at 5276.66 USD.
Loan amortisation schedule whose final balance does not reach zero for Pine Assembly Workshop. The same 36 months with one number changed: the instalment is 1479.00, the correct 1479.91 rounded down to whole dollars. Every row still satisfies payment equals interest plus capital and closing equals opening less capital, but after the last payment the borrower still owes 36.15 USD instead of 0.00. Cumulative interest ends at 5280.15, which is 3.49 more than the correct schedule, because the balance falls more slowly.
Loan summary for Pine Assembly Workshop. The facility terms as a flat object, including the arrangement fee of 480.00 USD with an explicit arrangementFeeIsFinanced flag set to false, so a reader cannot silently add it to the principal. The monthly rate is a string at eight decimal places for the same reason the workbook carries it that way.
Quarterly interest accrual for Pine Assembly Workshop. The first 4 quarters of the facility rolled up from the monthly schedule. Each row opening balance is the opening balance of the first month in the quarter and each closing is the closing of the last, so closing equals opening less capital repaid and the quarters chain without a gap.
The same records as Apache Avro: a compact row-based binary format that embeds its own schema, widely used in Kafka pipelines. For testing Avro decoders and schema evolution.
The records as BSON: the binary-JSON encoding MongoDB stores documents in. For testing BSON decoders and JSON↔BSON conversion.
The records as CBOR: the IETF concise binary object representation used in IoT and COSE/WebAuthn. For testing CBOR decoders and JSON↔CBOR conversion.
The employee table as a dBase (DBF) file: the venerable xBase table format still emitted by GIS tools and legacy databases. For testing DBF readers and DBF→CSV conversion.
The same table as Feather (Arrow IPC file): the zero-copy on-disk form of an Apache Arrow table. For testing Arrow readers and fast columnar interchange.
A small HDF5 file with a compound 'employees' dataset and a numeric 'readings' grid: the hierarchical format used across science and ML. For testing h5py/HDF5 readers and conversion.
The records as MessagePack: a compact binary serialization that maps onto the JSON data model, common in caches and RPC. For testing MessagePack codecs and JSON↔MessagePack conversion.
The same employee table as Apache ORC: the columnar format common in the Hive/Hadoop ecosystem. For testing ORC readers and Parquet↔ORC conversion.
A small employee table as Apache Parquet: the columnar format at the heart of modern data lakes and analytics. For testing Parquet readers (pandas, Spark, DuckDB) and conversion.
A single protobuf User message in binary wire format (varint + length-delimited fields): the serialized counterpart to the user.proto schema. For testing protobuf decoders without the generated code.
Generic primary records CSV for Alder Books Reconciliation. 24 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Alder Books Reconciliation. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Alder Books Reconciliation. 102 records across 6 linked tables; no duplicate primary keys or missing references. Net cash change=5,236.00 USD; Journal debits=9,364.00 USD; Journal credits=9,364.00 USD.
Numeric expected results for Alder Books Reconciliation. Exact table counts, metric formulas, 24 chart points and three negative-test outcomes. Net cash change=5,236.00 USD; Journal debits=9,364.00 USD; Journal credits=9,364.00 USD.
Operating model JSON Schema for Alder Books Reconciliation. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Equivalent purchase import TSV for Alder Table Bistro. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Alder Table Bistro. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Alder Table Bistro. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Alder Table Bistro. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Alder Table Bistro. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Alder Table Bistro. 369 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=11,652.45 CAD; Net menu sales=15,780.80 CAD; Menu items sold=1,092.00 items; Guest reviews=18.00 records.
Numeric expected results for Alder Table Bistro. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=11,652.45 CAD; Net menu sales=15,780.80 CAD; Menu items sold=1,092.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Alder Table Bistro. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Alder Table Bistro. 96 data rows, 8 columns and 96 expected accepted rows.
Equivalent purchase import TSV for Cedar Street Tacos. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Cedar Street Tacos. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Cedar Street Tacos. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Cedar Street Tacos. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Cedar Street Tacos. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Cedar Street Tacos. 375 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=4,122.61 CAD; Net menu sales=19,374.60 CAD; Menu items sold=1,540.00 items; Guest reviews=18.00 records.
Numeric expected results for Cedar Street Tacos. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=4,122.61 CAD; Net menu sales=19,374.60 CAD; Menu items sold=1,540.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Cedar Street Tacos. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Cedar Street Tacos. 96 data rows, 8 columns and 96 expected accepted rows.
Generic primary records CSV for Cobalt Operations Team. 8 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Cobalt Operations Team. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Cobalt Operations Team. 102 records across 5 linked tables; no duplicate primary keys or missing references. Paid hours=336.00 hours; Base pay=9,072.00 USD; Employees=8.00 records.
Numeric expected results for Cobalt Operations Team. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Paid hours=336.00 hours; Base pay=9,072.00 USD; Employees=8.00 records.
Operating model JSON Schema for Cobalt Operations Team. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Equivalent purchase import TSV for Copper Oven Bakery. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Copper Oven Bakery. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Copper Oven Bakery. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Copper Oven Bakery. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Copper Oven Bakery. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Copper Oven Bakery. 368 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=10,172.83 CAD; Net menu sales=6,651.14 CAD; Menu items sold=1,316.00 items; Guest reviews=18.00 records.
Numeric expected results for Copper Oven Bakery. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=10,172.83 CAD; Net menu sales=6,651.14 CAD; Menu items sold=1,316.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Copper Oven Bakery. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Copper Oven Bakery. 96 data rows, 8 columns and 96 expected accepted rows.
Equivalent purchase import TSV for Ember Lane Pizza. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Ember Lane Pizza. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Ember Lane Pizza. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Ember Lane Pizza. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Ember Lane Pizza. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Ember Lane Pizza. 375 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=15,061.21 CAD; Net menu sales=25,954.50 CAD; Menu items sold=1,428.00 items; Guest reviews=18.00 records.
Numeric expected results for Ember Lane Pizza. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=15,061.21 CAD; Net menu sales=25,954.50 CAD; Menu items sold=1,428.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Ember Lane Pizza. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Ember Lane Pizza. 96 data rows, 8 columns and 96 expected accepted rows.
Generic primary records CSV for Fieldnote Learning Centre. 3 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Fieldnote Learning Centre. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Fieldnote Learning Centre. 72 records across 5 linked tables; no duplicate primary keys or missing references. Enrollments=18.00 records; Passed completions=9.00 learners; Available course seats=30.00 seats.
Numeric expected results for Fieldnote Learning Centre. Exact table counts, metric formulas, 3 chart points and three negative-test outcomes. Enrollments=18.00 records; Passed completions=9.00 learners; Available course seats=30.00 seats.
Operating model JSON Schema for Fieldnote Learning Centre. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Fieldnote Supply Shop. 6 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Fieldnote Supply Shop. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Fieldnote Supply Shop. 86 records across 9 linked tables; no duplicate primary keys or missing references. Gross item sales=942.00 USD; Refunded amount=80.00 USD; Orders=12.00 records.
Numeric expected results for Fieldnote Supply Shop. Exact table counts, metric formulas, 12 chart points and three negative-test outcomes. Gross item sales=942.00 USD; Refunded amount=80.00 USD; Orders=12.00 records.
Operating model JSON Schema for Fieldnote Supply Shop. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Shopify profile CSV for Fieldnote Supply Shop. 6 unique records follow the documented Shopify field subset. Strict local specification checks pass; account import and stored results are not verified.
Shopify profile schema for Fieldnote Supply Shop. 6 unique records follow the documented Shopify field subset. Strict local specification checks pass; account import and stored results are not verified.
Square profile CSV for Fieldnote Supply Shop. 6 unique records follow the documented Square field subset. Map these source fields into a current account export; this file is not a native Square import.
Square profile schema for Fieldnote Supply Shop. 6 unique records follow the documented Square field subset. Map these source fields into a current account export; this file is not a native Square import.
Woocommerce profile CSV for Fieldnote Supply Shop. 6 unique records follow the documented Woocommerce field subset. Strict local specification checks pass; account import and stored results are not verified.
Woocommerce profile schema for Fieldnote Supply Shop. 6 unique records follow the documented Woocommerce field subset. Strict local specification checks pass; account import and stored results are not verified.
Generic primary records CSV for Harbour House Stay. 6 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Harbour House Stay. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Harbour House Stay. 53 records across 7 linked tables; no duplicate primary keys or missing references. Occupied room nights=48.00 nights; Room revenue=6,840.00 USD; Ancillary revenue=672.00 USD.
Numeric expected results for Harbour House Stay. Exact table counts, metric formulas, 6 chart points and three negative-test outcomes. Occupied room nights=48.00 nights; Room revenue=6,840.00 USD; Ancillary revenue=672.00 USD.
Operating model JSON Schema for Harbour House Stay. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Equivalent purchase import TSV for Harbour Kitchen Group. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Harbour Kitchen Group. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Harbour Kitchen Group. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Harbour Kitchen Group. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Harbour Kitchen Group. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Harbour Kitchen Group. 369 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=7,897.76 CAD; Net menu sales=26,214.00 CAD; Menu items sold=1,764.00 items; Guest reviews=18.00 records.
Numeric expected results for Harbour Kitchen Group. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=7,897.76 CAD; Net menu sales=26,214.00 CAD; Menu items sold=1,764.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Harbour Kitchen Group. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Harbour Kitchen Group. 96 data rows, 8 columns and 96 expected accepted rows.
Equivalent purchase import TSV for Juniper Corner Cafe. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Juniper Corner Cafe. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Juniper Corner Cafe. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Juniper Corner Cafe. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Juniper Corner Cafe. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Juniper Corner Cafe. 365 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=8,715.93 CAD; Net menu sales=10,234.74 CAD; Menu items sold=1,204.00 items; Guest reviews=18.00 records.
Numeric expected results for Juniper Corner Cafe. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=8,715.93 CAD; Net menu sales=10,234.74 CAD; Menu items sold=1,204.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Juniper Corner Cafe. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Juniper Corner Cafe. 96 data rows, 8 columns and 96 expected accepted rows.
Generic primary records CSV for Juniper Fitness and Clinic Administration. 3 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Juniper Fitness and Clinic Administration. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Juniper Fitness and Clinic Administration. 66 records across 5 linked tables; no duplicate primary keys or missing references. Available slots=24.00 slots; Occupied slots=16.00 slots; Booking records=18.00 records.
Numeric expected results for Juniper Fitness and Clinic Administration. Exact table counts, metric formulas, 3 chart points and three negative-test outcomes. Available slots=24.00 slots; Occupied slots=16.00 slots; Booking records=18.00 records.
Operating model JSON Schema for Juniper Fitness and Clinic Administration. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Juniper Workspace Cloud. 6 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Juniper Workspace Cloud. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Juniper Workspace Cloud. 75 records across 6 linked tables; no duplicate primary keys or missing references. Active monthly recurring revenue=235.00 USD; Paid invoices=649.00 USD; Outstanding invoices=19.00 USD.
Numeric expected results for Juniper Workspace Cloud. Exact table counts, metric formulas, 6 chart points and three negative-test outcomes. Active monthly recurring revenue=235.00 USD; Paid invoices=649.00 USD; Outstanding invoices=19.00 USD.
Operating model JSON Schema for Juniper Workspace Cloud. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Pine Assembly Workshop. 6 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Pine Assembly Workshop. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Pine Assembly Workshop. 89 records across 11 linked tables; no duplicate primary keys or missing references. Units received=96.00 units; Units issued=72.00 units; Assembly relationships=6.00 records.
Numeric expected results for Pine Assembly Workshop. Exact table counts, metric formulas, 6 chart points and three negative-test outcomes. Units received=96.00 units; Units issued=72.00 units; Assembly relationships=6.00 records.
Operating model JSON Schema for Pine Assembly Workshop. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Pine Property Services. 6 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Pine Property Services. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Pine Property Services. 57 records across 6 linked tables; no duplicate primary keys or missing references. Estimated work=3,858.00 USD; Recorded job costs=2,838.00 USD; Work orders=12.00 records.
Numeric expected results for Pine Property Services. Exact table counts, metric formulas, 12 chart points and three negative-test outcomes. Estimated work=3,858.00 USD; Recorded job costs=2,838.00 USD; Work orders=12.00 records.
Operating model JSON Schema for Pine Property Services. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Tern Client Services. 4 generic records with stable primary keys. Map the documented fields before importing into another platform.
Hubspot profile CSV for Tern Client Services. 8 unique records follow the documented Hubspot field subset. Strict local specification checks pass; account import and stored results are not verified.
Hubspot profile schema for Tern Client Services. 8 unique records follow the documented Hubspot field subset. Strict local specification checks pass; account import and stored results are not verified.
Intentionally invalid semantic test records for Tern Client Services. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Tern Client Services. 98 records across 9 linked tables; no duplicate primary keys or missing references. Total deal value=34,500.00 USD; Weighted deal value=15,825.00 USD; Recorded activity time=720.00 minutes.
Numeric expected results for Tern Client Services. Exact table counts, metric formulas, 4 chart points and three negative-test outcomes. Total deal value=34,500.00 USD; Weighted deal value=15,825.00 USD; Recorded activity time=720.00 minutes.
Operating model JSON Schema for Tern Client Services. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Generic primary records CSV for Willow Community Fund. 3 generic records with stable primary keys. Map the documented fields before importing into another platform.
Intentionally invalid semantic test records for Willow Community Fund. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Willow Community Fund. 58 records across 8 linked tables; no duplicate primary keys or missing references. Pledged support=2,850.00 USD; Received support=1,800.00 USD; Outstanding pledges=1,050.00 USD.
Numeric expected results for Willow Community Fund. Exact table counts, metric formulas, 3 chart points and three negative-test outcomes. Pledged support=2,850.00 USD; Received support=1,800.00 USD; Outstanding pledges=1,050.00 USD.
Operating model JSON Schema for Willow Community Fund. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Equivalent purchase import TSV for Willow Event Kitchen. 96 data rows, 8 columns and 96 expected accepted rows.
Guest review import CSV for Willow Event Kitchen. 18 data rows, 5 columns and 18 expected accepted rows.
Intentionally invalid purchase import for Willow Event Kitchen. 4 data rows, 8 columns and 0 expected accepted rows.
Intentionally invalid review import for Willow Event Kitchen. 4 data rows, 5 columns and 0 expected accepted rows.
Intentionally invalid semantic test records for Willow Event Kitchen. Three independent cases report duplicate-primary-key, schema-type and foreign-key errors. JSON syntax remains valid.
Linked operating model for Willow Event Kitchen. 376 records across 18 linked tables; no duplicate primary keys or missing references. Supplier spend=7,900.99 CAD; Net menu sales=28,781.90 CAD; Menu items sold=1,652.00 items; Guest reviews=18.00 records.
Numeric expected results for Willow Event Kitchen. Exact table counts, metric formulas, 8 chart points and three negative-test outcomes. Supplier spend=7,900.99 CAD; Net menu sales=28,781.90 CAD; Menu items sold=1,652.00 items; Guest reviews=18.00 records.
Operating model JSON Schema for Willow Event Kitchen. Draft 2020-12 schema accepts the paired operating model. Relational rules additionally require unique keys and existing foreign references.
Purchase import CSV for Willow Event Kitchen. 96 data rows, 8 columns and 96 expected accepted rows.
An intentionally corrupt iCalendar file whose VEVENT is never closed, for testing fatal component-nesting errors without using a large or hostile payload.
A complete iCalendar structure using LF-only line endings, a common recoverable export defect for tolerant parser tests.
A standards-conforming event with a folded content line and UTF-8 text for baseline parser and line-unfolding tests.
A recurrence set with both an exclusion and an explicit addition, useful for catching expansion engines that apply only one modifier.
A weekly five-occurrence series that provides the recurrence baseline before exclusions or additions are applied.
The same weekly series with its third occurrence excluded, for testing RRULE expansion followed by EXDATE filtering.
The terminal cancellation for the scheduling group, checking METHOD, STATUS, UID and sequence precedence together.
An attendee acceptance for the same meeting, used to test UID correlation and PARTSTAT state updates.
The invitation that starts a scheduling lifecycle, using stable UID and organizer/attendee identities.
The UTC representation of the Toronto event, providing an exact normalization target for calendar importers.
A floating-time variant with no TZID or Z suffix, for verifying that parsers do not silently reinterpret local wall time as UTC.
A TZID-qualified event immediately after Toronto's spring-forward boundary, with an explicit VTIMEZONE definition.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 2.1 syntax.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 3.0 syntax.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 4.0 syntax.
An iCalendar (.ics) file with a single event and CRLF line endings per spec, for testing calendar imports.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 2.1 syntax.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 3.0 syntax.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 4.0 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 2.1 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 3.0 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 4.0 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 2.1 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 3.0 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 4.0 syntax.
A vCard 3.0 contact with name, email, phone, and address, for testing contact importers.
JSON description of nullable columns in the null-heavy columnar fixtures.
Feather file with dictionary-encoded strings: Arrow IPC edge-case fixture.
Feather/Arrow IPC twin of the null-heavy table, grouped with the Parquet nulls fixture.
Amounts stored as strings in Parquet: common ingestion edge case for ETL parsers.
Parquet with dictionary-encoded string column. Tests dictionary page decoding.
Parquet with repeated key values. Tests join/aggregation edge cases.
Empty Parquet file with schema but no rows: edge case for readers.
Parquet with a list-of-string column. Tests repeated-field decoding.
Parquet with bool/int/string/float columns including a null integer.
Parquet with a struct column. Tests nested type round-trips.
Tiny Parquet table with null name/score/note cells. Tests null handling in columnar readers.
Single-row Parquet table: minimal columnar fixture.
Tiny Apache rewrite rules SAMPLE for .htaccess parser tests.
Sample INI config file for legacy config parser tests.
Sample TOML application config for TOML parser tests.
JSON application settings for config-merge and validation tests.
AWS credentials file shape with obviously fake keys, for credential scanner and parser tests.
Minimal CI pipeline YAML for GitHub Actions / GitLab CI parser tests.
Tiny SAMPLE JSON config fixture (app-feature-flags) for parser and twin tests.
Tiny SAMPLE TOML config fixture (app-feature-flags) for parser and twin tests.
Tiny SAMPLE YAML config fixture (app-feature-flags) for parser and twin tests.
Tiny SAMPLE JSON config fixture (cors-origins) for parser and twin tests.
Tiny SAMPLE ENV config fixture (database-pool) for parser and twin tests.
Tiny SAMPLE INI config fixture (database-pool) for parser and twin tests.
Tiny SAMPLE YAML config fixture (k8s-resource-snippet) for parser and twin tests.
Tiny SAMPLE INI config fixture (logging-levels) for parser and twin tests.
Tiny SAMPLE YAML config fixture (rate-limit) for parser and twin tests.
Tiny SAMPLE TOML config fixture (redis-cache) for parser and twin tests.
Tiny SAMPLE YAML config fixture (redis-cache) for parser and twin tests.
Tiny SAMPLE ENV config fixture (smtp-relay) for parser and twin tests.
A sample docker-compose file defining a web service with Postgres and Redis dependencies, for testing Compose parsers and YAML tooling.
Sample docker-compose override file for merge/extends parser tests.
A sample multi-stage Dockerfile with a build stage and a slim runtime stage, for testing Dockerfile parsers, linters (hadolint), and syntax highlighting. Illustrative only.
A sample environment (.env) file with typical configuration keys and placeholder values, for testing dotenv parsers and config loaders. Contains no real secrets.
SAMPLE .env file (comments-edge) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (development) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (production-template) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (testing) for dotenv parser and config-loader tests: placeholders only.
A classic INI configuration file with sections and key/value pairs, for testing INI parsers.
SAMPLE Kubernetes configmap manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes deployment manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes ingress manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes secret manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes service manifest: fictional names, no real cluster secrets.
Minimal nginx reverse-proxy config SAMPLE for syntax highlighter and linter tests.
Sample terraform.tfvars with fictional region, for HCL/tfvars parser tests.
A TOML configuration file with tables, inline values, and an array of tables, for testing TOML parsers.
A W3C Web App Manifest (JSON) with name, theme colours, and icon set, for testing PWA install prompts and manifest validators.
Application for payment continuation sheet for Pine Property Services. 12 contract items, 2 change order lines and a TOTAL row, in the shape of an AIA G703 continuation sheet. Scheduled values total 4113.00; 1490.00 was certified on the previous application, 1618.00 is claimed this period and 140.00 is materials stored but not installed, giving 3248.00 completed and stored. Retainage is 10 percent of each line and totals 324.80.
Application for payment summary for Pine Property Services. The nine numbered lines of an AIA G702 style application. Contract sum 3858.00 plus 255.00 of change orders gives 4113.00; 3248.00 is completed and stored, retainage of 324.80 splits 310.80 on work and 14.00 on stored material, and after 1341.00 of previous certificates the current payment due is 1582.20.
Application for payment whose retainage was withheld at the wrong rate for Pine Property Services. The same nine lines as application-for-payment-002-summary.csv, but lines 5a and 5b were computed at 5 percent while their own descriptions still read 10 percent. Retainage reads 162.40 instead of 324.80, so the current payment due on line 8 reads 1744.60 against the correct 1582.20, 162.40 too much.
Approved change order register for Pine Property Services. 2 approved change orders: an addition of 420.00 for extra door hardware and a credit of -165.00 for deleted lighting scope, a net 255.00. The running contract sum moves from 3858.00 to 4113.00, which is line 3 of the payment application. A credit change order is a negative amount, not a separate document type.
Completion inspection register for Pine Property Services. 9 inspections, one for each completed work order. 8 passed and 1 needs a follow-up, INSPECT-6 against WO-06. follow_up_required is derived from result and agrees with it on every row. Every note carries the standing caveat that these are operational checks, not regulated certificates.
Construction reconciliation assertions for Pine Property Services. The eight identities this set claims with the figure each must produce: a 3858.00 contract sum moving to 4113.00, 3248.00 completed and stored, 324.80 retained, 1582.20 due, and a job cost variance of 1020.00. It also records the 162.40 size of the deliberate defect.
Cost code budget against actual for Pine Property Services. Two cost codes and a TOTAL row. Labour is budgeted 3120.00 against 2340.00 actual and materials 738.00 against 498.00, so the total budget 3858.00 is the contract sum and the total actual 2838.00 is the job cost report. The percentages are variance over budget: 25.00 on labour, 32.52 on materials and 26.44 overall.
Job cost report JSON for Pine Property Services. The same 12 work orders as job-cost-report.csv with the margin rule stated explicitly. totals.variance is 1020.00, which is 85.00 times the 12 work orders.
Job cost report, estimate against actual for Pine Property Services. 12 work orders with estimate and actual side by side. actual_labour_cost equals actual_labour_hours times actual_labour_rate on every row, actual_total is that plus actual_materials, and variance is estimate_total minus actual_total. Estimates total 3858.00 against 2838.00 of recorded cost, a variance of 1020.00, which is a uniform 85.00 per work order because every estimate carries 65.00 of labour margin and 20.00 of material margin.
Lien waiver register for Pine Property Services. Two waivers, one per payment application. LW-2026-001 is unconditional for 1341.00 because that payment has been received; LW-2026-002 is conditional for 1582.20 and takes effect only on receipt of the current payment. The two amounts sum to 2923.20, the total earned less retainage, so nothing certified is unwaived and the 324.80 of retainage is covered by neither, which is exactly right.
Material purchase register for Pine Property Services. 12 material purchases, one per work order, alternating between two fictional merchants. The amounts are the materials column of the job cost report and sum to 498.00, which is the 02-200 actual on cost-code-summary.csv. Every purchase is dated the day its work order was raised.
Planned maintenance schedule for Pine Property Services. 6 planned reviews, one per property, all on the same 92-day cycle: last carried out 2026-06-15 and next due 2026-09-15, which is 7 days after the 2026-09-08 snapshot. interval_days and days_until_next are both derived from the two date columns.
Property register with job costs for Pine Property Services. 6 properties, each with exactly 2 work orders. total_cost equals labour_cost plus materials on every row and the column sums to 2838.00, the whole job cost. Costs per property run from 328.00 to 618.00.
Retainage ledger for Pine Property Services. Two payment applications. Application 001 certified 1341.00 and retained 149.00; application 002 adds 1758.00 of completed and stored value, retains a further 175.80 and certifies 1582.20. Cumulative retainage reaches 324.80, which is 10 percent of the 3248.00 completed and stored to date.
Schedule of values for Pine Property Services. 12 contract line items, one per work order, plus a total line. Each scheduled_value is the approved estimate for that item and the column sums to 3858.00, the original contract sum every payment application starts from. labour_allowance plus material_allowance equals scheduled_value on every line, and each allowance sits a fixed margin above the recorded cost: 65.00 on labour and 20.00 on materials, which is where the 85.00 per item of estimate-over-actual comes from.
Site daily log for Pine Property Services. 9 daily entries, one for each completed work order, recording the crew, the labour hours and the weather. Hours total 27 and equal the labour hours the job cost report records against the same work orders. The four scheduled work orders have no log entry because no crew has attended them.
Work order export for Pine Property Services. 12 work orders across 6 properties, two per property, raised daily from 2026-08-01. 9 are completed and 3 are still scheduled. total_cost equals labour_cost plus materials on every row and the column sums to 2838.00. Costs are recorded on scheduled work orders as well as completed ones because the materials were bought in advance.
Work order export JSON for Pine Property Services. The same 12 work orders as work-order-export.csv with a byProperty rollup. Each of the 6 properties carries exactly 2 work orders and the totalCost figures sum to 2838.00.
Amendment register for Tern Client Services. Two rows, one per varied clause, each carrying the previous value and the new one so a reader can reconstruct the agreement as it stood on any date. Clause 4.1 moves from 250.00 to 400.00 and clause 5.1 from ten to fifteen business days for one statement of work only.
Clause index for Tern Client Services. Every sub-clause of the three agreements in this set as one row: 57 rows across 3 documents, with the clause number, the heading it sits under, the clauses it refers to and its character count. 16 rows carry at least one cross-reference and every one of those resolves to a clause that exists in the same document.
Contract reconciliation identities for Tern Client Services. 6 named identities with the figures behind each one, including the two places this set deliberately holds different numbers for the same hours: 100.00 USD billed and 60.00 USD paid per hour, and accepted allocation against billed time on PROJECT-1. The deliberate defect and its measured shortfall of 50.00 USD are listed separately.
Contract register for Tern Client Services. 11 agreements across five document types with their effective dates, terms, expiry dates, notice deadlines and values. The three rows whose value_basis is "not to exceed" sum to 9,000.00 USD, the liability cap the master agreement states at clause 10.2. 2 rows carry an empty value because the document has no monetary value, and 2 carry an empty file because no rendering of that contractor agreement ships in this set.
Contract register JSON for Tern Client Services. The same 11 agreements as an object with a contracts array. Empty CSV cells become empty strings rather than null, so a reader that treats the two as the same thing and one that does not will both produce the same record count.
Execution and signature log for Tern Client Services. 19 signature rows covering every executed document in this set. 2 rows have an empty signed_date and an empty method because the counterparty has not signed yet, and their status column says so, so a reader that treats an empty date as a parse failure and one that treats it as unsigned reach different conclusions about the same file.
Obligation register for Tern Client Services. 14 obligations pulled out of the three agreements, each naming the contract, the exact clause it comes from, who owns it, what triggers it and when it falls due. Every clause_ref resolves to a row of contract-clause-index.csv.
Rate card and caps for Tern Client Services. 5 priced terms drawn from the agreements in this set: the 100.00 USD client billing rate, the 60.00 USD contractor pay rate, both expense caps with the dates that separate them, and the 9,000.00 USD liability cap. Every row names the clause it comes from.
Renewal and notice diary for Tern Client Services. 8 dated events in ascending order, each with the number of days from the fixed snapshot of 2026-09-08. The first is 2026-09-18 at 10 days and the last is 2028-11-09 at 793 days. Every date also appears in contract-register.csv, so the diary can be rebuilt from the register and compared.
Statement of work deliverables for Tern Client Services. 9 deliverables across the three statements of work, each with a due date, an allocation, the not-to-exceed value of its own statement of work and a single testable acceptance criterion. Grouped by sow_id the allocations sum to exactly 2000.00, 3000.00 and 4000.00, matching the sow_not_to_exceed_usd column on every row of the group. Two rows are marked accepted on 2026-08-24 and carry an accepted_date; the other seven have an empty accepted_date.
Statement of work deliverables with an allocation that does not add up for Tern Client Services. The same 9 rows as sow-deliverables.csv with one number changed: the SOW-2026-03 D2 allocation is 2150.00 instead of 2200.00. The three SOW-2026-03 allocations therefore sum to 3950.00 against the 4000.00 that every row of that group states as sow_not_to_exceed_usd, a shortfall of 50.00 USD. The other two statements of work still balance exactly.
Annual return JSON for Juniper Workspace Cloud. The same five parts as a nested object with shareCapital, members, officers, personsWithSignificantControl and charges arrays. Numbers that are counts are JSON numbers and numbers that are money are strings with two decimals, so a reader that coerces everything to float loses the trailing zero on 6000.00 and on 14400.00.
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.
Capitalisation table for Juniper Workspace Cloud. The 4 holdings split into nominal and premium with a total row. Only MEM-04 carries premium, 14,400.00 USD, because only the 2026-05-18 allotment was priced above nominal, at 0.25 against 0.01. The percentages are apportioned by largest remainder and sum to exactly 100.0000.
Corporate reconciliation identities for Juniper Workspace Cloud. 6 named identities covering the issued and paid capital, the allotment split, the neutrality of the transfer, the resolution threshold and the trading figures the September minutes quote, with the numbers behind each. The deliberate defect and its 500 share shortfall are listed separately.
Meeting attendance register for Juniper Workspace Cloud. 8 attendance rows across two board meetings. The attended column carries three values, true, false and in attendance, because the secretary attends without being a director and does not count towards the quorum. Both meetings met the quorum of two directors with two and three directors present.
Register of charges for Juniper Workspace Cloud. Two charges, one satisfied and one outstanding. The outstanding floating charge secures 48,000.00 USD, which is the same principal as the loan facility in the banking set, so the two sets describe the same borrowing from the lender side and the borrower side.
Register of directors and secretaries for Juniper Workspace Cloud. 5 officers of whom 4 are currently in office. One row has a resigned_on date of 2026-05-18 and currently_in_office false; the other four have an empty resigned_on. The same date is the board meeting that appointed the replacement, so the register and the minutes agree.
Register of members for Juniper Workspace Cloud. The 4 members with their holdings, certificate numbers and amounts paid. shares_held sums to 600,000, which is the total_issued_shares value every row carries, and percent_of_issued sums to exactly 100.0000. amount_paid_usd sums to 20,400.00 USD, which is the 6,000.00 USD of nominal capital plus the 14,400.00 USD share premium from the 2026-05-18 allotment.
Register of members JSON for Juniper Workspace Cloud. The same 4 members plus the two cancelled certificates the CSV cannot hold, because a cancelled certificate has no current holding and would need a row with an empty share count. A reader that counts certificates from this file gets six; a reader that counts holdings gets four.
Register of members whose holdings do not add up to the issued capital for Juniper Workspace Cloud. The same 4 members with one number changed: MEM-03 holds 59,500 shares instead of 60,000. shares_held now sums to 599,500 against the 600,000 that every row still declares as total_issued_shares, a shortfall of 500 shares, 5.00 USD of nominal capital. percent_of_issued and amount_paid_usd are untouched, so three columns of the same row now disagree with each other.
Register of persons with significant control for Juniper Workspace Cloud. The two members holding more than 25 percent of the shares, with their holdings and percentages taken from the register of members. MEM-03 and MEM-04 hold 10.0000 percent each and are correctly absent, so a reader that expects every member to appear here will look for two rows that should not exist.
Share allotment return for Juniper Workspace Cloud. 4 allotment rows across two returns. On every row consideration is shares times price and also equals nominal plus premium. The three founding rows are priced at nominal so their premium is 0.00; the 2026-05-18 row is priced at 0.25 against a 0.01 nominal, so 15,000.00 USD of consideration splits into 600.00 nominal and 14,400.00 premium.
Shareholding movement history for Juniper Workspace Cloud. 5 movements in date order: four allotments that raise the shares in issue to 600,000 and one transfer of 18,000 shares from MEM-03 to MEM-02 that leaves the total unchanged. Replaying the movements from zero reproduces every holding in register-of-members.csv, including the certificate cancellations the transfer caused.
Statutory registers index for Juniper Workspace Cloud. 6 registers with the file that holds each one, the article clause that requires it, the number of entries and the date it was last updated. Every file named exists in this directory and every entry count matches the row count of that file.
A CSV with 10,000 data rows, for testing streaming parsers, memory handling, and import performance.
A clean, well-formed CSV with a header and 20 rows: the baseline case for CSV parser testing.
Tiny SAMPLE CSV (empty-fields) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (hash-commented) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (header-only) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (mixed-quoting) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (pipe-delimited) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (quoted-embedded-comma) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (quoted-embedded-newline) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (semicolon-eu) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (single-column) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (trailing-comma) exercising delimiter/quoting edge behaviour.
A CSV with no header row, for testing parsers that must infer or be told the column names.
A CSV encoded in Latin-1 (ISO-8859-1) with accented names, for testing encoding detection and mis-decoding (it will look wrong if read as UTF-8).
A deliberately messy CSV: a quoted field with a comma, a quoted field with an embedded newline, escaped double-quotes, and ragged rows with too few and too many fields, the cases that break naïve parsers.
A CSV that uses semicolons as the delimiter (common in European locales), for testing delimiter detection.
A tab-separated values file with a header and 20 rows, for testing TSV parsing and delimiter handling.
A real SQLite database with two related tables (users and orders joined by a foreign key) for testing database importers and SQL tooling.
A draw.io (diagrams.net) diagram in its native mxGraphModel XML (a small flowchart) for testing draw.io import/export and XML parsing of diagram files.
A Graphviz DOT directed graph describing a fulfilment pipeline, for testing DOT parsing, Graphviz rendering, and DOT-to-SVG/PNG conversion.
A Mermaid flowchart of an order-fulfilment process as diagrams-as-code, for testing Mermaid rendering, diagram-to-image conversion, and Markdown pipelines that embed Mermaid.
A PlantUML sequence diagram of an order interaction (customer, store, warehouse) as diagrams-as-code, for testing PlantUML parsing and diagram rendering pipelines.
A realistic e-commerce customer directory (500 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce customers table as a JSON array: the format twin of the CSV, for import and conversion testing.
A relational SQL schema (products, customers, orders with primary and foreign keys) plus sample INSERTs: the DDL twin of the e-commerce dataset, for testing schema import and migrations.
A realistic e-commerce order lines (customer_id → customers, product_id → products) (2000 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce orders table as a JSON array: the format twin of the CSV, for import and conversion testing.
The e-commerce orders table as Apache Parquet: the columnar twin, for testing analytics engines (pandas, DuckDB, Spark).
A realistic e-commerce product catalogue (200 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce products table as a JSON array: the format twin of the CSV, for import and conversion testing.
The e-commerce products table as Apache Parquet: the columnar twin, for testing analytics engines (pandas, DuckDB, Spark).
Customer export with tax jurisdiction for Fieldnote Supply Shop. 6 fictional customers at example.test addresses, each with the jurisdiction that set the tax rate on their orders. Every customer placed 2 orders and merchandise_total sums to 922.00.
Discount code usage for Fieldnote Supply Shop. One promotion, SAMPLE5, a fixed 5.00 USD reduction used on 4 of the 12 orders for a total of 20.00. Those are exactly the orders whose discount_total column in orders-export.csv is not zero.
Inventory and price feed with variants for Fieldnote Supply Shop. 12 variant rows over 6 products, two finishes each. Every gtin is a valid 13-digit GS1 number whose final digit is the modulo-10 check digit, and all 12 begin with a zero, so a spreadsheet that types the column as a number destroys the identifier. Quantities sum to 285 units and match the variant stock in the shop model.
Inventory and price feed XML for Fieldnote Supply Shop. The same 12 variants as inventory-feed.csv. Because the gtin values are element text rather than spreadsheet cells, the leading zeros survive here, which makes this file the reference against which the CSV round trip is checked.
Inventory feed as UTF-16 LE tab-separated text for Fieldnote Supply Shop. The same 12 variants, tab separated and encoded UTF-16 little endian with an FF FE byte order mark. Every ASCII character occupies two bytes, so a reader that opens the file as UTF-8 sees NUL between each letter and usually reports one column.
Marketplace fee schedule for Fieldnote Supply Shop. The four fee codes the settlement uses, with basis, rate and fixed component. REFERRAL at 0.12000 and PROCESSING at 0.02900 plus 0.30 reproduce every fee line in settlement-transactions.csv; REFUND_ADMIN is present at zero because the period waived it, which is why the settlement has no refund fee lines.
Marketplace settlement and payout summary for Fieldnote Supply Shop. The reconciliation people get wrong, stated as a key-value sheet: gross sales 922.00 minus total fees 180.99 minus refunds 80.00 equals net payable 661.01 USD, converted once at 0.91250 to a 603.17 EUR deposit. Every fee component equals the matching group of lines in settlement-transactions.csv.
Marketplace settlement and payout summary JSON for Fieldnote Supply Shop. The same settlement as settlement-payout.csv with the reconciliation rule written out as a string. netPayableUsd is 661.01 and depositAmountEur is 603.17.
Marketplace settlement transaction detail for Fieldnote Supply Shop. 41 settlement lines for period 2026-08: 12 order captures totalling 922.00, 12 referral fees totalling -110.64, 12 processing fees totalling -30.36, one monthly fee of -39.99 and 4 refund debits totalling -80.00. The column sums to 661.01, which is the net payable on settlement-payout.csv.
Multi-jurisdiction tax summary for Fieldnote Supply Shop. 6 jurisdictions across 2 countries, each with its own rate from 0.08250 to 0.13000. Taxable sales total 922.00, tax collected 96.34, tax refunded 7.46 and net tax due 88.88. net_tax_due equals tax_collected minus tax_refunded on every row. tax_collected is the sum of the per-order tax amounts, each already rounded to cents on orders-export.csv, so on US-CA and US-WA it is a cent below what rounding the jurisdiction's own taxable base would give.
Multi-jurisdiction tax summary JSON for Fieldnote Supply Shop. The same 6 jurisdictions as tax-summary.csv, with the marketplace facilitator basis and the rounding basis both stated. totals.netTaxDue is 88.88, and the document records that US-CA and US-WA differ by a cent under the other rounding basis.
Open and resolved chargebacks for Fieldnote Supply Shop. Two disputes against orders ORD-006 and ORD-009. Neither has been debited yet, which is why the 661.01 settlement contains no chargeback line: CB-2026-0001 is still open and CB-2026-0002 was won. The disputed amounts equal the captures on those orders exactly.
Order export CSV for Fieldnote Supply Shop. 12 orders over 2026-08-01 to 2026-08-12 across 6 tax jurisdictions. merchandise_subtotal minus discount_total equals taxable_amount on every row, tax_amount equals taxable_amount times tax_rate rounded half up, and order_total equals taxable_amount plus tax_amount. Column totals: 942.00 merchandise, 20.00 discount, 922.00 taxable, 96.34 tax.
Order export encoded as ISO-8859-1 for Fieldnote Supply Shop. The same 12 orders encoded in ISO-8859-1 (Latin-1) rather than UTF-8. Every byte is below 0x80 in this particular export, so it is byte-identical to the UTF-8 form and is the control case for an encoding test: a detector must not claim to have proved UTF-8 from content that is pure ASCII.
Order export in the European CSV dialect for Fieldnote Supply Shop. The same 12 orders written with a semicolon delimiter, decimal commas, dot thousands separators and dd/mm/yyyy dates. The first data row reads ORD-001;01/08/2026 and its order_total field is 38,06.
Order export JSON for Fieldnote Supply Shop. The same 12 orders as orders-export.csv with an added totals object. totals.taxableAmount is 922.00 and equals the sum of the per-order taxable_amount values.
Order export whose row 7 has an extra field for Fieldnote Supply Shop. Byte-for-byte the same as orders-export.csv except that data row 7 (order ORD-007, file line 8) carries 14 fields where the header declares 13. The surplus field holds the literal text gift-wrap.
Order export with a header and no rows for Fieldnote Supply Shop. A well-formed export for a period with no orders: one header line naming all 13 columns and nothing after it. The file is 163 bytes and ends with a single LF.
Order export with a UTF-8 BOM and US dates for Fieldnote Supply Shop. Identical order data to orders-export.csv, but the file opens with the three bytes EF BB BF and the dates are mm/dd/yyyy. The first header cell is therefore order_id preceded by the BOM, which a reader that does not strip it reports as '\ufeffor der_id' with the BOM glued to the name.
Order export with exactly one row for Fieldnote Supply Shop. One header line and one data row, order ORD-001 for CUS-01 with an order_total of 38.06. The boundary case for readers that infer column types from a sample, which have exactly one observation per column here.
Order line export CSV for Fieldnote Supply Shop. 24 order lines, two per order, each naming the variant actually sold. quantity times unit_price equals line_total on every row and the line totals sum to 942.00, which is the merchandise_subtotal column of orders-export.csv before discounts.
Refund and partial-refund export for Fieldnote Supply Shop. 4 refunds: 2 return the whole line and 2 return one unit of a multi-unit line. merchandise_refund totals 80.00 and matches the refunded column of the shop payments table; tax_refund totals 7.46 and is charged at the order jurisdiction rate on the merchandise refunded.
Refund export JSON for Fieldnote Supply Shop. The same 4 refunds as refunds.csv plus the stated refund policy: the order-level promotion is not clawed back when a line is refunded. totals.merchandiseRefund is 80.00.
Refund export that refunds more than was captured for Fieldnote Supply Shop. The four valid refunds from refunds.csv plus three rows against order ORD-005, whose captured amount is 78.00. Those three rows refund 36.00, 42.00 and a further 18.00 of merchandise, a total of 96.00, which exceeds the capture by 18.00. RFND-007 also refunds LINE-009 a second time after RFND-005 already returned both units.
Returns and RMA register for Fieldnote Supply Shop. 4 return authorisations, one per refund in refunds.csv, each with a requested date four days before the received date and a disposition of return to saleable stock. Every row restocks, so the returned quantities are the ones the inventory feed adds back.
Returns and RMA register XML for Fieldnote Supply Shop. The same 4 authorisations as returns-rma.csv as XML. The root element ReturnAuthorisations declares count="4" and contains exactly that many ReturnAuthorisation children, each with 11 child elements.
Sales by product for Fieldnote Supply Shop. 6 products with units sold, gross merchandise before discount, units refunded and net merchandise. gross_merchandise sums to 942.00, which is the merchandise subtotal of orders-export.csv before the four 5.00 promotions, and merchandise_refunded sums to 80.00.
Settlement reconciliation assertions for Fieldnote Supply Shop. The five identities this document set claims, each with the exact figure it must produce: net payable 661.01 USD, deposit 603.17 EUR and net tax due 88.88. It also records the size of the deliberate defect, 0.02 EUR.
Settlement whose deposit misses by the FX rounding for Fieldnote Supply Shop. Every USD figure is identical to settlement-payout.csv, but the deposit was produced by converting each of the 41 settlement lines to EUR and rounding before summing. deposit_amount_eur reads 603.19 where the single conversion of net_payable_usd gives 603.17, a difference of 0.02 EUR that no USD column reveals.
Shipping manifest for Fieldnote Supply Shop. 10 shipments, one for each of the 10 fulfilled orders; the two orders still processing are absent. billable_weight_kg is the sum of the unit weights on the order plus 0.250 kg of packaging, carried to three decimals. The manifest moves 38 units weighing 21.450 kg with a declared value of 709.00.
Shipping manifest JSON for Fieldnote Supply Shop. The same 10 shipments as shipping-manifest.csv with a totals object declaring 38 units and 21.450 kg of billable weight.
Three-period payout history for Fieldnote Supply Shop. Three consecutive monthly settlements, the last of which is the one detailed in settlement-payout.csv. Each row satisfies gross minus fees minus refunds equals net, and net times fx_rate rounded half up equals the EUR deposit, at three different rates (0.92410, 0.91980 and 0.91250).
Timestamps spanning a US spring-forward DST gap and leap-day dates for timezone and calendar edge-case testing.
A sanitization-test CSV with one equals-prefixed cell clearly labelled sample-only. Use it to verify importers neutralize spreadsheet formulas, not an attack list.
A small CSV whose header row repeats the column name id: a common importer failure mode.
SKU identifiers that start with zeros. Spreadsheet tools often coerce these to numbers and drop the zeros. Keep them as text.
A CSV where missing values are written seven different ways (empty string, NULL, NA, N/A, null, None, and a dash) across text and numeric columns. A fixture for testing null-detection and coercion in CSV importers.
A CSV listing timestamps in eleven formats: ISO 8601 with Z and numeric offsets, millisecond precision, naive local, date-only, Unix epoch in seconds and milliseconds, US AM/PM, and RFC 1123. A fixture for testing date parsing and timezone normalisation.
A CSV whose 'value' column mixes integers, floats, scientific notation, dates, hex, thousands separators, and whitespace, and whose 'flag' column mixes a dozen boolean spellings. A torture test for type inference and schema detection.
A JSON object that repeats several member names (name, tags, timeout, active). RFC 8259 permits duplicate keys but leaves the result parser-defined: most keep the last. A fixture for testing how a JSON parser resolves duplicates.
A CSV with 1000 columns and a handful of rows: a stress test for parsers, spreadsheet importers, and databases with column limits or per-row buffering assumptions. Deterministic (fixed seed).
Attendance summary by course for Fieldnote Learning Centre. 3 courses and a TOTAL row. Attendance is uneven: 66.67 percent on Spreadsheet basics, 83.33 on Customer service and 100.00 on Workshop safety orientation, 83.33 overall. session_slots is enrolments times 2 on every row and sessions_attended plus absences equals it.
Bursary award register for Fieldnote Learning Centre. 4 awards worth 807.50. Three are a percentage of the fee and apply to every enrolment the learner holds; one is a fixed 120.00 award and applies to that learner's earliest enrolment only, capped at the fee. award_value is a rate for a percentage award and an amount for a fixed one, which is why the column mixes 0.5000 with 120.00.
Certificate eligibility with three conditions for Fieldnote Learning Centre. All 18 enrolments tested against three conditions: the enrolment is complete, the score reaches the pass mark, and both sessions were attended. 7 are eligible. 9 enrolments passed, so 2 passing learners are still ineligible on attendance alone: ENR-04 and ENR-11, each of whom attended 1 of 2 sessions. Every ineligible row names its reasons.
Course capacity and outcome report for Fieldnote Learning Centre. 3 courses, each seating 10 and holding 6 enrolments, so every course is at 60.00 percent with 4 seats free. pass_rate_of_completed divides passes by completions, not by enrolments, which is why COURSE-1 reports 60.00 percent from 3 passes out of 5 completions rather than out of 6 enrolments.
Course catalogue with materials for Fieldnote Learning Centre. 3 courses with their fee, capacity, pass score and the exercise material attached to each. material_characters is the exact length of the markdown exercise held against the course in the operating model, from 197 to 253 characters, so a content-length assertion has a real number to check.
Course fee schedule for Fieldnote Learning Centre. 3 courses with the fee broken into tuition, materials and a flat 25.00 registration charge. The three components add up to total_fee on every row: 300.00, 350.00 and 225.00. Every course runs 2 sessions, seats 10 and passes at 70.
Education reconciliation assertions for Fieldnote Learning Centre. The six identities this set claims with the figure each must produce: 5250.00 of gross fees, 4442.50 net of bursary, 9 passes, 7 certificates, 18 results in both gradebook shapes and 2600.00 of scheduled instalments. It also records both deliberate defects and their exact size.
Enrolment export for Fieldnote Learning Centre. 18 enrolments over 3 courses and 12 learners, 6 per course. 15 are complete and 9 passed. passed is true only where the enrolment is complete and the score reaches the pass score, which is why 2 rows carry a score at or above 70 and passed false: ENR-17 at 75 and ENR-18 at 82.
Enrolment export JSON for Fieldnote Learning Centre. The same 18 enrolments as enrolment-export.csv with the pass rule written out and a byCourse rollup. 9 of the 15 completed enrolments passed, a rate of 60.00 percent of completions.
Fee payment plan schedule for Fieldnote Learning Centre. 16 instalments across the 8 invoices whose net payable exceeds 250.00. Each is split into two equal instalments due 2026-08-31 and 2026-09-30; the first is paid and the second is still due. The instalments of an invoice always sum to its net_payable and the schedule totals 2600.00, which is the net payable of those 8 invoices and not of all 18.
Gradebook export, one row per result for Fieldnote Learning Centre. 18 results grouped by course, 6 per course. Scores run from 55 to 100 against a maximum of 100 and a pass score of 70. grade_band is derived from score and completion: 6 fail, 3 pass, 2 merit, 4 distinction and 3 incomplete. An incomplete enrolment gets no band even when its score would earn one.
Gradebook in wide format for Fieldnote Learning Centre. The same results as gradebook-export.csv pivoted to one row per learner and one column per course. 12 learners, 3 score columns and 18 empty cells where a learner is not enrolled on that course. An empty cell means no enrolment; it does not mean a score of zero, and treating it as zero destroys both best_score and the pass count.
Gradebook with an impossible score and a missing one for Fieldnote Learning Centre. The same 18 results as gradebook-export.csv with two cells changed. ENR-06 carries a score of 104 where the max_score column on the same row declares 100. ENR-12's score cell is empty while its passed column still reads true and its grade_band still reads distinction, so the file asserts a distinction it holds no score for.
Invoice register JSON for Fieldnote Learning Centre. The same 18 invoices as invoice-register.csv with the four rules that govern them written out, including the capping rule that keeps net_payable non-negative. totals.netPayable is 4442.50.
Invoice register where a bursary exceeds the fee it is set against for Fieldnote Learning Centre. The same 18 invoices, except that the award on ENR-03 was entered as 350.00 against a 225.00 fee. net_payable on that row reads -125.00, a negative amount, and the net column totals 4205.00 instead of 4442.50. The award is 125.00 larger than the fee it can be applied to.
Invoice register with bursaries for Fieldnote Learning Centre. 18 invoices, one per enrolment. tuition plus materials_fee plus registration_fee equals gross_fee, and gross_fee less bursary_amount equals net_payable, on every row. Gross totals 5250.00, bursaries 807.50 and net payable 4442.50. One invoice is reduced to 0.00 by a full bursary and no invoice is negative. payment_plan is true on the 8 invoices whose net exceeds 250.00.
Learner summary export for Fieldnote Learning Centre. 12 learners with their enrolments and fee position. Six learners hold 2 enrolments and six hold 1, 18 in total. gross_fees less bursary_total equals net_payable on every row and the columns total 5250.00, 807.50 and 4442.50. certificates_eligible sums to 7, not to the 9 passes.
Session attendance register for Fieldnote Learning Centre. 36 attendance records, 2 sessions for each of the 18 enrolments. 30 are present and 6 are absent, an attendance rate of 83.33 percent. Sessions run on 2026-08-10 and 2026-08-11 for every course, so the register has two dates and no others.
A .csv file whose content is tab-delimited. Tests whether importers sniff delimiters or trust the extension.
A CSV with # comment lines mixed among data: common in scientific exports; tests comment skipping.
A Latin-1 CSV with high-bit accented characters, for legacy 8-bit charset detection.
A CSV that mixes CRLF and LF row endings within one file: newline normalisation fixture.
A pipe-delimited (| ) tabular file, for testing non-comma delimiter autodetection.
A CSV with a quoted field that contains an embedded newline: a classic RFC 4180 parser stress case.
Rows with differing field counts, for testing how importers pad, truncate, or error on ragged CSV.
European-style CSV using semicolons as delimiters and comma decimals: a common locale edge case.
A Shift-JIS encoded Japanese CSV, for CJK charset detection and Shift-JIS→UTF-8 conversion in importers.
A one-column CSV of email addresses: edge case for delimiter sniffers that expect commas in every row.
UTF-16 big-endian CSV with BOM, for byte-order detection in tabular importers.
The same three data rows as UTF-16 little-endian with a BOM, wide-character CSV decoding fixture.
A CSV prefixed with a UTF-8 BOM (EF BB BF) and accented / CJK cells, for testing BOM-aware importers.
A CP1252 CSV using the 0x80–0x9F range (smart quotes, euro, bullet) that Latin-1 misreads.
A classic fixed-width text extract with documented column positions, for COBOL-style / mainframe importer tests.
A 1000-row orders dataset whose user_id references the users dataset: a relational fixture for testing joins and import flows. Paired with a JSON twin.
The 1000-row orders dataset as JSON: the format twin of the CSV version, relational to the users dataset.
A 500-row dataset of fake but realistic users (name, email, address, date of birth), generated with a fixed seed. Paired with a JSON twin.
The 500-row users dataset as a JSON array: the format twin of the CSV version, for testing import and conversion.
A well-formed Atom feed with multiple entries, for testing feed readers and parsers.
An HTTP Live Streaming (HLS) media playlist in UTF-8 M3U8 (#EXT-X-VERSION, target duration, four timed .ts segments, and #EXT-X-ENDLIST) for testing HLS parsers and adaptive-streaming players.
A JSON Feed 1.1 document (the JSON alternative to RSS/Atom) with a feed header and three items using content_html, content_text, tags, and publish dates, for testing JSON Feed parsers and readers.
An extended M3U media playlist with #EXTINF duration and title directives over three track references (local and remote), for testing playlist parsers and media players.
An OPML 2.0 subscription list with nested outline groups and three feed entries (title, xmlUrl, htmlUrl): the format RSS readers use to import and export subscriptions, for testing OPML parsers.
A well-formed RSS 2.0 feed with a channel and multiple items, for testing feed readers and parsers.
Synthetic finance dataset (ledger-lines) as CSV, for ETL and warehouse loader tests.
JSON twin of the finance/ledger-lines mini-dataset.
A year of daily OHLCV stock candles (open/high/low/close/volume) as a seeded random walk: a realistic finance time-series for testing charting, indicators, and importers. JSON twin included.
The daily OHLCV candles as a JSON array: the format twin of the CSV, for charting and time-series testing.
End-of-month account balance snapshot for open-banking API mock tests.
Synthetic bank statement line items for reconciliation tooling tests.
Balanced double-entry ledger SAMPLE for accounting engine validation tests.
Daily USD/EUR SAMPLE rates for FX chart and conversion tests.
Stripe-style payment intent SAMPLE JSON for checkout integration tests.
Synthetic suspicious-activity flag JSON for AML compliance workflow tests.
Synthetic bank transaction history for personal-finance importer tests.
A GeoJSON FeatureCollection with a point, a line, and a polygon, for testing map tools and geo importers.
A GPX track with timestamped trackpoints and elevation, for testing route parsers and mapping tools.
A KML document with named placemarks, for testing Google Earth / mapping importers.
The same 40 world cities as a GeoJSON FeatureCollection of Points (longitude, latitude order per RFC 7946), each with name, country, and population properties. The mapping twin of the CSV, for testing GeoJSON parsers and map renderers.
A curated world-cities dataset: 40 major cities with country, latitude, longitude, and population. A realistic geospatial fixture for testing map plots, geocoding, and CSV→GeoJSON conversion. GeoJSON twin included.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed service-dependency graph in GraphML: ten microservices (web, api, auth, db, cache, queue, worker, …) with their call/dependency edges. A fixture for testing directed-graph importers, cycle detection, and topological sorting.
The same 12-person social network in GEXF 1.3 (Gephi's native format): node attributes and weighted edges. The format twin of the GraphML file, for testing Gephi imports and GraphML↔GEXF conversion.
A small synthetic social network in GraphML: 12 people in two communities with a few bridging ties, carrying node attributes (name, age, community) and weighted edges. Twinned with a GEXF file for testing graph importers and format converters.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
Sample GraphQL Schema: small deterministic fixture for parsers and the in-browser editor.
A sample HL7 FHIR R4 bundle with a Patient plus vital-sign Observations, an Encounter, and a Condition: a realistic healthcare-interoperability fixture for testing FHIR parsers and mappers. Synthetic data, not a real person.
Synthetic FHIR Claim resource for healthcare billing parser tests, not a real patient.
Fictional insurance eligibility check response for prior-auth workflow tests.
Synthetic lab result rows for clinical data warehouse import tests.
Sample HL7 v2 ORM order message with PID and OBR segments: fictional patient and order ids.
Synthetic patient demographics CSV for EHR import and de-identification pipeline tests.
Synthetic e-prescription JSON for pharmacy routing and validation tests.
SAMPLE procedure code list with fees for medical billing calculator tests.
Claim adjustment reason codes for Juniper Fitness and Clinic Administration. The 5 adjustment codes the remittance uses, each with its group code and whether it is contractual, patient responsibility or another adjustment. The distinction matters: a CO adjustment can never be billed to the patient and a PR adjustment is exactly what is billed, so a reader that ignores the group code bills the wrong party.
Claim status register for Juniper Fitness and Clinic Administration. All 16 claims with the status code the 835 CLP02 carries, the payer control number and the 17 days between submission and payment. 1 claim is status 4, denied, and the rest are status 1, processed as primary. Every payer control number is unique and appears once in remittance-835.edi.
Denial register for Juniper Fitness and Clinic Administration. The single denied claim, CLM-0011, denied in full for 85.00 USD under CO 97 with a 90 day appeal deadline of 2026-12-24. The group code is CO, so the amount is a contractual write-off and must not be billed to the patient even though nothing was paid, which is exactly the case a reader gets wrong by assuming an unpaid claim becomes a patient balance.
Diagnosis code table for Juniper Fitness and Clinic Administration. The 3 diagnosis codes referenced by the claims, all of them administrative rather than clinical: a routine assessment, a follow-up and an equipment familiarisation visit. Every code is a synthetic placeholder and the table says so in its own column.
Encounter register for Juniper Fitness and Clinic Administration. 16 encounters, one for each confirmed booking in the appointment model. The two cancelled bookings are absent, so the register has 16 rows where the booking table has 18. Charges sum to 1,180.00 USD across 18 service lines, allowed to 876.00, and the payers paid 700.80 leaving 175.20 with patients.
Healthcare reconciliation identities for Juniper Fitness and Clinic Administration. 6 named identities covering the booking to claim mapping, both money splits, the 837 and 835 balance rules and the denial that is deliberately not a patient balance. The invalid 837 and its measured 20.00 USD difference are listed separately, with a flag recording that the file is structurally valid.
Patient roster for Juniper Fitness and Clinic Administration. The 16 patients, which are the fictional visitor names the appointment model already carries, joined to their booking, encounter, claim and payer. Every row carries the same synthetic date of birth of 1900-01-01 and a column that says so, because the X12 claim needs a demographic segment and this set will not hold a plausible personal record to fill it.
Payer fee schedule for Juniper Fitness and Clinic Administration. 12 rows, every procedure against every payer. All three payers use the same 80 percent allowed rate and the same 20 percent coinsurance, so the schedule is deliberately uniform and any difference a reader finds between payers in the remittance comes from adjudication rather than from pricing.
Payer roster for Juniper Fitness and Clinic Administration. The 3 payers with their claim counts and money. Claims sum to 16, charges to 1,180.00 USD, allowed to 876.00 and paid to 700.80, which are the same control totals the remittance and the reconciliation carry.
Procedure code table for Juniper Fitness and Clinic Administration. The 4 procedure codes this clinic bills, with the charge, the allowed amount at 80 percent of charge and the contractual adjustment that is the difference. The code_system column says on every row that these are synthetic placeholders in the five-character shape, not values from any real code set.
Provider roster for Juniper Fitness and Clinic Administration. The 3 providers with ten-digit identifiers in the national provider identifier shape. Each one carries a real modulo-10 check digit computed over the 80840 prefix and the nine-digit body, so a validator that implements the check digit rule accepts all of them, and the roster records that it did.
Receivable aging by payer for Juniper Fitness and Clinic Administration. The 3 payers plus a total row. On every row paid plus patient responsibility plus written off equals charged, and the three aging buckets sum to the outstanding column. Nothing is older than thirty days because every claim was paid 17 days after submission, so the whole 175.20 USD outstanding sits in the first bucket and is owed by patients rather than by payers.
Remittance adjustment lines for Juniper Fitness and Clinic Administration. 35 rows, one per adjustment rather than one per service line, because a paid service line carries two adjustments and a denied one carries a single CO 97. Grouping by adjustment group gives 304.00 USD of CO write-offs and 175.20 USD of PR patient responsibility. Summing the charged column instead double counts, because charged repeats on both adjustment rows of a paid line.
Service line detail for Juniper Fitness and Clinic Administration. All 18 service lines across the 16 encounters. Charges sum to 1,180.00 USD, which is the charge column of encounter-register.csv added, and grouping by claim_id reproduces every claim total exactly. This is the file the 837 service-line total has to agree with.
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.
X12 835 remittance rendered as JSON for Juniper Fitness and Clinic Administration. The same 3 payments and 16 claims as a JSON document with the adjustments as objects carrying their group and reason codes, so the contractual and patient-responsibility split is explicit rather than something a reader has to infer from a CAS segment position.
X12 837 batch rendered as JSON for Juniper Fitness and Clinic Administration. The same 16 claims as a JSON document, so a test can compare a parser output against an expected structure without reimplementing the X12 grammar. Control totals are hoisted to the document: 16 claims, 18 service lines and 1,180.00 USD.
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 envelope and delimiter specification for Juniper Fitness and Clinic Administration. The delimiters, envelope values and segment counts for every X12 file in this directory, including the invalid one, so a test harness can be configured from the fixture rather than by guessing. It also records that the usage indicator is T for test and that every patient carries the same synthetic date of birth.
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.
An employee directory: 30 staff with department, title, hire date, salary, and manager reference. Synthetic HR data for testing org-chart builders, directory imports, and payroll pipelines.
The employee directory as a JSON array: the format twin of the CSV, for HR import testing.
Synthetic hr dataset (employees-mini) as CSV, for ETL and warehouse loader tests.
JSON twin of the hr/employees-mini mini-dataset.
A monthly payroll summary derived from the employee directory: headcount, annual and monthly gross totals, and a per-department breakdown. A fixture for testing finance/HR dashboards and JSON aggregation.
Broker account statement for Pine Property Services. The broker side of the same premium: 7,630.00 USD of written premium, 12.5 percent commission of 953.75 USD, and 7,062.33 USD remitted to the insurer out of the 8,016.08 USD collected. Commission is charged on the subtotal only, not on the fees or the tax, which is why line 2 is not a percentage of line 5.
Certificate holder register for Pine Property Services. The 6 parties who require a certificate, each naming the endorsement that makes them an additional insured and the endorsement that waives subrogation. Every holder appears exactly once in certificate-of-insurance-register.csv.
Certificate of insurance register for Pine Property Services. 6 certificates, one per scheduled property, all issued 2026-09-08 against policy POL-2026-GL-0001 and all expiring 2027-03-31. days_until_expiry is 204 on every row, which is policy_end minus issue_date, and every row is positive because every certificate was issued while its cover was live.
Certificate register with a certificate that expired before it was issued for Pine Property Services. The same 6 valid rows with a seventh added: COI-2026-0007 is issued 2026-09-08 against a policy period that ended 2026-03-31, 161 days earlier, and its days_until_expiry cell reads -161. The row is internally consistent, so the arithmetic check passes and only the business rule that a certificate cannot be issued after its cover ends catches it. Its status still says in force.
Claim register for Pine Property Services. 3 claims against policy POL-2026-GL-0001, each joined to the work order and property the trades-property model holds. incurred_usd is paid_usd plus reserve_usd on every row; the three rows sum to 17,890.00 paid, 2,760.00 reserved and 20,650.00 incurred. One claim closed without payment because it was assessed below the 1,000.00 USD deductible.
Claim register JSON for Pine Property Services. The same 3 claims with the three column totals hoisted into a totals object, so a reader can check its own aggregation against the file rather than only against another file.
Claim settlement lines for Pine Property Services. The same seven lines as the settlement statement with the sign held in its own column rather than embedded in the amount, so amounts are all positive and a reader has to apply the sign to reproduce the running balance. Applying the signs in order reproduces every running value and ends at 17400.00.
Coverage limits for Pine Property Services. 6 coverage lines. Three of them carry an empty premium_usd because they are sub-limits of the general liability premium rather than separately rated, and the four rows that do carry a premium sum to the 7,040.00 USD base premium on the policy schedule.
Endorsement schedule for Pine Property Services. 4 endorsements with their effective dates and premiums. Two attach at inception and two mid-term, and the four premiums sum to 590.00 USD, the endorsement line of the premium breakdown. E01 and E02 are the two a certificate of insurance has to reflect, and the certificate register carries a column for each.
Insurance reconciliation identities for Pine Property Services. 6 named identities covering the premium chain, the instalment remainder, the apportioned insured values, the settlement calculation, the loss run and the broker account, with the figures behind each. The two deliberately invalid files and their measured 161 day gap are listed separately.
Loss run report for Pine Property Services. The policy-year loss run: 3 claims with a total row. Paid 17,890.00, reserved 2,760.00, incurred 20,650.00 USD against an earned premium of 3,344.66 USD at the 2026-09-08 snapshot, a loss ratio of 617.4 percent. Earned premium is the 7,630.00 USD subtotal, excluding fees and tax, for the 160 days of the 365 day policy period that have elapsed.
Premium breakdown for Pine Property Services. The full premium chain in 11 numbered lines, each stating the basis it is computed from, so every subtotal can be recomputed from the lines above it. Line 1 is 2700000.00 of insured value at 0.85 per 1000, which is 2295.00; line 11 is 8016.08 USD.
Premium instalment schedule for Pine Property Services. 5 instalments with a running balance that starts at 8,016.08 USD and reaches exactly 0.00 on the last row. The first 4 are 1603.22 and the last is 1603.20, because 8,016.08 divided by 5 does not land on a whole cent and the remainder is taken off the final instalment.
Schedule of insured locations for Pine Property Services. The 6 scheduled properties with their insured values and each one share of the 2,700,000.00 USD total. The share column is apportioned by largest remainder at four decimal places, so the six shares sum to exactly 100.0000 rather than to 100.0002, which is what rounding each share independently produces.
Schedule of insured vehicles for Pine Property Services. The 4 scheduled vehicles with the delivery route each is assigned to and a flat 620.00 USD premium each, which is the 2,480.00 USD commercial auto line on the policy schedule. The vehicle and route identifiers are the ones the inventory-manufacturing model holds.
Multi-level bill-of-materials SAMPLE for MRP and assembly planning tests.
Cycle-count variance SAMPLE for inventory audit reconciliation tests.
Synthetic purchase order JSON for procurement workflow tests.
Fictional SKU catalog for ERP and POS import tests.
Per-warehouse stock quantities for inventory reconciliation tests.
Warehouse and bin metadata for WMS routing tests.
A day of IoT sensor readings (temperature, humidity, pressure) at one-minute intervals from three sensors, with a realistic daily cycle plus noise, for testing time-series ingestion and downsampling. JSON twin included.
The IoT sensor readings as a JSON array: the format twin of the CSV, for time-series testing.
Synthetic iot dataset (sensor-readings-mini) as CSV, for ETL and warehouse loader tests.
JSON twin of the iot/sensor-readings-mini mini-dataset.
A deeply nested JSON document with objects inside arrays inside objects, for testing recursive parsing and path access.
A flat JSON array of ten simple objects: the baseline case for JSON parsing and mapping.
An intentionally invalid JSON file with a trailing comma and a missing closing brace, for testing parser error handling and messages. Not valid JSON by design.
A JSON Lines file with one object per line, for testing streaming/newline-delimited JSON parsers.
A draft-07 JSON Schema describing a user object, for testing schema validators and schema-aware tooling.
A newline-delimited JSON (NDJSON) stream of event records, for testing streaming JSON parsers.
Synthetic lab readings (temperature, pressure, pH) with ISO timestamps for scientific ETL tests. CSV twin.
Synthetic lab readings (temperature, pressure, pH) with ISO timestamps for scientific ETL tests. JSON twin.
A 50,000-row transactions dataset: an in-repo 'large' fixture for testing streaming CSV parsers, import performance, and pagination. Deterministic (fixed seed).
Bill of lading register for Pine Assembly Workshop. 4 bills of lading, one per delivery round, covering all 16 shipments and all 56 pieces. The piece counts are 8, 12, 16, 20 and they sum to 56, which is the parcels column of shipments-export.csv. Freight terms are prepaid on every round.
Carrier invoice whose fuel surcharge uses the wrong basis on one line for Pine Assembly Workshop. The 13 billable shipments with a TOTAL row. Every line is correct except SHIP-07, whose fuel_surcharge was computed on the weight charge alone: 53.68 times 0.065 gives 3.49 instead of 5.05 on the base plus weight charge. The line is 1.56 light and the TOTAL row reads 859.63 against the correct 861.19.
Carrier rate sheet for Pine Assembly Workshop. Two delivery zones. Zone A covers ROUTE-1 ROUTE-2 at 18.00 per stop plus 0.85 per kg; zone B covers ROUTE-3 ROUTE-4 at 24.00 per stop plus 1.10 per kg. A fuel surcharge of 0.065 applies to the base plus the weight charge, and every line rounds half up to cents.
Carrier rate sheet JSON for Pine Assembly Workshop. The same two zones as rate-sheet.csv with the rating formula written out as a string, including the fact that the fuel surcharge applies to the base charge as well as the weight charge. That basis is the one most often got wrong.
Customs commercial invoice lines for Pine Assembly Workshop. 4 invoice lines covering the 20 kits on BOL-2026-0004, all classified under HS 9403.30 with country of origin CA. amount_usd equals quantity times unit_price_usd on every line and the column sums to 1360.00; net weight sums to 226.880 kg and gross to 244.000 kg, the difference being the packaging.
Customs entry XML for Pine Assembly Workshop. An import entry for the BOL-2026-0004 consignment on a CIF basis. Goods 1360.00 plus freight 388.08 gives a customs value of 1748.08; duty at 0.025 is 43.70 and import tax at 0.050 on the customs value plus duty is 89.59, a total payable of 133.29. The statistical breakdown restates the 226.880 kg across the three component codes.
Delivery route plan and capacity for Pine Assembly Workshop. 4 rounds with 4 stops each. Parcels per round are 8, 12, 16, 20 against a vehicle capacity of 30 parcels, so capacity_used_percent runs from 26.67 to 66.67 and no round is over capacity. freight_charged_usd counts only delivered shipments and sums to 861.19.
EDI X12 856 advance ship notice for Pine Assembly Workshop. An ANSI X12 004010 transaction set 856 for bill of lading BOL-2026-0004: 35 segments from ISA to IEA, terminated with a tilde and CRLF as the format carries in practice. The hierarchy is one shipment level, 4 order levels and 4 item levels, so CTT declares 9 HL segments and SE declares 31 segments in the transaction set.
HS tariff code reference for Pine Assembly Workshop. Four tariff codes with duty rates and the unit of quantity each is measured in. Only 9403.30 is used on this entry, because the kit is presented complete but unassembled and is classified as the finished article; the three component codes are shipped so a classification test has a wrong-but-plausible alternative to reject.
Logistics reconciliation assertions for Pine Assembly Workshop. The six identities this set claims with the exact figure each must produce: 683.200 kg gross, 56 parcels, 56 cartons, 861.19 of billable freight and 133.29 of customs charges. It also records the size and cause of both deliberate defects.
Open delivery exceptions for Pine Assembly Workshop. 3 open exceptions, one for each shipment that has not been delivered. Between them they hold 12 parcels, which is exactly the difference between the 56 parcels shipped and the 44 delivered. Every resolution_target is two days after the raised_date.
Packing list by carton for Pine Assembly Workshop. 168 lines describing the contents of all 56 cartons: three part lines per carton, 4 LEG, 1 PANEL and 12 SCREW, which is the leaf level of the DESK bill of materials. The carton count equals the 56 parcels on shipments-export.csv and every carton weighs 12.200 kg gross.
Packing list whose carton count is short of the bill of lading for Pine Assembly Workshop. The same packing list as packing-list.csv with the 12 lines of the fourth carton on each BOL-2026-0003 consignment removed. It now describes 52 cartons where the register declares 56. BOL-2026-0003 accounts for 12 pieces against a declared 16.
Proof of delivery register for Pine Assembly Workshop. 13 delivery confirmations, one for each delivered shipment and none for the three still in transit. pieces_delivered equals pieces_expected on every row, so the register accounts for all 44 delivered parcels, and the exception_code column is empty throughout because no delivery was short or damaged.
Rated freight charges for Pine Assembly Workshop. 16 rated shipments. line_total equals base_charge plus weight_charge plus fuel_surcharge on every row, weight_charge equals gross_weight_kg times rate_per_kg rounded half up, and fuel_surcharge equals 0.065 of the two added together. The 13 billable rows total 861.19 and all 16 rows total 1093.24.
Shipment export CSV for Pine Assembly Workshop. 16 shipments over 4 delivery rounds, 13 delivered and 3 still in transit. Every parcel is one DESK kit at 12.200 kg gross, so gross_weight_kg is always parcels times 12.200. Parcels total 56 and delivered_parcels total 44; the in-transit rows report 0 delivered and an empty delivery_date.
Shipment export JSON for Pine Assembly Workshop. The same 16 shipments as shipments-export.csv with a totals object. totals.parcels is 56 and totals.grossWeightKg is 683.200, the sum of the per-shipment weights.
Shipment tracking event export for Pine Assembly Workshop. 74 scan events in chronological order per shipment: five for each of the 13 delivered shipments and three for each of the 3 still in transit, which never reach OUTFORDEL or DELIVERED. The DELIVERED timestamp on each shipment equals the delivered_time recorded for it on proof-of-delivery.csv.
Shipment tracking events as newline-delimited JSON for Pine Assembly Workshop. The same 74 scan events as tracking-events.csv, one JSON object per line with no enclosing array and no trailing comma. The file is not valid JSON as a whole and is not meant to be: each line is a complete document, which is what lets a consumer stream it without buffering the whole file.
Tracking events out of order with a duplicated delivery scan for Pine Assembly Workshop. The same events as tracking-events.csv written newest first rather than oldest first, with one extra row: the DELIVERED scan for SHIP-02 appears twice under two different scan_id values, SCN-00010 and SCN-00075, with identical shipment_id, event_code, date and time. The file has 75 rows against 74 distinct events.
Vehicle utilisation report for Pine Assembly Workshop. 4 vehicles, one per round. spare_capacity equals capacity_parcels minus parcels_carried on every row and is positive throughout, from 10 to 22 parcels. fuel_litres is the planned consumption for one run of the round and litres_per_parcel divides it by the parcels carried, rounded half up to three decimals.
An Apache access log in the Combined Log Format: the Common fields plus referer and user-agent. A realistic web-server log for testing access-log parsers, analytics, and grok patterns.
An Apache access log in the Common Log Format (CLF): client, timestamp, request line, status, and byte count. Deterministic, with reserved documentation IPs. Paired with a Combined-format twin for testing log parsers.
A Docker json-file container log: one JSON object per line with the log text, stream (stdout/stderr), and an RFC 3339 timestamp, exactly as Docker's default logging driver writes it. A fixture for container-log shippers and parsers.
A realistic Java stack trace: a Spring-style NullPointerException with a nested 'Caused by' chain and '... N more' elision. A fixture for testing stack-trace parsers, error groupers, and log viewers.
A structured application log with one JSON object per line at info/debug/warn/error levels, for testing log ingestion.
A Kubernetes-component log in the klog/glog format: a severity letter, timestamp, thread id, and source location prefix followed by the message. A fixture for testing klog parsers and severity extraction.
Tiny SAMPLE log excerpt (app-json-structured) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (cloudflare-ray-sample) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (multiline-stacktrace) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (nginx-access-sample) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (nginx-error-sample) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (systemd-journal-excerpt) for parser and alert-rule tests.
An nginx combined-format access log with several requests, including a 403 and a 404, for testing log parsers.
A realistic Node.js/Express stack trace, a TypeError with V8-style 'at function (file:line:col)' frames including an async frame and internal node: frames. A fixture for testing JS stack-trace parsers.
A realistic Python traceback with a chained exception ('During handling of the above exception...') and a caret error indicator. A fixture for testing traceback parsers and error-reporting tools.
A structured application log in logfmt, space-separated key=value pairs (ts, level, msg, method, path, status, duration, request_id) as used by many Go and Heroku-style services. A fixture for testing logfmt parsers.
A BSD-style syslog (RFC 3164) sample: timestamp, host, process and PID, then the message, across sshd, cron, kernel, nginx, and application entries. A fixture for testing syslog parsers and forwarders.
Attribute sampling plan for Pine Assembly Workshop. The sampling table the inspection used. The lot of 16 legs, being the quantity issued to BUILD-1 and BUILD-2 together, falls in the 16 to 25 band, which calls for a sample of 5 and an accept number of 0, and 5 is exactly the number of samples inspection-measurements.csv holds for each characteristic. With an accept number of 0 and 2 nonconforming readings, the lot is rejected on the plan and dealt with by nonconformance rather than by acceptance.
Bill of materials exploded for a production order for Pine Assembly Workshop. The same structure exploded for BUILD-1, an order for 2 DESK. Extended quantity is quantity per parent times parent quantity on every row, and the leaf totals of 8 LEG, 2 PANEL and 24 SCREW equal the material requirements the inventory-manufacturing model already holds for that order, which the model_requirement column repeats on each leaf row for comparison.
Bill of materials JSON for Pine Assembly Workshop. The DESK structure as a flat array with level, parent and both quantities, plus the cost identity at the top: 25.20 USD of leaf material plus 14.80 USD of added value is the 40.00 USD standard cost the parts table holds. A reader can rebuild the tree from parent and component without needing the indent string the CSV carries.
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.
Certificate of conformance register for Pine Assembly Workshop. Two certificates against the same lot and the same inspection report, one per production order. The first discloses 2 nonconformances and the second none, because the nonconforming legs were consumed by the replacement on the first order and the second order drew clean stock from the same lot.
Exploded bill of materials whose sub-assembly quantities do not roll up for Pine Assembly Workshop. The same 6 rows with one number changed: the SCREW line under BASE carries an extended quantity of 12 instead of 16. That row now says 8 per parent times 2 parents is 12, which is arithmetically false, and the SCREW leaf total falls to 20 against the 24 the model_requirement_component_total column on the same rows still declares. The shortfall is 4 screws, 0.40 USD of material, and it is enough to leave one BASE sub-assembly short at build time.
First article inspection for Pine Assembly Workshop. The first article record for LEG against DRW-LEG-002 revision C: all 5 characteristics measured and passed before the run started. The readings are the fourth sample from the production inspection, which is deliberate: the first article passes on every characteristic while the production lot later fails on two, so the pair shows that a clean first article does not guarantee a clean run.
Gauge calibration register for Pine Assembly Workshop. The 5 gauges used on this inspection, each with its calibration certificate, the date it was calibrated and the date it falls due. All 5 were inside calibration on 2026-09-10, the inspection date, and the used_for column names the characteristics each one measured, so every characteristic can be traced to a gauge and every gauge to a certificate.
Indented bill of materials for Pine Assembly Workshop. The DESK structure exploded to 2 levels in 6 rows, with an indent column so the tree is readable and an is_assembly flag so leaves can be told from sub-assemblies. Per finished unit the leaves are 4 LEG, 1 PANEL and 12 SCREW, which cost 25.20 USD. The 35.00 USD of sub-assembly rows is the same material counted again at a higher level and must not be added to it.
Inspection characteristics and tolerances for Pine Assembly Workshop. The 5 characteristics taken from DRW-LEG-002 revision C, with the nominal, both tolerances and the resulting limits. Four are bilateral and one, surface roughness, is unilateral with a lower tolerance of zero, so its lower limit equals its nominal and a reader that assumes symmetry computes a limit that does not exist.
Inspection measurements with tolerances for Pine Assembly Workshop. 25 readings, 5 samples across 5 characteristics of the LEG part. Deviation is measured less nominal and carries an explicit sign, and result is pass only when the reading lies between both limits inclusive. 2 readings fail: CH-3 sample 3 measured 25.41, above the upper limit of 25.300 by 0.110; CH-5 sample 5 measured 1.58, below the lower limit of 1.600 by 0.020.
Inspection summary for Pine Assembly Workshop. One row per characteristic with the pass count, the observed minimum and maximum and the range. 3 characteristics pass every sample and 2 do not. The range column is observed spread and not tolerance, so a characteristic can have a small range and still fail if the whole sample sits off nominal.
Lot genealogy for Pine Assembly Workshop. The chain from purchase to certificate for lot LOT-2026-0912 in 7 records, each naming its parent record and the file that evidences it. Every evidence value that names a file names one that exists in this directory, so the genealogy is walkable rather than decorative.
Manufacturing and quality reconciliation identities for Pine Assembly Workshop. 6 named identities covering the explosion, the cost roll-up, the work order that closes to standard, the routing, the inspection rule including the unilateral tolerance, and the difference between component scrap and finished-goods yield. The deliberate defect and its 4 unit, 0.40 USD shortfall are listed separately.
Material issue list for Pine Assembly Workshop. The 3 leaf components issued to BUILD-1, at the quantities the explosion reaches and the model requires. Issued value is 50.40 USD, which is exactly line 1 of work-order-cost.csv, so the issue list and the cost build-up close on each other. No sub-assembly appears, because BASE and TOP are made on this order rather than issued to it.
Nonconformance register for Pine Assembly Workshop. 2 nonconformances, one per failing reading, each naming the characteristic, the limit breached and the amount by which it is breached. Both are single legs, 6.00 USD of material in total, so the 80.00 USD work order is not materially affected and the closed_on column is empty because neither is closed at the snapshot.
Standard cost roll-up for Pine Assembly Workshop. Every part with its material cost from the level below, the added value on top and the standard cost the parts table holds. On every row material plus added value equals standard cost. The DESK row takes its material from the two sub-assemblies at their standard costs, 35.00 USD, not from the leaves; the leaves come to 25.20 USD, and the difference is the added value already absorbed into the sub-assemblies.
Work order cost build-up for Pine Assembly Workshop. The seven line cost of BUILD-1: 50.40 USD of material, 18.50 of labour and 11.10 of absorbed overhead, giving 80.00 USD against a standard cost of 80.00 USD for the output and a variance of 0.00. The order closes exactly to standard, which is deliberate: it makes any variance a reader computes a defect in their arithmetic rather than a property of the fixture.
Work order register for Pine Assembly Workshop. The 4 production orders the model holds, all for 2 DESK each, costed through the same routing. Every order closes to standard with a zero variance because setup is the same and the quantity is the same on all four; a different order quantity would produce a variance, which is why the batch size is a column rather than an assumption.
Work order routing for Pine Assembly Workshop. The 5 operations for BUILD-1, each with a setup time charged once per order and a run time charged per unit. At an order quantity of 2 the total is 10 setup minutes plus 20 run minutes, 30 in all, which at 37.00 USD an hour is 18.50 USD of labour. Treating setup as a per-unit time instead would give 40 minutes and 24.67 USD.
Yield and scrap for Pine Assembly Workshop. Yield by production order. Every order yields 2 good units for 2 ordered, so finished-goods yield is 100.00 percent on all four, while BUILD-1 scrapped 2 legs worth 6.00 USD at component level. The two measures are in separate columns on purpose: component scrap that is replaced before assembly does not reduce finished-goods yield, and reporting one as the other is the mistake this file exists to catch.
Synthetic multi-touch attribution click rows with UTM fields, for marketing analytics importers. CSV twin.
Synthetic multi-touch attribution click rows with UTM fields, for marketing analytics importers. JSON twin.
Campaign summary against goal for Willow Community Fund. 3 campaigns and a TOTAL row. total_raised is donations received plus grants awarded and deliberately excludes the 1050.00 of pledges still outstanding, which sit in their own column. Against 12500.00 of goals, 6300.00 has been raised, 50.40 percent, ranging from 16.88 percent on Library corner to 88.57 percent on Workshop supplies.
Donation receipts JSON for Willow Community Fund. The same 9 receipts as donation-receipts.csv with the receipt rule written out. totals.deductible is 1669.50, which is 1800.00 of gifts less 130.50 of benefits.
Donation receipts that treat a quid pro quo gift as fully deductible for Willow Community Fund. The same 9 receipts, but on the 6 rows with a benefit the deductible_amount was copied from gross_amount while value_of_benefits and benefit_description were left correct. The deductible column totals 1800.00 against the correct 1669.50, overstating the deductible amount by 130.50, which is precisely the value of benefits the same file reports.
Donation receipts with benefit split for Willow Community Fund. 9 receipts for the gifts actually received. 3 are pure gifts where deductible_amount equals gross_amount; 6 were made at a fundraising event and carry a benefit, so their deductible_amount is the gross less the fair market value of what the supporter received. Gross totals 1800.00, benefits 130.50 and deductible 1669.50. Getting this split wrong is the single most common error on a charitable receipt.
Donor summary export for Willow Community Fund. 8 supporters with their year-to-date position. pledged_total equals received_total plus outstanding_total on every row, and received_total less value_of_benefits equals deductible_total. The columns total 2850.00 pledged, 1800.00 received, 130.50 of benefits and 1669.50 deductible.
Donor summary export JSON for Willow Community Fund. The same 8 supporters as donor-export.csv, with a privacy note recording that the export deliberately carries no contact or payment data. totals.deductible is 1669.50.
Fair market value of donor benefits for Willow Community Fund. The 2 goods and services supporters received in return for a gift, with the fair market value used to reduce the deductible amount on their receipt: Workshop lunch at 18.00 on 6 receipts and Garden tote bag at 7.50 on 3. No de minimis exception is applied: every benefit is deducted, however small.
Fund balance roll-forward by restriction class for Willow Community Fund. The same money as restricted-funds-report.csv collapsed to two restriction classes and a TOTAL row. Nothing was released from restriction in the period, so the unrestricted class does not move: it opens and closes at 1200.00. The restricted class opens at 0.00, receives 6300.00, spends 4395.25 and closes at 1904.75.
Fundraising event attendance for Willow Community Fund. 4 events with attendance against a 30-person capacity, the volunteer effort behind each and the gifts received at it. Attendance runs 60.00 to 80.00 percent of capacity, no event is oversubscribed, and the benefits_given column totals 130.50, exactly the value of benefits deducted on the receipts.
Grant budget against actual for Willow Community Fund. 10 rows: four budget lines and a Grant total for each of the 2 awarded grants. Each grant's budget lines sum to the amount awarded, 2000.00 and 2500.00, and actual spend of 4395.25 leaves 104.75 unspent. Two lines are overspent and carry a negative variance; the grant totals are still positive, which is how an overspend hides inside a grant that looks fine.
Grant register for Willow Community Fund. 3 grant applications, one per campaign. 2 were awarded in full and total 4500.00; the third is still pending and carries an awarded amount of 0.00 with no award date and no report date. Requested totals 7500.00, so 3000.00 of the ask is still undecided.
In-kind gift register for Willow Community Fund. 3 gifts of goods and services valued at 285.00 in total, each with the basis its value was arrived at. counted_as_cash is false on every row and no in-kind gift appears in restricted-funds-report.csv, donation-receipts.csv or campaign-summary.csv. That separation is the point of the file.
Nonprofit reconciliation assertions for Willow Community Fund. The seven identities this set claims with the figure each must produce: 1669.50 of deductible giving, 2850.00 of scheduled pledges, 1050.00 outstanding, 4500.00 of grants, 3104.75 of closing funds, 6300.00 raised and 285.00 of in-kind value that touches no cash total. It also records the 130.50 size of the deliberate defect.
Pledge aging at 2026-09-08 for Willow Community Fund. The 9 unpaid instalments bucketed by how overdue they are at the 2026-09-08 snapshot. Each of the three outstanding pledges has one instalment in each of the 1-30, 31-60 and 61-90 buckets, so the buckets hold 350.02, 349.99, 349.99 and total 1050.00. The bucket amounts are not round numbers because the instalment rounding put an extra cent in the youngest bucket.
Pledge instalment schedule for Willow Community Fund. 18 instalments across 12 pledges. The 9 settled pledges are single paid instalments; the 3 outstanding pledges are split into three monthly instalments due 2026-06-30, 2026-07-31, 2026-08-31. The instalments of a pledge always sum to its pledge_total: 325.00 splits 108.33, 108.33 and 108.34, so the final instalment absorbs the rounding. The schedule totals 2850.00 and the unpaid part is 1050.00.
Restricted and unrestricted fund report for Willow Community Fund. 4 funds and a TOTAL row. The general fund carries 1200.00 without donor restrictions and moves not at all in the period; the 3 campaign funds are restricted and receive 1800.00 of donations and 4500.00 of grants. Every row satisfies opening + receipts - expenditure = closing, and the funds close at 3104.75, of which 1904.75 is restricted.
Restricted fund report JSON for Willow Community Fund. The same 4 funds as restricted-funds-report.csv with the balancing rule stated and the closing balance split by restriction: 1904.75 with donor restrictions and 1200.00 without.
Volunteer hours by person for Willow Community Fund. 8 volunteers with 47 hours across 16 shifts at 4 events. Every volunteer worked exactly 2 shifts. Volunteer time is recorded in hours and is never valued in money anywhere in this set, which is deliberate: donated time is not a cash receipt and must not reach the fund report.
A valid Jupyter notebook (nbformat 4.5) with markdown cells, code cells, and real outputs (stdout stream and an execute result), for testing notebook parsers, nbconvert, and JSON tooling.
The exact answer for the blur variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the lowcontrast variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot-7 variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot+3 variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the noise variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the clean variant of this delivery: every one of the 29 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the blur variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the lowcontrast variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot-7 variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot+3 variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the noise variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the clean variant of this invoice: every one of the 33 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the blur variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the lowcontrast variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot-7 variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the rot+3 variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the noise variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
The exact answer for the clean variant of this receipt: every one of the 23 words with its string and pixel box, plus the transform that produced this variant. Authored before the image existed, so it is ground truth by construction rather than a second opinion.
Where the original view of head and shoulders portrait of an older white woman with short grey hair, plain cream background landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of an east asian woman with glasses, plain warm grey background landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of a bearded white man in his thirties, plain olive studio background landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of a south asian man in his fifties, plain slate studio background landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of a smiling white woman against a plain blue studio background landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of a young hijabi woman against a plain neutral studio background landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of head and shoulders portrait of an older east asian man against a plain warm studio background landed inside the expanded frame, as JSON: the rectangle 64,32 to 576,544 in a 768x640 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of abstract album cover artwork, bold overlapping colour shapes, grainy print texture landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of retro album cover artwork, sunset gradient and geometric lines, 1980s print feel landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of book cover artwork, weathered antique map and brass instruments on wood landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of book cover artwork, misty mountain ridge at dawn, layered depth, serene landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a delivery note on a clipboard held against a van door, outdoor overcast light, slight angle landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a printed invoice on a wooden desk beside a calculator and a pen, flat lay, soft daylight landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a restaurant menu card standing on a laid table, cutlery and glassware, warm evening light landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a scatter of crumpled paper receipts on a kitchen table, overhead view, harsh afternoon sun and hard shadows landed inside the expanded frame, as JSON: the rectangle 64,32 to 576,544 in a 768x640 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of rustic sourdough loaves on a wooden board, flour dust, warm bakery light landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of close up of coffee being poured into a white cup, steam, cafe counter, shallow depth landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of overhead plate of fresh pasta with herbs on a linen cloth, natural window light landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of overhead colourful garden salad in a ceramic bowl, marble surface, soft daylight landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of stylised fantasy mage character render, full body, neutral grey backdrop landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of fantasy video game environment, stone keep on a cliff at sunset landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of isometric stylised village diorama, soft shading, mobile style landed inside the expanded frame, as JSON: the rectangle 64,32 to 576,544 in a 768x640 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of colourful stylised platformer level, floating islands, bright palette landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a printed invoice on a wooden desk beside a calculator and a pen, flat lay, soft daylight landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of path through a deciduous forest, dappled sunlight, receding depth landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of modern minimalist living room interior, large windows, natural daylight landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of an open paper accounts ledger with ruled columns on a desk, fountain pen resting on the page, window light landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of small garden birds on a wooden feeder, natural daylight landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of tabby cat sitting on a windowsill, natural backlight, indoor landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of brown horse standing in a field, overcast daylight landed inside the expanded frame, as JSON: the rectangle 64,32 to 576,544 in a 768x640 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a market stall vendor arranging fresh vegetables on his stall, outdoor daylight, crates and price cards, documentary landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of middle aged indian man accountant at a desk with paper ledgers and a calculator, desk lamp landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of wheelchair user chef at a lowered prep counter slicing vegetables, professional kitchen landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a delivery driver with a parcel and a handheld scanner at a residential door, early evening light, van blurred behind landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of older white man farmer crouching in a vegetable field holding produce, overcast daylight landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a Black man in his seventies with grey hair arranging vegetables at an outdoor market stall, overcast daylight, crates and handwritten price cards landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a Black woman hairdresser in her forties in a bright salon, mirrors and styling chairs behind, professional, looking at camera landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a South Asian woman electrician in work clothes and safety glasses checking a consumer unit, domestic hallway, tool bag open, natural light landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of glass water bottle on a plain white studio background, soft light landed inside the expanded frame, as JSON: the rectangle 64,32 to 576,544 in a 768x640 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of potted houseplant on a plain neutral background, soft daylight landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of single running shoe on a plain white studio background, soft light landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of the exterior of a small independent bakery on a quiet street, awning and window display, morning light landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of empty cafe interior before opening, chairs down, morning sun across tables landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a cluttered joinery workshop bench with hand tools and sawdust, window light from the left landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of person lifting weights in a gym, indoor lighting landed inside the expanded frame, as JSON: the rectangle 192,0 to 704,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of abstract warm bokeh lights out of focus, dark background landed inside the expanded frame, as JSON: the rectangle 0,192 to 512,704 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of flat red brick wall landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 512x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of close up woven linen fabric texture, natural fibres landed inside the expanded frame, as JSON: the rectangle 96,96 to 608,608 in a 704x704 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of sports motorcycle parked at a kerb, sunny day landed inside the expanded frame, as JSON: the rectangle 128,0 to 640,512 in a 768x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of green farm tractor in a field, blue sky landed inside the expanded frame, as JSON: the rectangle 0,128 to 512,640 in a 512x768 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Where the original view of a warehouse worker holding a clipboard beside tall racking, high bay lighting, boxes on pallets landed inside the expanded frame, as JSON: the rectangle 0,0 to 512,512 in a 704x512 canvas, the padding that produced it, and the 40-pixel feather that means the comparison must be inset. Authored BEFORE the expansion ran, so it is ground truth rather than a rectangle recovered afterwards by matching the original against the result - which is what a consumer would otherwise have to do, and which cannot distinguish a correct offset from a plausible one.
Binary orc source for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-source.
Csv semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-csv.
Json semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-json.
Valid Protobuf wire record with string, uint32, and string fields for schema-guided decoding. Stable P8 artifact p8-convert-protobuf-source.
Expected JSON semantic result for the schema-guided Protobuf decode. Stable P8 artifact p8-convert-protobuf-expected.
Valid wire bytes intentionally supplied without a matching schema so tools must preserve unknown field 15. Stable P8 artifact p8-convert-protobuf-missing-schema.
Proto3 schema companion declaring the three fields used by the binary creator record. Stable P8 artifact p8-convert-protobuf-schema.
Bank payment file for Cobalt Operations Team. 8 payments, one per employee, for the net pay on payroll-register.csv. The amount column totals 6649.44, which is the net_pay total of the register to the cent. Sort code and account numbers are reserved test values and the reference on every line names the employee and the period.
Benefit deduction schedule for Cobalt Operations Team. 8 employees and a TOTAL row. Every employee is on the STD plan from 2026-01-01, contributing 42.00 against an employer contribution of 63.00, so employee contributions total 336.00, employer contributions 504.00 and premiums 840.00. Only the employee side reaches the payroll register; the employer side is a cost, not a deduction.
Benefit deduction schedule JSON for Cobalt Operations Team. The same 8 enrolments as benefits-deduction-schedule.csv with the rule that separates a deduction from an employer cost stated in words. totalPremiums is 840.00, of which only 336.00 is deducted from pay.
Benefit plan rate card for Cobalt Operations Team. Two health plans. STD costs 105.00 a period of which the employer pays 63.00, 60.00 percent, and all 8 employees are on it. ENH is defined at 174.00 with nobody enrolled, so it is the negative case: a plan that exists in the rate card and must never appear in a deduction.
COBOL copybook for the payment file for Cobalt Operations Team. A COBOL record description for the same 105-character layout, with PIC clauses matching bank-payment-layout.json field for field: X(n) for the alphanumeric fields and 9(9)V99 for the amount, which is where the two implied decimal places are declared. Comment lines carry the column ranges.
Employee directory for Cobalt Operations Team. 8 employees with department, pay basis, rate and start date. The names are the model's own role labels, not people, and the directory carries no address, telephone number, date of birth or national identifier. The bank fields are reserved test values: sort code 000000 and sequential account numbers from 00000001 to 00000008, flagged as such in the last column.
Employee directory JSON for Cobalt Operations Team. The same 8 employees as employee-directory.csv with a department count and a privacy note. The team splits 4 in Operations, 4 in Service.
Employer cost summary for Cobalt Operations Team. What the period actually costs the employer: 9072.00 of gross pay plus 272.16 of employer pension, 694.01 of payroll tax and 504.00 of health contribution, 10542.17 in total, which is 116.21 percent of gross and 31.38 per paid hour. None of it is deducted from pay: employees receive 6649.44.
Fixed-width bank payment file for Cobalt Operations Team. 8 records of exactly 105 characters each, the shape a bank credit-transfer file still arrives in. There is no delimiter and no header. Amounts are unsigned cents, zero filled and right justified in an 11-character field, so 604.80 is written as 00000060480. The column map is bank-payment-layout.json.
Fixed-width payment file column map for Cobalt Operations Team. The documented column map for bank-payment-fixed-width.txt: 9 fields with 1-based start, length, end and type, tiling the 105-character record with no gap and no overlap. It also carries the control totals a bank file is checked against: 8 records and 664944 cents.
Leave balances for Cobalt Operations Team. 8 employees and a TOTAL row. remaining_hours is entitlement less taken less approved future leave, and deliberately does not subtract pending requests: 16 hours are awaiting approval and are reported in their own column. Across the team 96 hours have been taken, 16 are approved for the future and 1168 of 1280 remain. remaining_days converts at 8 hours a day.
Leave request register for Cobalt Operations Team. 4 requests of 8 hours each, all for dates after the pay period. 2 are approved and count against the balance; 2 are pending and do not. counts_against_balance is derived from status and never disagrees with it.
Paid hours by shift for Cobalt Operations Team. 48 shifts over 2026-08-10 to 2026-08-15, 6 for each of the 8 employees. base_pay equals paid_hours times hourly_rate on every shift, hours total 336 and base pay totals 9072.00, which is the gross_pay column of payroll-register.csv. No shift exceeds standard hours, which is why no overtime element appears anywhere.
Pay element code list for Cobalt Operations Team. 8 pay elements split into earnings, employee deductions and employer costs, each with the basis it is calculated on, its rate and the general ledger account it posts to. Overtime is defined but carries used_this_period false because no shift in the period exceeded standard hours. The 7 used elements are exactly the lines that appear on the payslips and in the payroll journal.
Payroll journal batch for Cobalt Operations Team. 9 double-entry lines and a batch total. Debits are the four expense accounts totalling 10542.17; credits are the five payable accounts totalling the same 10542.17, so the batch balances exactly. The net pay payable credit of 6649.44 is the bank payment file, and the pension and health payables carry both the employee deduction and the employer contribution, which is why they exceed the deduction figures on the register.
Payroll journal batch JSON for Cobalt Operations Team. The same 9 lines as payroll-journal.csv with the posting rule stated. totals.debit and totals.credit are both 10542.17 and totals.difference is 0.00.
Payroll reconciliation assertions for Cobalt Operations Team. The eight identities this set claims with the figure each must produce: 9072.00 of gross from the shifts, 6649.44 of net after deductions, the same figure on the payslips and in the bank file, 664944 cents as the fixed-width control total, a journal balancing at 10542.17, 1470.17 of employer cost that is never a deduction, and 1168 hours of leave remaining. It also records the 58.80 size of the deliberate defect.
Payroll register for Cobalt Operations Team. 8 employees and a TOTAL row for the 2026-08-10 to 2026-08-15 period paid on 2026-08-21. gross_pay equals hours times hourly_rate, income_tax is 0.18 of gross, pension_employee is 0.05 of gross and health_benefit is a flat 42.00. total_deductions is the three added together and net_pay is gross less deductions, on every row. Gross totals 9072.00, deductions 2422.56 and net 6649.44.
Payroll register JSON for Cobalt Operations Team. The same 8 employees as payroll-register.csv with the rates and the balancing rule written out. totals.net is 6649.44 and equals totals.gross less totals.totalDeductions, 9072.00 less 2422.56.
Payroll register whose deductions do not reconcile to net pay for Cobalt Operations Team. The same 8 employees as payroll-register.csv except that net_pay for EMP-05 was computed before the pension deduction was applied. That row reads gross 1176.00, total_deductions 312.48 and net_pay 922.32, which is 58.80 more than gross less deductions. The TOTAL row was updated to match the column, so it reads 6708.24 against the correct 6649.44, and the file is internally consistent column-wise while being wrong row-wise.
Payslip lines for every employee for Cobalt Operations Team. 32 lines, 4 per payslip: one earning and three deductions. Deductions are written as negative amounts rather than as positive amounts in a deduction column, so the amount column sums straight to net pay: 6649.44 across all 8 payslips. Each payslip's lines sum to that employee's net_pay on payroll-register.csv.
Year to date earnings for Cobalt Operations Team. Cumulative earnings over 5 identical periods, this one and 4 earlier ones on the same hours and rates. Every figure is exactly 5 times the corresponding period figure, so ytd_gross totals 45360.00, ytd_deductions 12112.80 and ytd_net 33247.20. The period-level identity survives: gross less deductions equals net on every row.
A point-of-sale SKU catalog with tax codes and active flags: fictional Meridian Supply inventory. CSV twin.
A point-of-sale SKU catalog with tax codes and active flags: fictional Meridian Supply inventory. JSON twin.
Credit note lines CSV for Alder Table Bistro. 2 credit lines, one per note. CN-BST-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-BST-7002 credits 5 units where GRN-BST-2004 records only 3 returned, an overstatement of 15.58 CAD net.
Goods-received note lines CSV for Alder Table Bistro. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-BST-2002, an item substitution on GRN-BST-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-BST-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Alder Table Bistro. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-BST-1002 totals 329.53 CAD including GST.
Remittance advice lines CSV for Alder Table Bistro. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 1120.68 CAD is settled and 1765.18 CAD is withheld against statement balances of 2885.86 CAD; the first two figures sum to the third.
Statements of account CSV for Alder Table Bistro. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-BST-6001 closes at 1326.11 CAD and its four declared ageing buckets sum to exactly that. STM-BST-6002 closes at 1559.75 CAD while its declared buckets sum to 1566.76 CAD.
Supplier invoice lines CSV for Alder Table Bistro. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-BST-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-BST-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Alder Table Bistro. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Alder Table Bistro. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Alder Table Bistro. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Alder Table Bistro. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Cedar Street Tacos. 2 credit lines, one per note. CN-TRK-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-TRK-7002 credits 5 units where GRN-TRK-2004 records only 3 returned, an overstatement of 0.42 CAD net.
Goods-received note lines CSV for Cedar Street Tacos. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-TRK-2002, an item substitution on GRN-TRK-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-TRK-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Cedar Street Tacos. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-TRK-1002 totals 104.33 CAD including GST.
Remittance advice lines CSV for Cedar Street Tacos. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 635.20 CAD is settled and 384.78 CAD is withheld against statement balances of 1019.98 CAD; the first two figures sum to the third.
Statements of account CSV for Cedar Street Tacos. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-TRK-6001 closes at 547.74 CAD and its four declared ageing buckets sum to exactly that. STM-TRK-6002 closes at 472.24 CAD while its declared buckets sum to 481.61 CAD.
Supplier invoice lines CSV for Cedar Street Tacos. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-TRK-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-TRK-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Cedar Street Tacos. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Cedar Street Tacos. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Cedar Street Tacos. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Cedar Street Tacos. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Copper Oven Bakery. 2 credit lines, one per note. CN-BAK-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-BAK-7002 credits 5 units where GRN-BAK-2004 records only 3 returned, an overstatement of 9.88 CAD net.
Goods-received note lines CSV for Copper Oven Bakery. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-BAK-2002, an item substitution on GRN-BAK-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-BAK-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Copper Oven Bakery. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-BAK-1002 totals 289.65 CAD including GST.
Remittance advice lines CSV for Copper Oven Bakery. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 946.62 CAD is settled and 1189.60 CAD is withheld against statement balances of 2136.22 CAD; the first two figures sum to the third.
Statements of account CSV for Copper Oven Bakery. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-BAK-6001 closes at 740.74 CAD and its four declared ageing buckets sum to exactly that. STM-BAK-6002 closes at 1395.48 CAD while its declared buckets sum to 1396.87 CAD.
Supplier invoice lines CSV for Copper Oven Bakery. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-BAK-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-BAK-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Copper Oven Bakery. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Copper Oven Bakery. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Copper Oven Bakery. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Copper Oven Bakery. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Ember Lane Pizza. 2 credit lines, one per note. CN-PIZ-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-PIZ-7002 credits 5 units where GRN-PIZ-2004 records only 3 returned, an overstatement of 1.04 CAD net.
Goods-received note lines CSV for Ember Lane Pizza. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-PIZ-2002, an item substitution on GRN-PIZ-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-PIZ-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Ember Lane Pizza. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-PIZ-1002 totals 468.93 CAD including GST.
Remittance advice lines CSV for Ember Lane Pizza. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 1450.33 CAD is settled and 1823.85 CAD is withheld against statement balances of 3274.18 CAD; the first two figures sum to the third.
Statements of account CSV for Ember Lane Pizza. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-PIZ-6001 closes at 1107.20 CAD and its four declared ageing buckets sum to exactly that. STM-PIZ-6002 closes at 2166.98 CAD while its declared buckets sum to 2177.90 CAD.
Supplier invoice lines CSV for Ember Lane Pizza. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-PIZ-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-PIZ-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Ember Lane Pizza. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Ember Lane Pizza. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Ember Lane Pizza. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Ember Lane Pizza. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Harbour Kitchen Group. 2 credit lines, one per note. CN-GRP-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-GRP-7002 credits 5 units where GRN-GRP-2004 records only 3 returned, an overstatement of 3.80 CAD net.
Goods-received note lines CSV for Harbour Kitchen Group. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-GRP-2002, an item substitution on GRN-GRP-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-GRP-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Harbour Kitchen Group. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-GRP-1002 totals 325.41 CAD including GST.
Remittance advice lines CSV for Harbour Kitchen Group. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 1041.96 CAD is settled and 1608.28 CAD is withheld against statement balances of 2650.24 CAD; the first two figures sum to the third.
Statements of account CSV for Harbour Kitchen Group. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-GRP-6001 closes at 1317.12 CAD and its four declared ageing buckets sum to exactly that. STM-GRP-6002 closes at 1333.12 CAD while its declared buckets sum to 1342.11 CAD.
Supplier invoice lines CSV for Harbour Kitchen Group. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-GRP-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-GRP-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Harbour Kitchen Group. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Harbour Kitchen Group. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Harbour Kitchen Group. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Harbour Kitchen Group. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Juniper Corner Cafe. 2 credit lines, one per note. CN-CAF-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-CAF-7002 credits 5 units where GRN-CAF-2004 records only 3 returned, an overstatement of 3.04 CAD net.
Goods-received note lines CSV for Juniper Corner Cafe. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-CAF-2002, an item substitution on GRN-CAF-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-CAF-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Juniper Corner Cafe. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-CAF-1002 totals 348.83 CAD including GST.
Remittance advice lines CSV for Juniper Corner Cafe. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 1235.99 CAD is settled and 1940.07 CAD is withheld against statement balances of 3176.06 CAD; the first two figures sum to the third.
Statements of account CSV for Juniper Corner Cafe. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-CAF-6001 closes at 1726.12 CAD and its four declared ageing buckets sum to exactly that. STM-CAF-6002 closes at 1449.94 CAD while its declared buckets sum to 1460.86 CAD.
Supplier invoice lines CSV for Juniper Corner Cafe. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-CAF-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-CAF-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Juniper Corner Cafe. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Juniper Corner Cafe. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Juniper Corner Cafe. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Juniper Corner Cafe. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Credit note lines CSV for Willow Event Kitchen. 2 credit lines, one per note. CN-CAT-7001 credits 4 units for the short delivery and agrees with the goods-received note. CN-CAT-7002 credits 5 units where GRN-CAT-2004 records only 3 returned, an overstatement of 2.28 CAD net.
Goods-received note lines CSV for Willow Event Kitchen. 12 received lines across 4 goods-received notes. Three lines are exceptions: a short delivery of 4 units on GRN-CAT-2002, an item substitution on GRN-CAT-2003 where the delivered ingredient id differs from the ordered one, and a part return of 3 units on GRN-CAT-2004. accepted_quantity equals delivered_quantity minus returned_quantity on every row.
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.
Purchase order lines CSV for Willow Event Kitchen. 12 lines across 4 purchase orders dated 2026-08-05 to 2026-08-26. Each line repeats its order's net, tax and gross totals, so a reader can check that the line values sum to the header without a second file. Order PO-CAT-1002 totals 208.13 CAD including GST.
Remittance advice lines CSV for Willow Event Kitchen. 13 lines, one for every document on both statements, each marked paid or withheld with a reason. 1088.50 CAD is settled and 896.30 CAD is withheld against statement balances of 1984.80 CAD; the first two figures sum to the third.
Statements of account CSV for Willow Event Kitchen. 13 transaction rows across 2 month-end statements dated 2026-08-31. STM-CAT-6001 closes at 1003.36 CAD and its four declared ageing buckets sum to exactly that. STM-CAT-6002 closes at 981.44 CAD while its declared buckets sum to 991.60 CAD.
Supplier invoice lines CSV for Willow Event Kitchen. 14 lines across 5 invoice documents that carry only 4 distinct invoice numbers: INV-CAT-5002 appears twice, dated 2026-08-14 and 2026-08-17. invoice_number is therefore not a key; the pair of invoice_number and invoice_date is. invoice_stated_tax_total is the figure printed on the document, which for INV-CAT-5003 is one cent above the sum of its line tax amounts.
Supplier price list CSV for Willow Event Kitchen. 48 rows covering 2 suppliers, 6 items and 4 effective dates (2026-08-05, 2026-08-12, 2026-08-19, 2026-08-26). Each row carries the list unit price, the case pack quantity, the price per case and a contract tier price that applies only at 250 units. Every purchase order line in this set is priced from the row matching its supplier, item and order date.
Supplier price list CSV, semicolon and decimal comma for Willow Event Kitchen. The same 48 price rows re-exported the way a European supplier portal writes them: UTF-8 with a byte-order mark (EF BB BF), semicolon field separators, CRLF line endings, and decimal commas in list_unit_price, price_per_case and contract_tier_unit_price. Column names, column order and every value are identical to price-list.csv; only the encoding and the separators differ.
Three-way match report CSV for Willow Event Kitchen. 14 rows joining every invoice line to its purchase order line and its goods-received line. 9 rows match on item, quantity and price; the remaining 5 carry a match_result of duplicate-invoice-number, item-substituted, matched-credit-expected, quantity-variance and a note giving the exact variance.
Whole procure-to-pay chain JSON for Willow Event Kitchen. One object holding the buyer, both suppliers, all 6 items, the 48-row price list, 4 purchase orders, 4 goods-received notes, 5 invoice documents, 2 credit notes, 2 statements, the remittance advice, the 14-row three-way match and the 6 deliberate defects. Every monetary value is a JSON string with exactly two decimal places.
Contact export in the semicolon dialect for Tern Client Services. The same 8 contacts written with a semicolon delimiter. The billing_address field is still quoted because it contains newlines, but the tags field is now bare: "billing,renewals" needs no quotes when the delimiter is a semicolon, so the same value is quoted in contacts-export.csv and unquoted here. The file has 33 physical lines.
Contact export with quoted fields for Tern Client Services. 8 contacts in 33 physical lines, because every billing_address is a four-line address held in one quoted field. The addresses also contain commas, the notes contain doubled double-quote characters where a quotation appears, and the tags field holds the comma-separated value "billing,renewals" inside quotes. Every one of those is correctly escaped RFC 4180.
Expense claim whose mileage was paid at a superseded rate for Tern Client Services. The same 6 lines as expense-claim.csv, but the three mileage amounts were computed at the superseded 0.58 per kilometre while the rate column still reads 0.62. The mileage subtotal is 136.88 where 236 km at the stated rate is 146.32, so the claim is 9.44 light and totals 212.13 instead of 221.57.
Expense claim with mileage for Tern Client Services. 6 claim lines for August: 3 mileage lines worth 146.32 and 3 receipted lines worth 75.25, 221.57 in total. amount equals quantity times rate on every line, including the mileage lines where quantity is kilometres. Each line carries the project it belongs to and a receipt reference.
Invoice register JSON for Tern Client Services. The same 3 invoices as invoice-register.csv with the settlement rule stated: the retainer is drawn while a balance remains and the remainder is billed. totals.outstanding is 3200.00.
Invoice register with retainer draws for Tern Client Services. 3 invoices totalling 7200.00, which is the whole of the August timesheet. 4000.00 of it was settled by drawing the retainer to nil and 3200.00 is outstanding on SVCINV-3. amount equals retainer_applied plus cash_due on every row, and every invoice is dated 2026-09-30, 22 days after the 2026-09-08 snapshot, so all three sit in the not yet due bucket.
Mileage log for Tern Client Services. 3 client trips totalling 236 km. amount equals distance_km times rate_per_km on every row at the 0.62 per kilometre MIL rate from fee-schedule.csv, and the column sums to 146.32. Each trip names the project it was made for, so the mileage allocates cleanly to the three projects.
Professional fee schedule for Tern Client Services. Five rate codes. STD at 100.00 per hour is the only billing rate any time entry uses, which is why every row of timesheet-export.csv carries 100.00; OOH and TRV are defined but unused in this period and carry used_this_period false. MIL at 0.62 per kilometre is the mileage rate mileage-log.csv applies and COST at 58.00 per hour is the internal rate project-profitability.csv uses.
Professional services reconciliation assertions for Tern Client Services. The six identities this set claims with the figure each must produce: 7200.00 of billable time, the same amount invoiced, a retainer closing at 0.00, a work-in-progress roll-forward closing at 0.00, 221.57 of expenses and 9000.00 of won deals. It also records the 9.44 size of the deliberate defect.
Project profitability for Tern Client Services. 3 projects and a TOTAL row. revenue_billed is the invoiced value, labour_cost is hours times the 58.00 internal COST rate, expenses is the claim allocated by project, and gross_margin is revenue minus the two costs. Total revenue 7200.00 less total cost 4397.57 gives 2802.43, a margin of 38.92 percent.
Quote export for Tern Client Services. 12 quotes, one per deal, each for the deal amount. 3 are accepted and total 9000.00, the same figure as the won deals on pipeline-export.csv; the remaining 9 are open. Every quote expires on 2026-09-30, 30 days after it was issued.
Retainer ledger for Tern Client Services. A three-line retainer account: a 4000.00 deposit received on 2026-07-28 and two draws of 1600.00 and 2400.00 applied when SVCINV-1 and SVCINV-2 were raised. The running balance closes at 0.00, which is why SVCINV-3 is billed for payment rather than drawn.
Sales activity export for Tern Client Services. 24 logged activities over 2026-08-01 to 2026-08-24 across three types. Minutes total 720, which is 12 hours, and every deal_id resolves in pipeline-export.csv. This is recorded sales effort and is deliberately separate from the billable time in timesheet-export.csv, which none of it appears in.
Sales pipeline export for Tern Client Services. 12 deals across 4 companies and four stages. weighted_amount equals amount times probability on every row, amount totals 34500.00 and weighted_amount totals 15825.00. The 3 won deals total 9000.00, which is the sum of the project budgets on project-profitability.csv, and the lost deals carry probability 0.00 and a weighted amount of 0.00.
Specialist utilisation report for Tern Client Services. 3 specialists against a stated 64 available hours each. Billable hours are 16, 24, 32, so utilisation runs 25.00 to 50.00 percent. Each specialist worked on exactly one project in this period, which is why the projects column is 1 on every row.
Timesheet export CSV for Tern Client Services. 24 time entries over 2026-08-01 to 2026-08-24 across 3 projects for one client. billable_amount equals hours times hourly_rate on every row and every row is at the 100.00 standard rate. Hours total 72 and billable_amount totals 7200.00, split 1600.00 / 2400.00 / 3200.00 across the three projects.
Timesheet export JSON for Tern Client Services. The same 24 entries as timesheet-export.csv with a byProject rollup and a totals object. totals.hours is 72 and totals.billableAmount is 7200.00, and each byProject member names the invoice that billed it.
Work in progress at 2026-08-15 for Tern Client Services. Unbilled work at the 2026-08-15 cut-off: 15 of the 24 August time entries had been recorded by then, 45 hours worth 4500.00. Nothing had been invoiced at that date, the first invoice being dated 2026-09-01, so wip_at_cutoff equals value_to_cutoff on every row.
Work in progress roll-forward for Tern Client Services. The full-period roll-forward for the 3 projects and a TOTAL row. Opening WIP is 0.00, 7200.00 of time was added, the same 7200.00 was transferred to billed when the September invoices were raised, and closing WIP is 0.00 on every line. Transfers are negative because they leave work in progress.
Arrears report for Pine Property Services. The one genuine arrear: U-05 owes 16012.50 USD for 2026-Q3, due 2026-07-01 and 69 days overdue at the 2026-09-08 snapshot, which puts it in the 61 to 90 day bucket. The 5 fourth-quarter demands are deliberately absent because a demand for a quarter that has not started is not an arrear.
Building works recharged to the service charge for Pine Property Services. The 2 work orders the trades-property model records against PROP-1, with their labour and material costs, totalling 328.00 USD. All of them are recharged to the repairs and maintenance head, which is budgeted at 32,192.36 USD and spent at 31,240.00, so these rows are a subset of that head rather than the whole of it.
Deposit register for Pine Property Services. The 5 deposits, each two quarterly instalments of the rent on its own lease, holding 122,737.50 USD in total. Every deposit is released on expiry subject to a dilapidations claim, which is what connects this register to the dilapidations schedule in the same directory.
Lease abstract for Pine Property Services. The 5 let demises abstracted onto one row each: term, break, review, rent, service charge proportion and deposit. Quarterly rent is a quarter of annual rent and the deposit is two quarters on every row. Only LSE-2026-02 has a break date, so four of the five rows carry an empty break_date and an empty break_notice_by.
Lease abstract JSON for Pine Property Services. The same 5 leases plus a separate vacantUnits array, because a vacant demise has no lease to abstract but still has an area and a rental value. A reader that counts leases gets five; a reader that counts demises has to add the vacant array to get six.
Lease events diary for Pine Property Services. 12 dated events in ascending order with days measured from the 2026-09-08 snapshot. 1 of them are already in the past and carry a negative number, because a rent review date that has passed is still a fact about the lease and dropping it would hide a review that was never actioned.
Lease register for Pine Property Services. The 5 live leases with days to expiry measured from the 2026-09-08 snapshot. The shortest has 935 days to run and the longest 2761. Service charge percentages here are the same apportionment the budget and reconciliation use, so the register can be joined to either.
Property reconciliation identities for Pine Property Services. 5 named identities covering the areas, the rent, the service charge apportionment, the demands and the dilapidations build-up, with the figures behind each. The deliberate defect and its measured 18.50 sq m shortfall are listed separately.
Quarterly rent and service charge demands for Pine Property Services. 20 demands across four quarters for the five let demises. Each total is rent plus service charge and each outstanding is total less paid. Demanded rent and service charge across the year come to 331,075.00 USD, and 98,781.25 is outstanding: one genuine arrear and 5 demands for a quarter that has not started at the 2026-09-08 snapshot.
Rent roll for Pine Property Services. The 6 demises with area, rent, passing rent and estimated rental value. Unit areas sum to 1200.00 sq m, which is the building_area_sq_m value every row carries. Passing rent is 245,475.00 USD and estimated rental value 271,475.00, the difference being the 26000.00 USD that U-06 would produce if it were let. Annual rent is area times rate on every row and quarterly rent is a quarter of passing rent.
Rent roll JSON for Pine Property Services. The same 6 demises with the building level figures hoisted out of the rows: lettable area, common area, occupied area and occupancy by area. Occupancy is stated as a percentage of lettable area, not of lettable plus common, which is the choice that moves the number.
Rent roll whose unit areas do not sum to the building area for Pine Property Services. The same 6 demises with one number changed: U-03 reads 211.50 sq m instead of 230.00. Unit areas now sum to 1181.50 against the 1200.00 that every row still declares as building_area_sq_m, a shortfall of 18.50 sq m. The rent columns are untouched, so U-03 annual rent no longer equals its area times its rate either, and the two failures are the same mutation seen twice.
Schedule of condition for Pine Property Services. The 6 elements recorded at lease start and again at the exit inspection, with the dilapidations item each defect leads to. Five of the six lead to a costed item and the sixth records no defect and no action, so the schedule proves the claim is complete rather than only that it is arithmetically right.
Schedule of dilapidations lines for Pine Property Services. The same 12 lines as data, with subtotal and total rows carrying an empty item_ref so they can be told apart from costed items. Only the 5 rows with a reference beginning D are remedial works; the rest are on costs, subtotals or the consequential loss.
Schedule of unit areas for Pine Property Services. The 6 demises in PROP-1 with their floor areas and each one share of the 1200.00 sq m lettable area. Areas sum to the lettable area exactly and the shares sum to exactly 100.0000 percent because they are apportioned by largest remainder. The 185.00 sq m of common parts sits outside this table and is never apportioned, which is why no row accounts for it.
Service charge budget apportionment for Pine Property Services. The 96,000.00 USD budget apportioned across all six demises by area, including the vacant one, because a vacant unit share falls on the landlord and not on the other tenants. The six annual amounts sum to the budget exactly and the percentages sum to exactly 100.0000.
Service charge expenditure against budget for Pine Property Services. 6 heads of charge plus a management fee and a total. Actual expenditure is 102,476.00 USD against a budget of 96,000.00, and the management fee on both sides is 10 percent of the heads above it rather than a fixed amount, so it moves with the expenditure it is charged on.
Service charge year end reconciliation for Pine Property Services. The year end settlement: each demise share of the 102,476.00 USD actually spent against the 96,000.00 USD paid on account, with the difference as a balancing charge. Every row share of actual less on account equals its balancing charge, and the charges sum to 6,476.00 USD, the overspend. No unit is in credit, so the credit column is 0.00 throughout and is kept as a column rather than dropped.
Sample Protobuf Schema: small deterministic fixture for parsers and the in-browser editor.
A property-listings dataset: 30 homes with address, type, price, beds/baths, size, year built, coordinates, and status. Synthetic data for testing listing importers, map plots, and price analytics.
The property listings as a JSON array: the format twin of the CSV, for import and mapping tests.
A MovieLens-style ratings log: 240 user/item/rating events with Unix timestamps across 50 users and 40 items. A fixture for testing recommender pipelines, collaborative-filtering loaders, and sparse-matrix builders.
Allergen matrix for Alder Table Bistro. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 2 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Alder Table Bistro. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Potato gratin) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: milk: Cream.
Cleaning schedule for Alder Table Bistro. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Alder Table Bistro. Intentionally inconsistent. Row 3 reports a closing count of 22.20 kg for ING-03 (Potatoes), the counted figure with the two decimal digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 22.02 kg. Every derived value follows the wrong count, so the file is internally consistent and its total of 1574.49 CAD differs from the correct 1574.81 CAD by -0.32 CAD.
Daily Z-read and cash-up for Alder Table Bistro. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 896.00 less discounts 89.60 and comps 11.50 gives net sales 794.90; with GST 39.75 and charged tips 95.39 the total due is 930.04 CAD. Cash, card and gift tenders sum to the 917.54 collected after a 12.50 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 24 covers.
Daily Z-read as structured data for Alder Table Bistro. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Alder Table Bistro. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Alder Table Bistro. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 0 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Alder Table Bistro. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Alder Table Bistro. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Alder Table Bistro. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Alder Table Bistro. 12 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 1.01 to 3.07 CAD.
Product mix carrying items the menu does not have for Alder Table Bistro. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Roast chicken plate (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Alder Table Bistro. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 15780.80 CAD.
Purchase pack to recipe unit conversions for Alder Table Bistro. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 0 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Alder Table Bistro. 4 allocation rows and one total row for 2026-08-28. The declared pool of 138.14 CAD is 95.39 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 138.14 CAD, which equals the pool exactly.
Tip pool that is one cent short for Alder Table Bistro. Intentionally inconsistent. The last allocation row (EMP-04) reads 36.25 where the exact largest-remainder share is 36.26. The allocation rows therefore sum to 138.13 CAD while the total row still declares the pool as 138.14 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Alder Table Bistro. 15 dated waste entries across 11 columns, totalling 37.87 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Alder Table Bistro. 5 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 5 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Cedar Street Tacos. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 0 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Cedar Street Tacos. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Bean bowl) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: none declared from the costed recipe lines.
Cleaning schedule for Cedar Street Tacos. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Cedar Street Tacos. Intentionally inconsistent. Row 3 reports a closing count of 21.97 kg for ING-03 (Black Beans), the counted figure with the two decimal digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 21.79 kg. Every derived value follows the wrong count, so the file is internally consistent and its total of 2559.14 CAD differs from the correct 2559.57 CAD by -0.43 CAD.
Daily Z-read and cash-up for Cedar Street Tacos. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 1197.00 less discounts 119.70 and comps 11.00 gives net sales 1066.30; with GST 53.32 and charged tips 127.96 the total due is 1247.58 CAD. Cash, card and gift tenders sum to the 1235.58 collected after a 12.00 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 37 covers.
Daily Z-read as structured data for Cedar Street Tacos. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Cedar Street Tacos. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Cedar Street Tacos. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 2 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts. Theoretical closing on CNT-03 lands exactly on a half hundredth of a stock unit, so a reader that rounds half to even prints a different figure than this file, which rounds half up throughout.
Inventory count sheet as transcribed for Cedar Street Tacos. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Cedar Street Tacos. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Cedar Street Tacos. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Cedar Street Tacos. 18 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 1.18 to 2.11 CAD.
Product mix carrying items the menu does not have for Cedar Street Tacos. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Chicken taco trio (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Cedar Street Tacos. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 19374.60 CAD.
Purchase pack to recipe unit conversions for Cedar Street Tacos. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 1 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Cedar Street Tacos. 4 allocation rows and one total row for 2026-08-28. The declared pool of 170.71 CAD is 127.96 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 170.71 CAD, which equals the pool exactly.
Tip pool that is one cent short for Cedar Street Tacos. Intentionally inconsistent. The last allocation row (EMP-04) reads 44.80 where the exact largest-remainder share is 44.81. The allocation rows therefore sum to 170.70 CAD while the total row still declares the pool as 170.71 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Cedar Street Tacos. 15 dated waste entries across 11 columns, totalling 14.33 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Cedar Street Tacos. 3 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 3 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Copper Oven Bakery. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 4 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Copper Oven Bakery. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Sweet butter roll) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: cereals_gluten: Bread Flour; milk: Butter.
Cleaning schedule for Copper Oven Bakery. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Copper Oven Bakery. Intentionally inconsistent. Row 3 reports a closing count of 102.00 each for ING-03 (Eggs), the counted figure with the last two whole digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 120.00 each. Every derived value follows the wrong count, so the file is internally consistent and its total of 629.74 CAD differs from the correct 623.44 CAD by 6.30 CAD.
Daily Z-read and cash-up for Copper Oven Bakery. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 396.75 less discounts 39.68 and comps 4.25 gives net sales 352.82; with GST 17.64 and charged tips 42.34 the total due is 412.80 CAD. Cash, card and gift tenders sum to the 408.30 collected after a 4.50 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 31 covers.
Daily Z-read as structured data for Copper Oven Bakery. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Copper Oven Bakery. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Copper Oven Bakery. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 1 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Copper Oven Bakery. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Copper Oven Bakery. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Copper Oven Bakery. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Copper Oven Bakery. 11 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 0.36 to 0.86 CAD.
Product mix carrying items the menu does not have for Copper Oven Bakery. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Yeasted loaf (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Copper Oven Bakery. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 6651.14 CAD.
Purchase pack to recipe unit conversions for Copper Oven Bakery. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 0 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Copper Oven Bakery. 4 allocation rows and one total row for 2026-08-28. The declared pool of 85.09 CAD is 42.34 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 85.09 CAD, which equals the pool exactly.
Tip pool that is one cent short for Copper Oven Bakery. Intentionally inconsistent. The last allocation row (EMP-04) reads 22.32 where the exact largest-remainder share is 22.33. The allocation rows therefore sum to 85.08 CAD while the total row still declares the pool as 85.09 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Copper Oven Bakery. 15 dated waste entries across 11 columns, totalling 30.33 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct. WASTE-001 lands exactly on a half cent, so a reader that rounds half to even reports a cent less on that row than this file, which rounds half up like every other value in the folder.
Yield test results for Copper Oven Bakery. 2 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 2 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Ember Lane Pizza. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 4 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Ember Lane Pizza. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Basil tomato pizza) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: cereals_gluten: Pizza Flour; milk: Mozzarella.
Cleaning schedule for Ember Lane Pizza. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Ember Lane Pizza. Intentionally inconsistent. Row 3 reports a closing count of 23.52 kg for ING-03 (Crushed Tomatoes), the counted figure with the two decimal digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 23.25 kg. Every derived value follows the wrong count, so the file is internally consistent and its total of 3109.68 CAD differs from the correct 3110.43 CAD by -0.75 CAD.
Daily Z-read and cash-up for Ember Lane Pizza. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 1582.50 less discounts 158.25 and comps 20.00 gives net sales 1404.25; with GST 70.21 and charged tips 168.51 the total due is 1642.97 CAD. Cash, card and gift tenders sum to the 1624.97 collected after a 18.00 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 34 covers.
Daily Z-read as structured data for Ember Lane Pizza. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Ember Lane Pizza. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Ember Lane Pizza. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 1 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Ember Lane Pizza. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Ember Lane Pizza. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Ember Lane Pizza. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Ember Lane Pizza. 18 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 2.00 to 2.75 CAD.
Product mix carrying items the menu does not have for Ember Lane Pizza. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Margherita pizza (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Ember Lane Pizza. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 25954.50 CAD.
Purchase pack to recipe unit conversions for Ember Lane Pizza. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 3 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Ember Lane Pizza. 4 allocation rows and one total row for 2026-08-28. The declared pool of 211.26 CAD is 168.51 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 211.26 CAD, which equals the pool exactly.
Tip pool that is one cent short for Ember Lane Pizza. Intentionally inconsistent. The last allocation row (EMP-04) reads 55.44 where the exact largest-remainder share is 55.45. The allocation rows therefore sum to 211.25 CAD while the total row still declares the pool as 211.26 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Ember Lane Pizza. 15 dated waste entries across 11 columns, totalling 43.81 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Ember Lane Pizza. 2 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 2 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Harbour Kitchen Group. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 3 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Harbour Kitchen Group. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-03 (Loaded fries) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: milk: Whole Milk.
Cleaning schedule for Harbour Kitchen Group. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Harbour Kitchen Group. Intentionally inconsistent. Row 3 reports a closing count of 91.00 each for ING-03 (Beef Patty), the counted figure with the last two whole digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 19.00 each. Every derived value follows the wrong count, so the file is internally consistent and its total of 3075.48 CAD differs from the correct 3241.08 CAD by -165.60 CAD.
Daily Z-read and cash-up for Harbour Kitchen Group. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 1650.00 less discounts 165.00 and comps 19.50 gives net sales 1465.50; with GST 73.28 and charged tips 175.86 the total due is 1714.64 CAD. Cash, card and gift tenders sum to the 1702.64 collected after a 12.00 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 44 covers.
Daily Z-read as structured data for Harbour Kitchen Group. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Harbour Kitchen Group. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Harbour Kitchen Group. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 1 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Harbour Kitchen Group. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Harbour Kitchen Group. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Harbour Kitchen Group. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Harbour Kitchen Group. 10 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 0.79 to 3.08 CAD.
Product mix carrying items the menu does not have for Harbour Kitchen Group. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "House burger (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Harbour Kitchen Group. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 26214.00 CAD.
Purchase pack to recipe unit conversions for Harbour Kitchen Group. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 0 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Harbour Kitchen Group. 4 allocation rows and one total row for 2026-08-28. The declared pool of 218.61 CAD is 175.86 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 218.61 CAD, which equals the pool exactly.
Tip pool that is one cent short for Harbour Kitchen Group. Intentionally inconsistent. The last allocation row (EMP-04) reads 57.38 where the exact largest-remainder share is 57.39. The allocation rows therefore sum to 218.60 CAD while the total row still declares the pool as 218.61 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Harbour Kitchen Group. 15 dated waste entries across 11 columns, totalling 31.90 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Harbour Kitchen Group. 4 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 4 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Juniper Corner Cafe. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 4 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Juniper Corner Cafe. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Breakfast sandwich) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: cereals_gluten: Sourdough Bread; eggs: Eggs.
Cleaning schedule for Juniper Corner Cafe. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Juniper Corner Cafe. Intentionally inconsistent. Row 3 reports a closing count of 60.57 l for ING-03 (Oat Drink), the counted figure with the two decimal digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 60.75 l. Every derived value follows the wrong count, so the file is internally consistent and its total of 1538.64 CAD differs from the correct 1538.14 CAD by 0.50 CAD.
Daily Z-read and cash-up for Juniper Corner Cafe. A 61-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 608.75 less discounts 60.88 and comps 5.50 gives net sales 542.37; with GST 27.12 and charged tips 65.08 the total due is 634.57 CAD. Cash, card and gift tenders sum to the 624.07 collected after a 10.50 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 28 covers.
Daily Z-read as structured data for Juniper Corner Cafe. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Juniper Corner Cafe. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Juniper Corner Cafe. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 1 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Juniper Corner Cafe. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Juniper Corner Cafe. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Juniper Corner Cafe. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Juniper Corner Cafe. 8 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 0.70 to 1.68 CAD.
Product mix carrying items the menu does not have for Juniper Corner Cafe. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Flat white (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Juniper Corner Cafe. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 10234.74 CAD.
Purchase pack to recipe unit conversions for Juniper Corner Cafe. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 0 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Juniper Corner Cafe. 4 allocation rows and one total row for 2026-08-28. The declared pool of 107.83 CAD is 65.08 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 107.83 CAD, which equals the pool exactly.
Tip pool that is one cent short for Juniper Corner Cafe. Intentionally inconsistent. The last allocation row (EMP-04) reads 28.29 where the exact largest-remainder share is 28.30. The allocation rows therefore sum to 107.82 CAD while the total row still declares the pool as 107.83 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Juniper Corner Cafe. 15 dated waste entries across 11 columns, totalling 63.66 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Juniper Corner Cafe. 2 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 2 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen matrix for Willow Event Kitchen. 4 menu items across 18 columns: the fourteen listed allergens plus a count and a sources column naming the ingredient behind every Y. Derived from the recipe lines, so a dish whose recipe contains a dairy ingredient reads Y under milk. 3 of 4 dishes declare at least one allergen.
Allergen matrix missing a menu item for Willow Event Kitchen. Intentionally incomplete. 3 rows where the recipes cost 4 menu items. MENU-04 (Reception plate) has no row, although it has costed recipe lines in plate-costs.csv and sales in sales-mix-pmix.csv. Its correct row would declare: milk: Yogurt.
Cleaning schedule for Willow Event Kitchen. 18 tasks across 6 areas and 11 columns, with frequency in days, the responsible role, the chemical and its contact time, the last completion date and a next-due date that is exactly last_completed plus frequency_days. 4 task(s) are overdue at the period end.
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.
Cost of goods sold that contradicts the count sheet for Willow Event Kitchen. Intentionally inconsistent. Row 3 reports a closing count of 22.91 kg for ING-03 (Chickpeas), the counted figure with the two decimal digits transposed, where inventory-count-sheet.csv, inventory-variance.xlsx and cogs-report.json all count 22.19 kg. Every derived value follows the wrong count, so the file is internally consistent and its total of 2104.76 CAD differs from the correct 2106.63 CAD by -1.87 CAD.
Daily Z-read and cash-up for Willow Event Kitchen. A 62-line printed till report for 2026-08-28, 46 characters wide with no line longer than that. Gross 1795.50 less discounts 179.55 and comps 18.00 gives net sales 1597.95; with GST 79.90 and charged tips 191.75 the total due is 1869.60 CAD. Cash, card and gift tenders sum to the 1854.60 collected after a 15.00 refund. 2 voids are logged outside gross sales and the drawer records an over/short of -0.35 on 40 covers.
Daily Z-read as structured data for Willow Event Kitchen. The same Z-read as JSON: 4 item lines, a summary block, 3 tender lines that sum to the total collected, 2 voids, one comp, 1 refund traced to its sales id, and a cash drawer block whose expected figure less the counted figure equals the declared over/short of -0.35 CAD.
HACCP temperature log for Willow Event Kitchen. 84 readings across 13 columns: 3 units checked twice a day for fourteen days. Each row carries its own lower and upper limit, so the within_limit column can be recomputed from the row beside it. 2 readings fall outside their limit (TEMP-038, TEMP-071) and only those rows carry a corrective action.
Inventory count sheet for Willow Event Kitchen. 6 ingredients across 17 columns: par level, opening count, receipts, theoretical usage, recorded waste, theoretical closing, counted closing and the variance between them, priced at standard cost. 1 item(s) close below par. These counted closing quantities are the ones cogs-report-inconsistent.csv contradicts.
Inventory count sheet as transcribed for Willow Event Kitchen. The same closing counts as inventory-count-sheet.csv, in the shape a paper count actually arrives in. CRLF line endings, a UTF-8 byte order mark, a semicolon delimiter and a decimal comma. Two blank lines, one section banner that is not a record, one ingredient split across two locations, one counted as whole packs plus a remainder, one superseded mid-shift row at 14:20, trailing whitespace in three fields, a leading-zero bin code, an empty bin code, and one record carrying ten fields where the header declares 9. Every quirk is named in README.md.
Labour schedule with split and overnight shifts for Willow Event Kitchen. 74 shift segments across 17 columns for 2026-08-20 to 2026-09-02, totalling 413.00 paid hours and 9634.00 CAD of base pay. 14 shifts are split into two segments with an unpaid gap, and 9 segments end on the following calendar day, including SHIFT-056 which runs 22:30 on 2026-09-02 to 05:30 on 2026-09-03. 4 rows are authored cover shifts; the rest reproduce the shared staffing table hour for hour.
Overtime computed on the wrong week boundary for Willow Event Kitchen. Intentionally inconsistent. The same 74 shift segments are grouped into Sunday-start work weeks where the declared policy, and labour-hours-overtime.xlsx, start each week on Monday. The correct grouping yields 5.00 payable overtime hours and 51.50 CAD of premium; this file yields 3.00 hours and 31.50 CAD. The hours that disappear belong to EMP-01 in the week beginning 2026-08-24, whose 46.00 hours the Sunday grouping splits across two weeks.
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.
Plate costing lines for Willow Event Kitchen. 19 recipe lines across 4 menu items, 17 columns. Recipe quantities are in grams, millilitres or each; the as-purchased quantity divides by the yield, so the line cost is not a naive multiplication. Plate costs run 0.72 to 2.19 CAD.
Product mix carrying items the menu does not have for Willow Event Kitchen. Intentionally inconsistent. 6 rows where sales-mix-pmix.csv has 4. MENU-90 and MENU-91 are not in the shared menu table, and the first row renames MENU-01 to "Chicken buffet portion (lunch)", which has a doubled space and a suffix the menu does not carry. The remaining rows are correct.
Product mix report for Willow Event Kitchen. 4 menu items across 12 columns for 2026-08-20 to 2026-09-02: quantity sold, mix percent, gross, discount, net, share of net, plate cost, item cost, item margin and item food-cost percent. Quantities and net sales match the shared sales table row for row; total net is 28781.90 CAD.
Purchase pack to recipe unit conversions for Willow Event Kitchen. 6 ingredients across 16 columns. Each row carries the purchase pack, the pack price, the cost per stock unit to six decimal places, the cost per recipe unit to eight, and the purchase id, date and supplier the price came from. 1 row(s) report a non-zero rounding residual because the pack size is not a whole number of stock units.
Tip pool distribution for Willow Event Kitchen. 4 allocation rows and one total row for 2026-08-28. The declared pool of 234.50 CAD is 191.75 charged to card plus 42.75 declared cash, split 30 percent to back of house, then allocated within each group by hours times a role weight. Whole cents are assigned by largest remainder, so the rows sum to 234.50 CAD, which equals the pool exactly.
Tip pool that is one cent short for Willow Event Kitchen. Intentionally inconsistent. The last allocation row (EMP-04) reads 61.55 where the exact largest-remainder share is 61.56. The allocation rows therefore sum to 234.49 CAD while the total row still declares the pool as 234.50 CAD, a shortfall of exactly 0.01 CAD.
Waste and spoilage log for Willow Event Kitchen. 15 dated waste entries across 11 columns, totalling 25.38 CAD at standard cost. The quantities per ingredient are exactly the recorded waste that inventory-variance.xlsx and cogs-report.xlsx deduct.
Yield test results for Willow Event Kitchen. 2 yield tests across 17 columns: raw weight, trim waste, trimmed weight, trim yield percent, cooked weight, cooking loss percent and the overall yield factor. All 2 rows report matches_recipe=yes, meaning each measured trim yield equals the yield percent that plate-costs.csv applies to the same ingredient.
Allergen menu as data for Alder Table Bistro. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 2 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Alder Table Bistro. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-02 Tomato soup is printed on printed-menu.pdf at 11.50 CAD and declares 1 allergen in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Alder Table Bistro. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Alder Table Bistro. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$11.50", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Alder Table Bistro. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Alder Table Bistro. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "é", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Alder Table Bistro. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 11.50 CAD and again on line 23 at 12.50 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Cedar Street Tacos. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 0 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Cedar Street Tacos. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 Chicken taco trio is printed on printed-menu.pdf at 13.50 CAD and declares 0 allergens in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Cedar Street Tacos. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Cedar Street Tacos. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$13.50", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Cedar Street Tacos. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Cedar Street Tacos. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "ï", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Cedar Street Tacos. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 11.00 CAD and again on line 23 at 12.00 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Copper Oven Bakery. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 4 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Copper Oven Bakery. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 Yeasted loaf is printed on printed-menu.pdf at 7.50 CAD and declares 1 allergen in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Copper Oven Bakery. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Copper Oven Bakery. Intentionally invalid. All 30 Offer nodes carry price as a JSON string with a currency symbol, the first being "$7.50", where menu.jsonld carries the same 30 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Copper Oven Bakery. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Copper Oven Bakery. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "à", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Copper Oven Bakery. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 4.25 CAD and again on line 23 at 5.25 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Ember Lane Pizza. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 4 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Ember Lane Pizza. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 Margherita pizza is printed on printed-menu.pdf at 17.00 CAD and declares 2 allergens in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Ember Lane Pizza. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Ember Lane Pizza. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$17.00", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Ember Lane Pizza. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Ember Lane Pizza. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "à", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Ember Lane Pizza. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 20.00 CAD and again on line 23 at 21.00 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Harbour Kitchen Group. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 3 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Harbour Kitchen Group. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 House burger is printed on printed-menu.pdf at 18.50 CAD and declares 2 allergens in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Harbour Kitchen Group. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Harbour Kitchen Group. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$18.50", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Harbour Kitchen Group. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Harbour Kitchen Group. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "à", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Harbour Kitchen Group. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 19.50 CAD and again on line 23 at 20.50 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Juniper Corner Cafe. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 4 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Juniper Corner Cafe. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 Flat white is printed on printed-menu.pdf at 4.75 CAD and declares 1 allergen in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Juniper Corner Cafe. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Juniper Corner Cafe. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$4.75", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Juniper Corner Cafe. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Juniper Corner Cafe. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "é", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Juniper Corner Cafe. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 5.50 CAD and again on line 23 at 6.50 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Allergen menu as data for Willow Event Kitchen. 4 rows and 21 columns: the menu item id, the printed section, the menu price, the 14 allergen columns, the declared count and the ingredient sources. 3 of 4 dishes declare at least one allergen. Joins to printed-menu.pdf and to plate-costs.csv on menu_item_id.
Allergen menu missing a dish on the menu for Willow Event Kitchen. Intentionally incomplete. 3 rows where allergen-menu.csv has 4. MENU-01 Chicken buffet portion is printed on printed-menu.pdf at 21.00 CAD and declares 1 allergen in the costing folder, and it has no row here. The remaining rows are correct.
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.
Drinks list as data for Willow Event Kitchen. 8 rows and 7 columns pairing every printed drink line with the till item code it imports as, the serve size in millilitres and the basis of its price. The three drinks sold both ways appear twice, once per service.
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.
Menu JSON-LD with string prices for Willow Event Kitchen. Intentionally invalid. All 27 Offer nodes carry price as a JSON string with a currency symbol, the first being "$21.00", where menu.jsonld carries the same 27 prices as JSON numbers. Nothing else differs, so a consumer that accepts text prices reports the file as fine and then fails on the arithmetic.
Till import for Willow Event Kitchen. 21 rows and 6 columns in the shape a point of sale ingests: item_code, item_name, category, price, tax_code, modifier_group. 4 dishes, 8 modifier options across 4 groups, 8 drink lines and one stored value line. Item codes are letter prefixed so a spreadsheet cannot eat a leading zero, and two tax codes are present so a mapping has something to map.
Till import in the European dialect for Willow Event Kitchen. The same 21 rows as pos-import.csv in the other dialect a till exports: semicolon delimited, decimal comma in the price column, Latin-1 encoded and CRLF terminated. It carries the non-ASCII characters "é", so reading it as UTF-8 raises a decode error instead of silently producing mojibake.
Till import with a duplicate item code for Willow Event Kitchen. Intentionally invalid. 22 rows where pos-import.csv has 21. item_code MENU-02 appears on line 3 at 18.00 CAD and again on line 23 at 19.00 CAD, which is the proposed price in the shared menu_price_changes table. It is the only repeated code in the file, so an importer that keeps the last row it reads silently ships the later price.
Synthetic product-analytics events (signup/login/upgrade) for testing event pipelines and warehouse loads. CSV twin.
Synthetic product-analytics events (signup/login/upgrade) for testing event pipelines and warehouse loads. JSON twin.
Billing reconciliation assertions for Juniper Workspace Cloud. The six identities this set claims with their exact figures: opening MRR 235.00, closing MRR 236.00, September invoiced 245.00, usage 24.54 and lifetime billings equal to recognition at 1963.20.
Closing MRR by account for Juniper Workspace Cloud. 6 accounts with the plan each one holds at 2026-09-30 and the recurring revenue that plan carries. Two accounts are cancelled and carry 0.00; the remaining four sum to 236.00, the closing figure on mrr-movement.csv.
Dunning sequence for Juniper Workspace Cloud. The 6 escalation steps against invoice INV-10 for account ACC-04, the one invoice in the model carrying an outstanding balance of 19.00. Steps run 2026-09-01 to 2026-09-30: reminder, two card retries that fail on insufficient_funds, a final notice, a third retry that fails on do_not_honor, then cancellation. Each row's next_action_date equals the attempt_date of the following row, and the last row has none.
Dunning sequence JSON for Juniper Workspace Cloud. The same 6 steps as dunning-sequence.csv with the retry policy and the terminal state named. terminalState is cancelled.
Failed payment attempt log for Juniper Workspace Cloud. The 3 card attempts behind the dunning sequence, with UTC timestamps, the gateway status and the decline code. All three are for 19.00 against invoice INV-10 and all three failed, which is why the balance never moves.
Invoice register widened to 40 columns for Juniper Workspace Cloud. The same 17 invoices as invoice-register.csv followed by 29 empty custom_field_NN columns, 40 in total. Every custom field is present in the header and empty in every row, which is what a billing platform export looks like when the tenant has defined no custom fields.
MRR movement report for Juniper Workspace Cloud. Opening monthly recurring revenue 235.00 on 2026-09-01, expansion 50.00 from the Team to Studio upgrade, contraction -30.00 from the Team to Basic downgrade, churn -19.00 when account ACC-04 is cancelled on 2026-09-30, no new business, closing 236.00. The opening figure equals the recurring-line subtotal of invoice-lines-2026-09.csv exactly.
MRR movement report JSON for Juniper Workspace Cloud. The same movement as mrr-movement.csv with the reconciliation rule stated. openingMrr 235.00, closingMrr 236.00.
MRR movement report that does not reconcile for Juniper Workspace Cloud. Identical to mrr-movement.csv except that the contraction row states -20.00 instead of -30.00. The from_plan and to_plan columns still say Team to Basic, a -30.00 drop, so the row contradicts itself as well as the closing total. Opening plus the four movement rows gives 246.00 while the closing row still states 236.00.
Raw metered usage events for Juniper Workspace Cloud. 18 daily usage records over 2026-08-01 to 2026-08-03 for 6 accounts, carrying an export count and a storage reading in MB. These are the inputs the tiered usage bill is computed from; the exports column sums to 102.
Revenue recognition and deferred revenue schedule for Juniper Workspace Cloud. 15 monthly periods from 2026-07 to 2027-09. Monthly subscriptions are recognised in their own service month, so the deferred balance is 0.00 until the 1069.20 annual contract is billed in 2026-09 for a service period starting 2026-10. That pushes deferred revenue to 1069.20 at 2026-09-30 and releases it at 89.10 a month until it reaches 0.00 at 2027-09. Billings and recognition both total 1963.20.
Revenue recognition schedule JSON for Juniper Workspace Cloud. The same 15 periods as the CSV with the recognition basis stated. totals.billed and totals.recognised are both 1963.20 and peakDeferred is 1069.20.
September invoice lines with mid-cycle proration for Juniper Workspace Cloud. 9 lines across 5 invoices. 5 are recurring plan lines summing to 235.00; 2 are proration credits summing to -49.00 for the unused half of a Team plan; 2 are proration charges summing to 59.00. One account upgrades Team to Studio and one downgrades Team to Basic, both effective 2026-09-16 with 15 of 30 days remaining. The lines sum to 245.00.
September invoices with proration as JSON for Juniper Workspace Cloud. The 5 September invoices nested with their lines, plus the stated proration basis. totals.total is 245.00 and totals.recurring is 235.00, which equals opening monthly recurring revenue.
Subscription invoice register for Juniper Workspace Cloud. 17 invoices over three cycles: 12 monthly invoices for 2026-07 and 2026-08 and 5 for 2026-09. amount minus paid equals outstanding on every row. Billed totals 913.00 and outstanding 38.00, which is the 19.00 August invoice in dunning plus the 19.00 September invoice for the same account.
Subscription lifecycle events for Juniper Workspace Cloud. The 4 events that move recurring revenue in September, each with a UTC timestamp and the MRR delta it causes. The deltas sum to 1.00, which is exactly closing MRR 236.00 minus opening MRR 235.00. The annual contract signing carries a 0.00 delta because the plan rate does not change.
Subscription plan catalog for Juniper Workspace Cloud. The 3 plans the accounts hold, with the monthly rate, the annual rate at a 10 percent discount and the metered allowances. The Studio annual rate 1069.20 is the amount actually billed on the annual contract invoice.
Tiered usage bill for Juniper Workspace Cloud. 6 accounts billed on the rate card. The tier columns split each account's exports across the three bands and always sum back to billable_exports. Export charges total 16.65, storage charges 7.89 and the usage bill 24.54. Account ACC-06 is the only one to reach the third tier, with 1 unit above 20.
Tiered usage bill JSON for Juniper Workspace Cloud. The same 6 accounts as usage-billing-tiered.csv with the rate card embedded as nested tier objects whose open-ended top band has upTo null. totals.usageTotal is 24.54.
Tiered usage rate card for Juniper Workspace Cloud. Two metered dimensions. Exports: the first 10 are included, units 11 to 20 cost 0.4000 each and everything above 20 costs 0.2500. Storage: 250 MB included, then 0.0150 per MB on the peak reading. The open-ended top tier has an empty to_unit.
The compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.
The baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.
The breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.
Draft-07 JSON Schema describing a SAMPLE event object for domain-specific validator tests.
Intentionally invalid JSON Schema (json-schema-bad-ref) for negative validator tests.
OpenAPI with a response schema $ref pointing at a missing component. Tests broken-reference detection.
OpenAPI document with paths set to null, intentionally invalid for negative schema tests.
OpenAPI with an unsupported openapi version string: negative case for version validators.
Draft-07 JSON Schema describing a SAMPLE inventory item object for domain-specific validator tests.
Draft-07 JSON Schema describing a SAMPLE invoice object for domain-specific validator tests.
JSON Schema allOf merging id and name requirements. Tests composite schema validation.
Minimal JSON Schema SAMPLE focusing on additional properties false 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 enum currency constraints.
Minimal JSON Schema SAMPLE focusing on format uri email constraints.
Minimal JSON Schema SAMPLE focusing on nullable optional constraints.
Minimal JSON Schema SAMPLE focusing on one of status constraints.
Minimal JSON Schema SAMPLE focusing on pattern sku constraints.
JSON Schema with a oneOf union over string vs number tagged objects, for testing union validation.
The compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.
The baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.
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 empty schema is valid and accepts every instance. The old invalid label was incorrect; no type or required-property constraint exists.
Omitting type is legal JSON Schema. The x property has an empty subschema, x is optional, and non-object instances are not rejected by properties.
Minimal OpenAPI 3.1 document with a webhooks section, for testing webhook-aware spec parsers.
OpenAPI document with empty paths but populated components. Tests partial spec loaders.
Sample POST /pets request body matching the pet-store OpenAPI spec.
Sample 404 problem response for OpenAPI error-handling tests.
Sample paginated pet list response for mock-server and contract tests.
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 baseline member of a complete OpenAPI 3.1 ticket endpoint contract. Reference API: string ticket IDs and required id/summary response properties.
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.
Invalid payment JSON (negative amount, short currency) for schema error reporting tests.
Valid payment JSON instance paired with the payment JSON Schema.
Draft-07 JSON Schema for payment amount/currency validation in fintech API tests.
A valid OpenAPI 3.1 pet-store SAMPLE spec in JSON: list/create pets with paginated responses for schema-validator and codegen tests.
YAML twin of the valid pet-store OpenAPI spec, for testing YAML spec parsers and JSON↔YAML conversion.
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 product object that conforms to the product JSON Schema: the positive case for testing a JSON-Schema validator.
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.
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 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 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.
User JSON deliberately violating the schema five ways: negative case for validator error reporting.
JSON instance conforming to the Wave F user JSON Schema: positive validator test case.
Draft 2020-12 JSON Schema for a user object with email format and role enum, paired with valid/invalid instances.
A BibTeX bibliography with three real citations (Lovelace, Knuth, Shannon) across article, book, and inproceedings types, for testing BibTeX parsers, reference managers, and citation converters.
A minimal but valid FITS image (a primary header of 80-character cards padded to a 2880-byte block, followed by a 16x16 unsigned-byte pixel gradient) for testing FITS readers and header-card parsers.
An MDL Molfile (V2000) of a water molecule with standard geometry (a counts line, atom block with 2D coordinates, and bond block) for testing cheminformatics parsers and MOL/SDF converters.
A NetCDF-3 (classic) file holding a small CF-convention gridded temperature field over latitude, longitude, and time, with named dimensions and units, for testing NetCDF readers like netCDF4 and xarray.
The same water molecule in PDB format with fixed-column HETATM coordinate records and a CONECT bond record, for testing molecular-structure parsers and viewers and PDB/MOL conversion.
The same three references as an RIS citation file with two-letter tags and ER record terminators: the twin of the BibTeX file, for testing RIS import and BibTeX/RIS conversion.
A PKCS#10 certificate signing request (PEM) with the subject and SAN, self-signed by the RSA key to prove key possession, for testing CSR parsers and certificate-authority intake flows.
An Ed25519 private key in PKCS#8 PEM, derived from a fixed seed: a published, sample-only modern elliptic-curve key for testing PEM parsers and Ed25519 tooling. Never use it for real.
An Apache/nginx .htpasswd file with two users hashed using the {SHA} scheme (Base64 SHA-1): the sample passwords are documented in the file, for testing Basic-Auth credential parsers and hash identification.
A PKCS#12 (.p12/PFX) bundle packaging the sample RSA key and certificate together, protected with the sample password 'novus-sample', for testing keystore importers and PKCS#12 parsers. (The PKCS#12 MAC salt is random, so this file is intentionally not byte-stable.)
A 2048-bit RSA private key in unencrypted PKCS#8 PEM: a deliberately PUBLISHED, sample-only key for testing PEM key parsers and PKCS#8 decoders. Never use it for anything real.
A sample JSON Web Token (JWT) signed with HS256 using a published example secret (verifiable but powerless) for testing JWT decoders and validators. Sample only, never for production. Paired with its decoded claims.
The decoded header and payload of the sample JWT as JSON, alongside the public signing secret and algorithm: the ground truth for checking a JWT decoder's output.
An OpenSSH-format Ed25519 public key (the shareable half of the key pair): a single line of algorithm, Base64 key blob, and comment, for testing SSH public-key parsers and authorized_keys tooling.
The same self-signed certificate under the conventional .crt extension (PEM-encoded), for testing trust-store importers and tools that key off the .crt extension. Sample only.
The binary DER encoding of the same certificate, for testing ASN.1/DER parsers, Java keystores, and DER-to-PEM converters. Published sample certificate, not a real identity.
A self-signed X.509 v3 certificate in PEM (Base64) encoding with a SAN and key-usage extensions, published sample material for testing certificate and TLS parsers. Not a real identity.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
Machine-readable description of all 16 variants in this group: the file, the kind of damage, the measured parameters that produced it and what each one is expected to demonstrate. Provided so a test suite can walk the ladder programmatically instead of hard-coding filenames.
A football-style league table: position, played, won/drawn/lost, goals for/against, goal difference, and points for ten teams, derived from a full round of synthetic match results. Paired with the results JSON.
The full round of match results behind the league table: home/away teams, scores, and dates as a JSON array. A fixture for testing sports-data importers and standings calculators.
A MySQL-flavour SQL dump with backtick-quoted identifiers and engine options, for testing SQL importers.
A Postgres-flavour SQL dump with a CREATE TABLE and INSERT statements, for testing SQL importers and migrations.
The customer dimension of a star schema: surrogate key, name, city, country, and segment. Joins to the sales fact table on customer_key. Names are synthetic.
The date dimension of a star schema: one row per day with a YYYYMMDD surrogate key and calendar attributes (year, quarter, month, weekday). Joins to the sales fact table on date_key.
The product dimension of a star schema: surrogate key, SKU, name, category, and unit price. Joins to the sales fact table on product_key.
The sales fact table at the centre of a star schema: 300 sale lines with foreign keys to the date, product, and customer dimensions plus quantity and amount measures. A fixture for testing joins, star-schema imports, and BI tools.
Synthetic support dataset (tickets) as CSV, for ETL and warehouse loader tests.
JSON twin of the support/tickets mini-dataset.
A customer-survey response set: 60 respondents rating five statements on a 1–5 Likert scale plus a 0–10 NPS score and a segment. A fixture for testing survey analysis, aggregation, and NPS/CSAT calculations.
Deterministic synthetic CSV batch 01 for bulk-import smoke tests.
Deterministic synthetic JSON batch 01 for bulk-import smoke tests.
Deterministic synthetic CSV batch 02 for bulk-import smoke tests.
Deterministic synthetic JSON batch 02 for bulk-import smoke tests.
Deterministic synthetic CSV batch 03 for bulk-import smoke tests.
Deterministic synthetic JSON batch 03 for bulk-import smoke tests.
Deterministic synthetic CSV batch 04 for bulk-import smoke tests.
Deterministic synthetic JSON batch 04 for bulk-import smoke tests.
Deterministic synthetic CSV batch 05 for bulk-import smoke tests.
Deterministic synthetic JSON batch 05 for bulk-import smoke tests.
Deterministic synthetic CSV batch 06 for bulk-import smoke tests.
Deterministic synthetic JSON batch 06 for bulk-import smoke tests.
Deterministic synthetic CSV batch 07 for bulk-import smoke tests.
Deterministic synthetic JSON batch 07 for bulk-import smoke tests.
Deterministic synthetic CSV batch 08 for bulk-import smoke tests.
Deterministic synthetic JSON batch 08 for bulk-import smoke tests.
Deterministic synthetic CSV batch 09 for bulk-import smoke tests.
Deterministic synthetic JSON batch 09 for bulk-import smoke tests.
Deterministic synthetic CSV batch 10 for bulk-import smoke tests.
Deterministic synthetic JSON batch 10 for bulk-import smoke tests.
Deterministic synthetic CSV batch 11 for bulk-import smoke tests.
Deterministic synthetic JSON batch 11 for bulk-import smoke tests.
Deterministic synthetic CSV batch 12 for bulk-import smoke tests.
Deterministic synthetic JSON batch 12 for bulk-import smoke tests.
Deterministic synthetic CSV batch 13 for bulk-import smoke tests.
Deterministic synthetic JSON batch 13 for bulk-import smoke tests.
Deterministic synthetic CSV batch 14 for bulk-import smoke tests.
Deterministic synthetic JSON batch 14 for bulk-import smoke tests.
Deterministic synthetic CSV batch 15 for bulk-import smoke tests.
Deterministic synthetic JSON batch 15 for bulk-import smoke tests.
Deterministic synthetic CSV batch 16 for bulk-import smoke tests.
Deterministic synthetic JSON batch 16 for bulk-import smoke tests.
Deterministic synthetic CSV batch 17 for bulk-import smoke tests.
Deterministic synthetic JSON batch 17 for bulk-import smoke tests.
Deterministic synthetic CSV batch 18 for bulk-import smoke tests.
Deterministic synthetic JSON batch 18 for bulk-import smoke tests.
Deterministic synthetic CSV batch 19 for bulk-import smoke tests.
Deterministic synthetic JSON batch 19 for bulk-import smoke tests.
Deterministic synthetic CSV batch 20 for bulk-import smoke tests.
Deterministic synthetic JSON batch 20 for bulk-import smoke tests.
Sales tax filing worksheet for Fieldnote Supply Shop. The 6 jurisdictions this shop collected in during 2026-08-01 to 2026-08-31, taken to the point of remittance. Net tax due sums to 88.88 USD, exactly the figure the wave-one tax-summary.csv reaches by a different route; two jurisdictions allow a vendor collection discount, which takes 0.13 off, so 88.75 USD is actually remitted. 2 rows have an empty permit_number because the two Canadian jurisdictions are filed on the GST/HST return instead.
Sales tax filing worksheet JSON for Fieldnote Supply Shop. The same 6 jurisdictions with the three control totals hoisted into a totals object. Rates are strings at five and four decimal places rather than floats, so 0.08875 survives; read as a float it is the rate that most often loses its last digit in a round trip.
Sales tax nexus summary for Fieldnote Supply Shop. Why the shop is registered in each of the 6 jurisdictions, with the permit, the filing frequency and the next due date. Due dates range from 2026-09-20 to 2026-10-31, so a reader that assumes one filing calendar across a multi-state seller gets four of the six wrong.
Sales tax payable control account for Fieldnote Supply Shop. The ledger account behind the filing: opening 0.00, credited 96.34 of tax collected, debited 7.46 of tax refunded, leaving 88.88 USD payable at the end of the period. The 0.13 vendor allowance and the 88.75 remittance then clear it to exactly 0.00 on 2026-09-20. The balance after row 3 is the same number the filing worksheet reaches by summing six jurisdictions.
Tax obligation calendar for Fieldnote Supply Shop. 10 dated obligations across four regimes and two currencies, in due date order, each with the days from the fixed snapshot and the amount due. The amount column mixes USD and CAD, so it must not be summed without the currency column: doing so gives a meaningless 10399.60.
Tax rate table for Fieldnote Supply Shop. The 6 rates as both a decimal and a percentage, so a reader can check one against the other. US-NY at 0.08875 is the one that a float round trip most often damages, and it is carried here to five decimal places and as 8.875 percent.
Tax reconciliation identities for Fieldnote Supply Shop. 5 named identities across three operating models and two currencies, including the rounding-order identity that measures how far a per-row tax calculation drifts from a per-period one. The deliberate defect and its measured 100.00 USD shortfall are listed separately.
Tax reconciliation, source against source for Fieldnote Supply Shop. 7 identities stated as a pair of sources and their values, with the difference computed rather than asserted. Every difference is 0.00, and two of the rows reach across into the wave-one ecommerce set and into the crm-services model, so the file is also a cross-set consistency check.
GST/HST return JSON for Harbour Kitchen Group. The same six lines with the registration, province, rate and period as siblings of the lines array, so the rate can be checked against the line arithmetic without another file.
GST/HST return lines for Harbour Kitchen Group. The six return lines as a three-column CSV keyed by the line number the form uses, so a reader can address a value by its line rather than by its position. Line 109 and line 115 both carry 3152.57 CAD because there are no instalments to deduct.
GST/HST return workings for Harbour Kitchen Group. Every source record behind the return: 56 sales rows tagged to line 105 and 24 purchase rows tagged to line 108, 80 rows in all. Taxing each row and adding gives 3407.94 and 255.23, which are 0.12 and -0.02 away from the 3407.82 and 255.25 on the return, because the return taxes the period total once and this file taxes every row and then adds.
Payroll deduction rates used by the T4 shaped slips for Harbour Kitchen Group. The 5 rates behind every T4 box in this set, with the basis each one is applied to and an explicit statement that no maximum, band or personal exemption is applied. Two rows are multipliers of another row rather than percentages of income, so a reader that treats the rate column as one thing gets the employer lines wrong.
T4 shaped slip register for Harbour Kitchen Group. All 8 slips for the period. Box 14 sums to 9,190.00 CAD, which is the base pay the restaurant model records across every rostered shift, and boxes 16, 18 and 22 sum to 546.82, 152.56 and 1,378.50. Every row net_pay_cad is box 14 less those three, and the eight net figures sum to 7,112.12 CAD.
T4 shaped summary lines for Harbour Kitchen Group. The same 8 summary lines as a CSV keyed by the box number, with the slip count on a line whose key is a word rather than a number, so a reader that assumes an integer key on every row has to handle it.
1099-NEC shaped recipient list for Tern Client Services. 2 recipients with every box the slips print. box_1 sums to 2880.00 USD, which is the control_total_box_1 value carried on every row, and the box_6 column is empty on both rows because neither payee has a state identification number. The third contractor is absent by design: WRK-02 files a W-8BEN shaped certificate and is reported on the 1042-S shaped statement.
1099-NEC shaped recipient list JSON for Tern Client Services. The same 2 recipients with the control total hoisted out of the rows and into the document, where it belongs, so the same check can be run against a single authoritative value rather than a value repeated on every row.
1099-NEC shaped recipient list whose boxes do not reach the control total for Tern Client Services. The same 2 recipients with one number changed: WRK-03 box_1 reads 1820.00 instead of 1920.00. box_1 now sums to 2780.00 against the 2880.00 that both rows still carry as control_total_box_1, a shortfall of 100.00 USD. box_7 was moved with box_1 so the row stays internally consistent and only the control total catches it.
Payee register for Tern Client Services. All 3 contractor payees with the certificate each has on file and the information return each one gets. Payments sum to 4,320.00 USD, which is every recorded hour at 60.00 USD, but they split 2,880.00 to 1099-NEC shaped slips and 1,440.00 to a 1042-S shaped statement, so no single information return file totals the ledger.
Hourly order counts weekdays only (09–16 UTC) across three SAMPLE days.
Load readings with a repeated 01:00 local hour on fall-back DST. Tests ambiguous timestamp handling.
Hourly load data skipping the 03:00 hour on DST spring-forward day. Tests timezone/DST gap handling.
Two rows share the same timestamp key. Tests deduplication and last-write-wins policies.
JSON array with duplicate timestamp keys for ingestion pipeline tests.
Timestamps at Unix epoch and classic 32-bit Y2038 boundary.
Series with an explicit null value at a missing sample point.
Sensor readings at irregular minute gaps. Tests time-series resampling and gap detection.
JSON twin of irregular-interval sensor readings for charting library tests.
Readings spanning Feb 29 leap day: calendar edge case.
Sub-second millisecond timestamps for precision parsing tests.
Same nominal instant expressed in Z, -05:00, and +09:00 offsets.
CSV with NaN string and empty cells representing missing measurements.
Timestamps out of chronological order. Tests sort-on-ingest behaviour.
Sparse event log in JSON Lines: two events hours apart for event-stream ingestion tests.
Pre-aggregated weekly totals JSON for rollup/chart tests.
A flight-schedule dataset: 30 flights with airline, origin/destination airports, departure/arrival times, aircraft, gate, and status. Synthetic data for testing travel apps, schedule parsers, and status boards.
The flight schedule as a JSON array: the format twin of the CSV, for import and display tests.
A 30-day daily weather forecast for one city: high/low temperature, condition, precipitation, wind, and humidity. Synthetic (seeded) data for testing weather widgets, chart tools, and time-series import.
The daily forecast as a JSON array: the format twin of the CSV, for import and charting tests.
A well-formed XML catalogue with nested elements and attributes, for testing XML parsers and XPath queries.
A YAML configuration file with nested mappings, sequences, inline lists, and comments, for testing YAML parsers.
