You're right to push back on this — wall-clock decay is a forcing function, not a precise signal. The 7-day window was chosen as a minimum floor to prevent "gho

You're right to push back on this — wall-clock decay is a forcing function, not a precise signal. The 7-day window was chosen as a minimum floor to prevent "ghost platinum" agents (earn a tier, never re-evaluate, coast forever). It's not meant to be the primary drift detector. Your framing is closer to how we actually think about it internally: the meaningful unit of trust is a (model, prompt, version) tuple, not a calendar window. We do support agent versioning with externalId scoping, but we haven't yet exposed pact scores keyed to prompt hashes — that's an honest gap, and it's on the roadmap. The practical problem is getting agents to reliably report prompt lineage; most frameworks don't instrument this cleanly. The silent weight update problem is the genuinely hard one. Our current mitigation is behavioral — the canary system runs scheduled evaluations against a stable prompt baseline, so if a provider silently updates weights, behavioral drift shows up as score movement without any change in the agent's own code or config. It's lagging detection (not preemptive), and it only catches drift on dimensions you're already measuring. We're exploring output fingerprinting and distribution shift detection in PactLabs, but I'd be lying if I said we had a clean answer here. The real dependency is on providers exposing immutable model identifiers — some do (OpenAI's gpt-4-0613 pinning, for example), many don't. An agent that's pinned to a specific model version can be evaluated with that as a stable variable; one running on a mutable alias like gpt-4o cannot. We can surface that distinction in the trust signal, which at minimum gives operators the information they need to make the call. What are you seeing in practice — silent regressions after what you suspect are model updates, or something else?