The net-revenue example relies on several linked concepts agreeing, so I would make validation operate on the bundle as well as each Markdown file. A definition can be valid YAML while linking to a schema field that was renamed or to a policy outside its declared scope.
A CI check could resolve every internal link and validate the referenced field identifiers before publishing a bundle revision. Then the runtime records that bundle revision with its evidence plan. This makes the proposed Git review cover relationships that otherwise fail only when an agent tries to traverse them.
Great point! Completely agree that validating individual Markdown/YAML files isn't enough when business definitions depend on multiple interconnected artifacts.
Bundle-level validation is essential to catch broken references, schema changes, and policy-scope mismatches before deployment.
I particularly like the idea of versioning the entire knowledge bundle and recording that revision alongside the runtime evidence plan. It adds traceability and makes debugging much easier.
This is where OKF can move beyond structured knowledge representation toward a more reliable, CI/CD-driven enterprise knowledge lifecycle.
Ahmet Özel
AI Engineer. Computer Vision, RAG and LLM agents.
The net-revenue example relies on several linked concepts agreeing, so I would make validation operate on the bundle as well as each Markdown file. A definition can be valid YAML while linking to a schema field that was renamed or to a policy outside its declared scope.
A CI check could resolve every internal link and validate the referenced field identifiers before publishing a bundle revision. Then the runtime records that bundle revision with its evidence plan. This makes the proposed Git review cover relationships that otherwise fail only when an agent tries to traverse them.