Status: Accepted Date: 2026-09-17
Substrate content (ontology/eligibility/, ontology/behaviour/, ontology/instrument/, and their spec/, vocab/, shapes/, ontology/examples/) must remain usable without knowledge of any specific industry or deployment. Design discussion that references a specific applied use case is valuable for motivating and stress-testing a mechanism, but if substrate prose, naming, or worked examples are drafted by paraphrasing that discussion, the substrate ends up structurally shaped around one deployment’s inventory even when no deployment-specific term appears verbatim.
This project’s containment posture is deliberately lightweight: there is no requirement for a physically separate repository or an adversarial two-role review. Applied-layer or deployment-specific content may be authored anywhere in this repository at the user’s discretion, and committed or not at the user’s discretion. The one standing rule is about the direction of authorship for substrate content specifically.
Substrate content is authored in this order:
Applied-layer or deployment-specific material may be read for context and to sanity-check that a mechanism is sufficient, but it is never the source of substrate wording, class naming, section structure, or worked-example structure. Where a design conversation happens to reference a specific applied deployment, that reference stays in the applied-layer material — under WINGMAN/ or wherever the user directs it — and does not travel into substrate text, even in generalised or renamed form.
ontology/examples/ before README.md.README.md, spec/*.ttl, or vocab/*.ttl names a specific commercial deployment, brand, or closed-estate identifier, in any form.