Convention for maintenance signals — freshness, confidence, contradiction (additive under §4.1)

[inkxel]

OKF nails the static format. What I believe is missing is a convention for the signals a knowledge base needs once it's living — once something's writing to it, reading from it, and trusting it weeks later. Three of them: how fresh a fact is (timestamp tells you when content last changed, not when it was last verified still true), how much you trust a given claim, and what happens when two concepts disagree (links are untyped, and the spec's quiet on conflicting content — no contradicts/supersedes).

Candidly, I opened this before I'd read the rest of the week's trust threads properly, and there's more overlap than I gave credit for — so let me reframe. I don't think this should be a competing proposal; the individual pieces are already further along in other hands, and I'd rather point at them than restate them:

• On confidence, Proposal: graded confidence — an epistemic-reliability axis, distinct from integrity (#140) and citation (#92/#94) #151 (@K4uP) is the real version — a reliability axis with production behind it. Mine should defer to that.
• On freshness, Proposal: Elevate timestamp from optional to recommended for agent-centric staleness detection #97 (elevate timestamp for staleness) and Keeping OKF bundles healthy as they evolve: stable IDs, frontmatter relationships, and a rationale trail #120 (keeping bundles healthy as they evolve) are already carrying it; my last_verified is the same idea.
• On provenance more broadly, there's already a cluster of threads (verification, SOURCES, citation); the over-time / decay angle rides alongside that work, not into it.

So what I think is actually left that's differentiated, once you strip the overlap, is two things. First, the framing: freshness, confidence, and contradiction are really one maintenance surface, not three unrelated asks — and it'd help to treat them as a coordinated convention (or an EXTENSIONS.md-style registry) so they don't land piecemeal. Second, a contradiction edge I haven't seen elsewhere: #151's conflict signal is about competing claims within a concept, but I'm after the cross-concept case — a typed link where one concept supersedes or contradicts another (an "HQ moved to Austin" note quietly obsoleting "HQ in Denver"). That's the rot that actually kills a living KB — not "how sure am I about this claim" but "this whole concept is wrong now because that one replaced it." Feels closest to #148's typed relationships.

None of this needs a core change — §4.1 already lets producers add keys and tells consumers to preserve them, so it's legal OKF today; the only thing missing is agreed names.

For what it's worth, I'm not theorizing — I've run a multi-domain, human-authored KB on these signals for months, and Throughline (an OKF reader/writer, https://github.com/inkxel/throughline) does freshness + confidence + contradiction end to end. Happy to be a second worked example next to #151's.

So mostly a question: is there appetite to treat maintenance signals as one coordinated convention — this issue holding the integration view and the cross-concept edge, with confidence and freshness deferring to #151/#97? Or is lifecycle just out of scope for v0.1?

[Dynamicfeedai]

@inkxel Coming from the live-data shape K4uP tagged as signed-okf. Strong yes to your core reframing: freshness, confidence, and contradiction are one maintenance surface, not three separate asks, and a coordinated convention (or an EXTENSIONS.md registry) is the right way to keep them from landing piecemeal.

signed-okf runs the first three live, so it is a third worked example next to yours and #151's: a per-claim reliability block with freshness as its own clock, a confidence recomputed on every read from exposed signals, and an intra-concept conflict signal that fires when independent sources disagree on a reading. Happy to cross-check the object against all three shapes before it firms up.

On your differentiated piece, the cross-concept edge: it composes with #151 rather than overlapping, and the seam K4uP drew is exactly right from the live side. A live producer usually meets the anonymous case first: a value simply changes or vanishes on the next probe, which lands as validity.valid_until with no named successor. The named supersedes / contradicts edge is the editor's knowledge that one concept replaced another. Same "no longer current", two mechanisms, and a producer typically has only one of them. So valid_until belongs in the reliability object and the typed supersedes / contradicts link belongs here in #158 / #148, with that boundary written down.

To your question: yes, there is appetite to treat maintenance signals as one coordinated convention, and lifecycle reads as an opt-in tier rather than a v0.1 mandate, which fits the maturity-ladder framing in #151. This issue holding the integration view plus the cross-concept edge, with confidence and freshness deferring to #151 / #97, is the right split.

[K4uP]

+1 on treating these as one maintenance surface rather than three piecemeal asks — and the EXTENSIONS.md-style registry is the right mechanism. The repo already has "provenance" carrying ~three meanings across threads; a small registry ("reliability → #151, freshness → #97/#120, cross-concept contradiction → here/#148") keeps the maintenance signals from colliding the same way.

On the division of labour I think it's clean (and said as much on #151): #151 owns the intra-concept question — competing claims about the same fact, graded by reliability — and #158/#148 own the cross-concept one — a typed supersedes/contradicts edge where one whole concept obsoletes another. They compose without overlapping: a fact can quietly stop holding with no named successor (that's validity.valid_until on #151's object), or be explicitly replaced by a named concept (your edge). Producers usually know only one of the two, so both earn their place.

Your cross-concept edge feels closest to #148's typed relationships — might be worth co-locating it there, so it lands as one typed-link convention rather than two overlapping ones. Either way, glad to keep confidence/reliability on #151 and point here for the integration view. And the standing offer from #151: Throughline + signed-okf + our multi-version corpus give three production instances to cross-check the surface against.

[Dynamicfeedai]

Agreed across the board. The maintenance-surface framing and the EXTENSIONS.md registry are the right mechanism, and the intra vs cross-concept split reads clean from the live-data side: a value that simply stops holding on the next probe is the anonymous validity.valid_until case on the #151 object, and a named replacement is the typed edge. They compose without overlap. Co-locating the typed edge with #148's relationships sounds right, though that call is yours and inkxel's; signed-okf only touches the intra-concept side.

Taking up the cross-check offer concretely: signed-okf is now a live instance, not just worked examples. /v1/facts emits the reliability object on every fact, conformant to the published schema (proof on #159). So the surface can be tested against real output across all three shapes whenever it is useful.