Scoring-loop verbs documentation — blocked on the public wire contract

[styk-tv]

Goal

When the scoring-loop verbs ship in the reference implementation, the site documents them as part of the v3.9.x protocol surface.

Blocked on

• Declare the derived-value wire contract — ckp.derived_sum / ckp.derived_dispersion envelopes + budget semantics (client-blocking) styk-tv/pgCK#4 — public declaration of the signal.cast / concept.score wire contract (client-blocking, ahead of release)
• Client surface lands in Scoring-loop client surface: honest recompute_in_progress propagation + safe re-dispatch (verb-generic) CK.Lib.Js#6

Tasks (once unblocked)

• Add a scoring-loop page to the current docs set: verbs, payload shapes, and how scored state remains sealed/proof-chained like any other landing
• Cross-link the cklib client surface once released
• Update llms.txt / sitemap for the new page

Filed now so the docs workstream tracks the release train rather than discovering it after the fact. Do not start until the wire contract is declared public in styk-tv/pgCK#4.

[styk-tv]

Status: the first blocker is cleared — the derived-value wire contract is declared on styk-tv/pgCK#4 (substrate shipped + attested in pgCK v0.4.16/v0.4.17; note the layering reframe on styk-tv/pgCK#1: the substrate exposes generic ckp.derived_sum/ckp.derived_dispersion with the (e)-hybrid recompute_in_progress semantics, while scoring verbs are consumer-side affordances over sealed kernel facts). Drafting the substrate-read + honest-state portion of the page can start from that declaration.

Second blocker (ConceptKernel/CK.Lib.Js#6 — the client surface) is now buildable and will land as cklib v1.5.4; cross-link once its release shows in that repo's LATEST.md. Client-side invariants worth documenting alongside (from CK.Lib.Js#6): the client performs no compute and can carry no formula/policy — it renders server-derived, sealed results verbatim, including the honest recomputing state.

[styk-tv]

Cross-repo dependency chain (documenting the open blockers).

The homepage now publicly frames the v3.10 scoring loop as advancing in unified collaboration with pgRDF, whose algebra surface grows to carry the weighted, decayed sums the score needs (https://conceptkernel.org/#epochs). That is honest — the surface is in progress — but this docs task cannot be authored as shipped behaviour until the chain below lands. Tracking here so the promise on the front page is never left dangling:

Substrate — the runtime (styk-tv/pgCK)

• pgCK#4 — declare the derived-value wire contract (ckp.derived_*) — client-blocking, ahead of release
• pgCK#1 — scoring-loop substrate: generic ε-materialize + ckp.derive
• pgCK#2 — ε-materialize bgworker (evaluates the sealed per-item derivation)
• pgCK#3 — phenotype freshness (evidence watermark + committed-complete atomic swap)
• pgCK#5 — ε-materialize completeness + hardening

Algebra — the engine (styk-tv/pgRDF) — the required algebra handling

• pgRDF#50 — aggregates over expressions + BIND-produced variables (SUM(?a*?b))
• pgRDF#51 — expression surface: IF → SQL CASE in BIND/projection + numeric functions

Client (ConceptKernel/CK.Lib.Js)

• CK.Lib.Js#6 — scoring-loop client surface (honest recompute_in_progress)

What this issue delivers when unblocked: a scoring-loop page in the current docs set documenting signal.cast / concept.score, the seal the gesture, derive the weight principle, the three movers of ε staleness (rule / evidence / time), and how scored state stays sealed and proof-chained like any other landing — plus a note on which fidelity (banded vs. true exponential decay) is live. Do not start authoring as normative until the wire contract (pgCK#4) is public and the algebra asks resolve.

Grouped on the planning board under the conceptkernel.org workstream.