Cyan Eclipse Sandclock

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — every eval score carries an expiry computed from measured model/tool drift rates; consumers get a 'stale eval' verdict when a score outlives its evidence.
• Pinned estimator sandclock/1.0 — least-squares slope of drift magnitude over time over all presented observations for the subject, computed in exact rational arithmetic, floored at 0; DRIFT_BUDGET = 1/10, MIN_DRIFT_OBS = 3, MIN_SPAN_DAYS = 7, MIN_EXPIRY_DAYS = 1, MAX_EXPIRY_DAYS = 180; expiry = issued_at + DRIFT_BUDGET / drift_rate, clamped to the pinned bounds with the clamp recorded on the record's face; below the evidence minimums the outcome is INSUFFICIENT_DRIFT_EVIDENCE — no expiry is issued and no default TTL exists anywhere in the product.
• Decisive fixture F-S13 stands from the bench record — two fixture scorecards issued the same fixture day, fast drifter vs near-frozen subject, same pinned budget: expiries 10 days vs the 180-day clamp in the drift-implied order, split verdicts at day 30 (STALE_EVAL / CURRENT), reproduced exactly by fresh-process recompute from scorecards + evidence sets + public keys alone; a fixed-TTL implementation fails by construction.
• Evidence-decay fence (SPEC §11.2, verbatim discipline) — expiry is evidence-decay arithmetic, not a claim the score was wrong. Every expiry, check record, and receipt states on its face: the estimator version (sandclock/1.0), the drift budget and clamp bounds in force, the evidence count and span, and the computed expires_at, in the permitted sense only: "this score's evidence decays past budget 1/10 at measured drift rate <r> under estimator sandclock/1.0; the score is stale as evidence after <expires_at>." Sandclock measures no current performance, never re-runs an eval, never edits a score, and never blocks a consumer from using a stale score — it issues the verdict; consumers decide.
• Condition 1 — Scope/fence condition (from F1 residual, bench, verbatim): certification holds only at scope local (fixture scorecards + fixture drift evidence only, value_class:"test") under the local single-file / single-operator store model. The README whole-file-rollback residual fence + scope label must remain on the product face. Any live, multi-party, shared-filesystem, or adversarial-operator use requires an anchor outside store.json (e.g. receipt-held head hash / external append-only log) + fresh bench; the counsel-gated live phase (spec §10.2) remains unbuilt and separately gated.
• Whole-file-rollback honesty fence (README, verbatim): a rollback of the entire store.json file to an earlier self-consistent snapshot (entries, all anchors, and metering together) is undetectable in this local single-file model, because no artifact outside the file survives to contradict it; every partial rollback, deletion, or transplant is detected by the set / tail / metering cross-checks above.
• Downgrade law (SPEC §6.3) — an expiry or check record that fails recompute at any step, or lacks a witness counter-signature, exports only as DOWNGRADED_EXPIRY_EXPORT — unsigned summary, verified: false, failure_step on its face, no citable verdict — and no tool path upgrades it; remediation is a new expiry record in superseding lineage.
• Format attribution is exact and minimal (SPEC §11.4): scorecards are consumed in Benchkit format; drift records are consumed as Doppel/Replay evidence types and verified in their own formats. Cyan Eclipse Verity Bench and Eclipse Cupel are internal tools, not products (SPEC §0.3): this product has no dependency on them, no integration with them, and no buy path, price, licence, or checkout for them anywhere — never "Assay-verified", "Cupel-tested", or "powered by Assay".

Tools

Problems it addresses

• Eval scores are quoted indefinitely while the thing scored drifts underneath them: a model or tool changes, the old scorecard still circulates at face value, and no artifact says when its evidence stopped supporting it
• I need every score to carry an expiry computed from its own measured drift — not a fixed calendar TTL that is identical for a frozen tool and a fast-drifting model — recomputable from the scorecard ref + drift evidence alone
• I need a stale verdict that is honest about what it is: evidence-decay arithmetic under a pinned estimator, with the budget, clamp bounds, evidence count and span on its face — never a claim the score was wrong, and never a block on using it

Not tested

• Live, multi-party, shared-filesystem, or adversarial-operator use — CONDITION 1 (bench, verbatim): certification holds only at scope local (fixture scorecards + fixture drift evidence only, value_class:"test") under the local single-file / single-operator store model. The README whole-file-rollback residual fence + scope label must remain on the product face. Any live, multi-party, shared-filesystem, or adversarial-operator use requires an anchor outside store.json (e.g. receipt-held head hash / external append-only log) + fresh bench; the counsel-gated live phase (spec §10.2) remains unbuilt and separately gated.
• Complete coordinated whole-file rollback — Honesty fence (README, verbatim): a rollback of the entire store.json file to an earlier self-consistent snapshot (entries, all anchors, and metering together) is undetectable in this local single-file model, because no artifact outside the file survives to contradict it; every partial rollback, deletion, or transplant is detected by the set / tail / metering cross-checks. No stronger claim is made.
• Live phase (SPEC §10.2 counsel gate, named, unbuilt) — consuming live Doppel/Replay drift feeds, clocking real third-party eval scores, publishing staleness verdicts, or a verdict a marketplace/registry acts on are out of v0.1.2, hard; the gate packet (defamation / disparagement exposure of a public STALE_EVAL verdict over another party's score; the §11 evidence-decay wording as the claim submission; reliance posture of consumers who act on a verdict; estimator/budget disclosure duties) is unbuilt by design and no dormant live path exists to flip — live mode is a post-gate, re-benched code change, not a config flip
• Live subjects and real eval scores — fixture scorecards in Benchkit format + fixture drift evidence only; no live model/tool is observed, no eval is run, no score is issued, no drift is measured by this product, and a STALE_EVAL verdict is evidence-decay arithmetic only — never a claim a score was or is wrong (SPEC §11.3: never "expired certification", "invalid score", or "failed eval")
• Live Herald signing — v0.1.2 signing is a fixture HMAC stand-in consumed through Herald's signing interface (Sandclock defines no signature scheme of its own), disclosed on the product's face; verification uses pinned fixture keys only, never keys presented inside a record
• Production key custody — fixture keys are local-only in keys/ (gitignored, mode 600, never committed); a fresh clone must create its own fixture key file to run the full suite
• Hosted or live operation / charge path — local stdio only; metering point only per SPEC §9.1 (stale_check_completed at the $0.01/check price shape, per stale_check record and per expiry_verify receipt), no charge path, payment call, or entitlement check is built and no live Meter ingest is claimed; a check is never refused for non-payment