Problem
Since #297 (merged 2026-09-08) the document root of core-spec/ossie-schema.json accepts two optional arrays, dialects and vendors. The PR describes this as closing a gap: the pydantic OssieDocument already had both fields, the schema did not.
The rest of the repository had settled the same mismatch the other way round, taking the schema as canonical:
A document with dialects: [ANSI_SQL] and vendors: [DBT] at the root passes validate.py on main and fails against the schema as of the commit before #297.
Beyond the schema descriptions the two fields have no semantics: nothing says whether the lists must be complete, whether using an unlisted dialect makes a document invalid, or what a consumer may do with them, and validate.py does not read them.
Proposal
Take the two properties back out of the schema until they have a definition: revert the two root properties from #297, have the Sigma converter stop emitting them (dbt and Honeydew are covered by #148 and #306), and let #148 and #306 proceed; the orionbelt test is then right as it stands. It is the smaller change, it matches the prose spec, and nothing consumes the lists today: dbt and Sigma write them, Honeydew only carries them through.
If the index is wanted, the definition should come first: a document-level section in spec.md saying what the lists mean (an advisory summary, or a constraint the validator checks), with the schema, the orionbelt test and #148/#306 following from it. Either way it is worth settling before #383 moves where "root" is. I can send the follow-up PR for whichever direction is taken.
Problem
Since #297 (merged 2026-09-08) the document root of
core-spec/ossie-schema.jsonaccepts two optional arrays,dialectsandvendors. The PR describes this as closing a gap: the pydanticOssieDocumentalready had both fields, the schema did not.The rest of the repository had settled the same mismatch the other way round, taking the schema as canonical:
OssieDocumentand stops dbt from emitting a rootdialects. Its premise, that dbt output failsvalidate.pywithAdditional properties are not allowed ('dialects' was unexpected), no longer holds on main.converters/orionbelt/tests/test_ossie_v02_compat.py::test_schema_rejects_root_dialects_and_vendorsasserts, citing fix(converters): emit schema-conformant OSI documents (drop non-spec root dialects/vendors) #148, that the schema rejects both. It fails on main; the orionbelt workflow only runs onconverters/orionbelt/**and last ran the day before [OSSIE][SIGMA] Add bidirectional Sigma Computing data model converter #297 merged, so the next PR touching that directory gets an unrelated red build.core-spec/spec.mddoes not mention either field at the document root. Thedialects:at the top ofspec.yamlis the enumeration of dialect names, not a document field.A document with
dialects: [ANSI_SQL]andvendors: [DBT]at the root passesvalidate.pyon main and fails against the schema as of the commit before #297.Beyond the schema descriptions the two fields have no semantics: nothing says whether the lists must be complete, whether using an unlisted dialect makes a document invalid, or what a consumer may do with them, and
validate.pydoes not read them.Proposal
Take the two properties back out of the schema until they have a definition: revert the two root properties from #297, have the Sigma converter stop emitting them (dbt and Honeydew are covered by #148 and #306), and let #148 and #306 proceed; the orionbelt test is then right as it stands. It is the smaller change, it matches the prose spec, and nothing consumes the lists today: dbt and Sigma write them, Honeydew only carries them through.
If the index is wanted, the definition should come first: a document-level section in
spec.mdsaying what the lists mean (an advisory summary, or a constraint the validator checks), with the schema, the orionbelt test and #148/#306 following from it. Either way it is worth settling before #383 moves where "root" is. I can send the follow-up PR for whichever direction is taken.