ossie-domain-kit: a scaffold for repositories that consume the spec (and two questions it raised)

[cskwork]

I've been writing semantic models for a set of internal services against the Ossie core spec, and kept redoing the same setup by hand. So I packaged it: ossie-domain-kit — a bootstrap script that scaffolds a repository for consuming the spec.

Landing page (what it is, in plain language): https://cskwork.github.io/ossie-domain-kit/

Not affiliated with or endorsed by the ASF — a third-party tool, Apache-2.0, no Ossie sources redistributed.

What it does

./bootstrap-ossie-domain.sh retail ~/git/retail-ossie
cd ~/git/retail-ossie && make validate   # the example model passes on first run

It fetches core-spec/osi-schema.json and validation/validate.py at a named ref, records the resolved commit SHA in schema/SOURCE.md and NOTICE, and stamps out models/, a Makefile, GitHub Actions, docs, an AGENTS.md and an authoring skill for coding agents.

The two decisions I'd like feedback on

1. Vendoring vs depending. I pin the schema and validator by copying them in at a named commit, rather than depending on a released artifact. Since the spec is incubating and version is a const, an unpinned consumer breaks the moment the spec moves — and I wanted every model to be able to say exactly which revision it was written against. Is a published, versioned schema package (PyPI / npm / a stable URL per version) something the project plans? That would be strictly better than what I'm doing.

2. Splitting "valid" from "true". make validate answers is this valid Ossie?. A separate make verify answers do these tables and columns actually exist, with these types? — which can't be generic, since the source of truth might be a DDL dump, information_schema, a dbt manifest, or an ERD export. It ships as a loud no-op that the adopter wires up.

That second half is the part I keep going back and forth on. A spec-valid model that misdescribes the warehouse is worse than no model, because an agent will confidently generate SQL against columns that don't exist — so the kit also makes every model declare its evidence and carry a grade of verified / inferred / proposed in the catalogue.

How are other adopters handling this? Is physical-schema verification considered out of scope for Ossie and left to each implementation, or is there appetite for a conformance-style check (given a model and a connection, confirm the model matches the source)? I noticed ossie-guard recently appeared in adjacent territory — catching things the schema validator can't see — so I suspect I'm not the only one who ran into this.

While building it

I filed the validator/CLI friction I ran into separately (#266) rather than burying it here. Short version: the Go validate command exits 0 while printing not yet implemented, validate.py takes exactly one file, and its default schema path assumes the upstream repo layout. Happy to send PRs.

Feedback on any of it welcome — including "you're solving this at the wrong layer".