Populate the 13 domain files with a starter Knowledge Base (188 entries) covering the reference test scenarios (single/two characters, interactions, indoor/outdoor, fantasy, modern) per MASTER_SPEC §16. - appearance.json: character identity, general appearance, hair, eyes, face. - clothing.json: garments plus worn accessories. - anatomy.json (body), expressions.json, poses.json, actions.json, interactions.json, objects.json, environments.json, camera.json, lighting.json. - quality.json / style.json: reserved, empty in V1 (not auto-generated). - Synonym aliases (girl/woman/lady -> female, boy/man -> male, etc.). - Exactly two deterministic expansions: school_uniform -> blazer + pleated_skirt; twin_braids -> braid. No speculative expansions. - Exactly one valid category per entry; no subjective concepts. The whole dataset validates with zero findings via the KB validation tooling (#9), so the loader (#7) accepts it. A test loads the shipped dataset, asserts clean load, checks core concepts across every reference scenario, verifies synonym aliases resolve, confirms the deterministic expansions and their targets, and guards against subjective concepts. Co-authored-by: kunail0804 <kunail0804@gmail.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Knowledge Base
The Knowledge Base is data only — no executable code (MASTER_SPEC §15). It is the single source of truth for how semantic concepts map to Illustrious tags. The compiler loads every file here once during initialization.
File organization
Concepts are split into multiple JSON files by domain, for readability and maintenance (§15.3). The compiler loads and merges all of them:
knowledge_base/
appearance.json clothing.json anatomy.json expressions.json
poses.json actions.json interactions.json objects.json
environments.json camera.json lighting.json quality.json style.json
Domain files are a maintenance convenience; a concept's category (below), not the file it lives in, determines its behaviour.
File format
Each file is a JSON array of entries:
[
{ "id": "long_hair", "tags": ["long hair"], "category": "hair" },
{ "id": "blue_eyes", "tags": ["blue eyes"], "category": "eyes" }
]
A complete worked example (with an alias and an expansion) is in
examples/knowledge_base.example.json.
Entry fields
Each entry validates against the knowledge_base_entry schema
(schemas/json/knowledge_base_entry.schema.json).
| Field | Required | Rule |
|---|---|---|
id |
yes | Canonical ID: lowercase snake_case, globally unique across the whole Knowledge Base. |
tags |
yes | The Illustrious tags this concept generates. At least one. Order is preserved. |
category |
yes | Exactly one of the 19 canonical categories (see below). |
aliases |
no | Alternative expressions resolving directly to this entry (no alias→alias chains). Globally unique, and must not collide with any id. |
expand |
no | Additional canonical ids automatically added during resolution. References canonical ids only, never raw tags; targets must exist. |
deprecated |
no | Marks an obsolete concept; it keeps working but the compiler emits a warning. |
notes |
no | Free-form documentation for contributors; ignored during compilation. |
Contributor rules
iduniqueness — every canonicalidis unique across all files.aliasuniqueness — every alias is unique across all files and never equal to anyid; aliases resolve directly to their entry (no chains).- Tag order — the order of
tagsis significant and preserved in output. - Category — must be one of the 19 categories; the authoritative set is
defined once in
compiler/common/categories.py. - Expansion —
expandlists canonicalids only; every target must exist. - At least one tag — every entry generates one or more tags.
Per-entry structure is enforced by the entry schema. Cross-entry rules (global uniqueness, expand targets exist, no alias chains) are enforced by the Knowledge Base validation tooling.
The 19 categories
character, appearance, hair, face, eyes, expression, body,
clothing, accessories, pose, action, interaction, objects,
environment, camera, lighting, style, quality, miscellaneous.
style and quality are reserved for workflow integration (not generated
automatically in V1); miscellaneous is a fallback that should stay nearly empty.