docs(okf-v0.2): U7 resolved — the 'not:' family is an example, not a field

Zero occurrences in the v0.2 SPEC.md, zero in the v0.1 SPEC.md at the parent of
the migration commit, no reference in upstream's reference_agent source, and one
file in the whole bundle set. An undocumented hand-authored key, legal under
§14's unknown-keys tolerance — a demonstration of the open namespace rather than
a field to support.

The same sweep settles '# Cited by': body prose in two policy files, absent from
the spec, and independently DERIVED by the visualizer (viz.html:56) from sources.
Both fit the upstream pattern already visible in credibility scores and trust
tiers — OKF stores signals, consumers derive views.

Answering this needed the v0.1 spec text, upstream's source, and a whole-tree
grep at once, which is what the local pinned clone made possible. That is U8's
lesson applied rather than restated.
This commit is contained in:
Kjell Tore Guttormsen 2026-07-27 16:32:40 +02:00
commit 0a7a77d5a8

View file

@ -185,12 +185,34 @@ a hard requirement on D1's reader, not a nicety. Consumers **MUST NOT** reject o
missing optional frontmatter, unknown `type` values, unknown additional keys,
broken cross-links, missing `index.md`. `status` absent defaults to `stable`.
### U7 — One unresolved observation
### U7 — The undocumented keys in the reference bundle. RESOLVED 2026-07-27
`metrics/gross-margin.md` carries a `not:` family (`- term / why / instead`) that
we could not locate in the spec sections read. It is either a v0.1 field we never
enumerated or an undocumented one. **Not resolved**, recorded so it is not
mistaken for something already checked. It touches nothing in the tag.
we could not locate in the spec sections read. The question recorded here was
whether it is a v0.1 field we never enumerated or an undocumented one.
**Measured, and it is neither of the two things that would have mattered.** Zero
occurrences in the v0.2 `SPEC.md`; zero in the **v0.1** `SPEC.md` (451 lines, read
at the parent of the v0.2 migration commit `780fe9d`); no reference anywhere in
upstream's own `reference_agent` source; and exactly **one** file in the whole
bundle set uses it. So it is an undocumented, hand-authored key in a single
example — legal under §14's "unknown additional keys MUST NOT be rejected", and a
demonstration of the open namespace rather than a field. Nothing to support.
The same sweep settles a second one. `# Cited by` appears as a body section in two
`policies/` files and nowhere in the spec — but `viewer/templates/viz.html:56`
renders a "Cited by" heading, so the visualizer **derives** that view by inverting
`sources` across the bundle. The two files hand-author what a consumer computes.
Both fit one upstream pattern worth keeping in view, because it is the same
principle stated for credibility scores and trust tiers: **OKF stores signals and
consumers derive views.** A reverse-citation index is a view. Nothing here is
something a producer emits, so none of it reaches our doors.
Method note, since it is the point of U8: answering this needed the v0.1 spec
text, upstream's source, and a grep over the whole tree at once. All three became
available when the pinned tree was cloned locally (operator, 2026-07-27) instead
of fetched file by file.
### U8 — Per-claim attribution is a BODY convention, and we read only frontmatter