Compatibility Packs That Prove Importers — Not Just Fill Folders

A large fixture catalogue looks impressive until a sibling product cannot import the "compatible" file. Novus Examples treats that failure as the point of the library. A file earns its place when it catches a distinct bug, proves an import contract, demonstrates an editor capability, or supplies a rights-cleared example a user can actually test.

That is why the September expansion work focused on checksum-pinned releases, restaurant import profiles, and sibling compatibility packs rather than on adding random extensions. Intentional pairs and conversion families stay. Accidental duplicates get review reports, not silent deletion.

Upload-ready is a claim about an importer, not about a zip folder. A restaurant kit may only carry that label after the real Novus Restaurant importer passes against the exact schema version, headers, types, required fields, valid and invalid fixtures, and expected normalized output.

The same rule applies to packs aimed at Background Remover masks, PDF forms and OCR, Visualizer audio, Convert round trips, and synthetic AI Stats exports. Each pack should name the bug or workflow it tests. A pretty filename is not evidence.

Seven restaurant gold kits cover menu, ingredients, recipes and costing, suppliers, inventory, sales, and pricing in CSV and XLSX, plus expected JSON and named failure cases. Import, rejection message, normalization, and export all have to verify. That is slower than shipping "sample menus," and it is why the kits are useful.

If you are building an importer, start from the kit that matches your job, run the happy path, then run every named failure. If your error message differs from the expected rejection, either your importer or the kit contract needs a revision — not a blog post that papers over the mismatch.

Use purpose and validity filters when they exist. Extension-only browsing returns volume; purpose browsing returns tests. Empty high-count cells in a coverage cube are warnings: they look like strength while hiding missing roles.

Prefer checksum-pinned releases when you need reproducibility. A floating "latest samples" folder that mutates under your feet cannot support a regression suite. Pin the release id in your test harness the same way you pin a dependency version.

A sibling app may claim compatibility with an Examples pack only when its importer consumed the exact fixtures and produced the expected normalized output or named rejection. Marketing copy that says "works with our sample files" without that gate is a bug in the claim, not a feature of the pack.

Convert round-trip packs should reopen downloads in an independent reader. PDF form packs should prove field fill and export. Mask packs should prove alpha contracts. Audio packs should prove decode and duration expectations. Inventing a softer bar for one app breaks the library for everyone.

Invalid headers, missing required columns, wrong types, empty files, and encoding traps belong in the kit beside the happy path. An importer that only sees clean files will look finished until a real kitchen sends Tuesday's export.

Document the expected rejection text. Fuzzy matching that accepts any error string hides regressions where the product starts accepting bad rows quietly.

Document Studio edits and authoring capability are a different claim from importer compatibility. A file can be a great studio exercise and a terrible importer proof. Keep those roles labelled. The companion article on what edit means in Document Studio covers capability levels; this article stays on packs that prove imports.

1. Name the sibling importer and schema version the pack targets.
2. Include valid and invalid fixtures with expected outputs.
3. Pin checksums for the release you test against.
4. Record the date and tool versions used in the last green run.
5. Refuse upload-ready labelling until that green run exists.

When you verify compatibility packs, keep a short checklist: open the live surface, reproduce one happy path, reproduce one refusal, and write down what the UI actually said. Do not upgrade a refusal into a promise. Do not demote a shipped control into optional colour. If a teammate cannot repeat the check from your notes alone, the article is not finished.

When you verify restaurant gold kits, keep a short checklist: open the live surface, reproduce one happy path, reproduce one refusal, and write down what the UI actually said. Do not upgrade a refusal into a promise. Do not demote a shipped control into optional colour. If a teammate cannot repeat the check from your notes alone, the article is not finished.

When a pack is retired, say so in coverage notes rather than leaving a zombie download. Broken links teach users that Examples is decorative. Living contracts teach them it is infrastructure.

The September expansion program treated blog posts as verification aids, not as announcements. Each article names a shipped surface, a refusal, and a checklist a second person can run without asking the author what they meant. That discipline matters more than adjective density.

If you maintain fixtures or adapters, schedule a quarterly re-read of the linked tools. UI labels drift. Capability matrices gain rows. A post that still describes last quarter's button is worse than no post, because it teaches the wrong click.

When you update the product, update the article in the same change set whenever the claim changes. Dated updated fields are claims about content, not about builds. Do not bump them for whitespace.

Readers who arrive from search deserve the same honesty as readers who arrive from the homepage. Lead with the limit if the limit is the point. Hide the limit and you will spend support time unsaying the article.

Finally, keep media local to the blog paths: posters, captions, transcripts, and opt-in films. Do not couple product explanation to advertising configuration. The films exist to show the feature, not to invent a demand channel.