Inspired focus domains.

The Inspired focus-domain dataset

Every subject the Inspired pipeline can shop for, the vocabulary each one uses, and the exact shape of the structured description its reader must return — extracted straight from the running code, not transcribed by hand.

Three files, generated at build time from src/domains.js:

| File | Rows | What it is | | --- | --- | --- | | domains.csv | one per domain | The catalogue: ids, aliases, subject nouns, exclusions, prompt fingerprints | | schema-fields.csv | one per domain × field | The structured description each reader fills, field by field | | domains.json | the same, nested | Both tables as one object, for anything that would rather not parse CSV |

Why this is worth publishing

GET /api/v1/domains gives you ids, labels and aliases. This gives you the part that actually determines what comes back: which fields the reader is required to fill for each subject, whether a field is a list or a string, and what it is for.

Two concrete uses:

• Know what you are getting before you spend a request. A fashion item carries layer, front_opening and fabric_finish; a furniture item carries placement, form and material_finish and has no front_opening at all. If you are mapping the response into your own schema, this is the mapping.
• Detect a prompt change without seeing the prompt. Each domain row carries analysis_prompt_sha256 along with its character and sentence counts. Pin the hash; if it moves, the reader's instruction changed and your expectations may need re-checking.

What is not in it

The prompt text itself. The dataset carries a hash and a length, not the instruction. The published article Ask for the shirt, get the vest explains the reasoning and quotes the clauses that matter; the verbatim prompts stay in the repository.

No results, no images, no user data, no search output. This describes the pipeline's inputs, not anything anyone has ever run through it.

Provenance

Generated by scripts/build-publications.js in the Inspired repository by importing src/domains.js and reading the live functions — so the row for a domain cannot drift from the code that serves it. Each build recomputes it and publishes the hashes of what it wrote.

The per-field purpose column is the one hand-written part: a short gloss per field name, maintained beside the generator.

Covers the five domains deployed at inspired.jetskibay.com in September 2026: fashion, furniture, devices, beauty, everything.

Attached are domains.csv, schema-fields.csv and domains.json from the Inspired
focus-domain dataset.

I am adding Inspired to a product catalogue tool. Our internal product record
has these fields: name, description, category, colour, material, shape,
condition_notes, and hardware_notes.

Using the dataset, not guesswork:

1. Build me a mapping table from each Inspired item field to one of our fields,
   per domain. I care about fashion, furniture and devices. Where a domain has
   no equivalent for one of ours, say so explicitly rather than picking the
   nearest field — I would rather leave it empty than fill it with the wrong
   thing.
2. Point out every field that exists in one of those three domains and not in
   the others, and tell me which of our fields would be empty as a result. I
   know front_opening is fashion-only; find the rest from the data.
3. Tell me which fields are lists rather than strings, and what their ceilings
   are, so I size our columns correctly.
4. For the fields with a closed vocabulary, give me the allowed values so I can
   make them an enum on our side instead of free text.
5. Write me a check that fails our build if Inspired's reading prompt changes
   for any of those three domains, using analysis_prompt_sha256. Pin today's
   values from the CSV.

One thing to be careful about: every field in this schema is required, so a
missing value in a response is not "the reader skipped it" — it means something
else went wrong. Do not design around optional fields that do not exist.