Problem
OpenKnowledge can represent provenance-related metadata through OKF/frontmatter, but teams need a project-level way to validate provenance and freshness rules consistently. A shared knowledge base can currently contain documents without source identity, source revision, verification timestamps, or owners, and there is no standard machine-readable report that distinguishes blocking defects from advisory staleness.
Use case
For a knowledge base compiled from external systems, a team wants to require provenance fields by document type or folder, detect documents past their freshness window, and run the checks in CI without making normal editing cumbersome.
Proposed direction
- Allow project configuration to declare required provenance fields and freshness policies per document type or folder.
- Provide a CLI validation/lint mode that emits stable JSON counts and exit statuses.
- Distinguish blocking defects (for example, invalid frontmatter or missing source identity) from advisory findings (for example, stale content or missing owner).
- Surface provenance and freshness status in the editor where practical.
- Keep the model compatible with OKF v0.2 and extensible for project-specific fields.
- Report evidence and findings; do not automatically resolve conflicting claims or rewrite canonical content.
Acceptance criteria
- A project can declare required provenance fields and a freshness policy.
- Validation reports missing/invalid provenance and stale documents separately.
- CI can fail on selected blocking findings while allowing advisory warnings.
- JSON output is suitable for dashboards and pull-request checks.
- Existing projects without these rules continue to work unchanged.
Please advise whether this belongs in the core content-rules/CLI surface or should be implemented as a first-party plugin.
Problem
OpenKnowledge can represent provenance-related metadata through OKF/frontmatter, but teams need a project-level way to validate provenance and freshness rules consistently. A shared knowledge base can currently contain documents without source identity, source revision, verification timestamps, or owners, and there is no standard machine-readable report that distinguishes blocking defects from advisory staleness.
Use case
For a knowledge base compiled from external systems, a team wants to require provenance fields by document type or folder, detect documents past their freshness window, and run the checks in CI without making normal editing cumbersome.
Proposed direction
Acceptance criteria
Please advise whether this belongs in the core content-rules/CLI surface or should be implemented as a first-party plugin.