Bundle-level metadata has no slot — collection-scoped fields (licence, upstream provenance) in a multi-corpus deployment

Hi — thanks for publishing OKF. We're adopting it in an enterprise knowledge platform and hit one structural gap early. Flagging it now rather than after the fact, since we intend to propose something and would rather build in the direction you're already heading.

## Context

We're running roughly **36 OKF-shaped bundles, ~4,370 concept documents**, mostly mirrors of external corpora (public engineering handbooks, open guides, reference works) adopted into a governed internal platform. OKF's model fit almost immediately — our mirrors were already markdown-with-frontmatter, and bundle-relative links already formed the graph. That part needed no convincing.

## The gap

**There is no home for collection-scoped metadata.**

Some facts are properties of a *bundle*, not of any concept within it:

- where the corpus was mirrored from, and **at which upstream commit** (without this a bundle is a snapshot, not a reproducible asset)
- the licence and attribution terms governing the whole collection
- when it was adopted, and by whom

Today the spec offers nowhere to put these:

- `index.md` is reserved and carries **no frontmatter**
- `log.md` is prose change history
- per-concept frontmatter works, but replicating a collection-level licence across ~1,100 files in a single bundle is unmaintainable, and creates 1,100 places for it to drift

The practical consequence for us is that governance facts end up in an out-of-band file that no OKF consumer knows to read — which undercuts the portability that makes OKF attractive in the first place.

## What we're prototyping

A `/*.yaml` sidecar holding collection-level defaults, with simple inheritance: **concept frontmatter wins; absent ⇒ inherit from bundle; absent at both ⇒ a declared fail-safe default.**

We chose a sidecar because the spec reserves only `index.md`/`log.md` and treats all other `.md` as concepts, so a non-`.md` file at bundle root appeared to be the least invasive option. We may well be wrong about that.

To be clear about scope: **we are not asking OKF to absorb our governance vocabulary.** Trust, confidence and attestation fields are specific to our platform and belong in our own extension namespace under the "preserve and tolerate unknown fields" rule — which, incidentally, is the single most useful sentence in the spec for adopters. **We're only raising the question of where bundle-scoped fields should live at all.**

## Questions

1. Is bundle-level metadata in scope for v0.2, or deliberately excluded?
2. If in scope, which shape would you prefer — a sidecar file, frontmatter permitted on `index.md`, or a reserved concept document (e.g. `bundle.md`)?
3. Is there prior art or an existing convention among early adopters we should follow instead of inventing one?

## Offer

We intend to submit a concrete proposal with a working reference implementation **by 11 August 2026**, backed by deployment data across the corpora above — including what broke. If you'd rather we shaped it differently, or the answer is simply "out of scope", that's genuinely useful to know now and we'll carry it privately instead.

Happy to contribute validation data from a multi-corpus deployment either way.

Review the OKF rules for index.md, log.md, concept frontmatter, and the reserved-file behavior described here. Compare the proposed /*.yaml sidecar with the index.md and bundle.md alternatives, then document a supported location, inheritance behavior, and validation expectations; done means the proposal resolves the three scope and shape questions without requiring repeated collection metadata.

Written by the indexing model from the issue text.