Context
An internal architecture review (2026-07-30) confirmed that Registry Notary validates but does not retain source_observed_at from Relay consultation results: RelayConsultationProvenance and stored issuance provenance carry only acquired_at (crates/registry-notary-server/src/relay_client.rs, crates/registry-notary-server/src/runtime/evaluation.rs). The only Notary freshness control is the federation-profile max_claim_result_age_seconds, which measures consultation-acquisition age, and Relay owns snapshot freshness through max_snapshot_age_ms (crates/registry-relay/src/consultation/executor.rs).
History shows this is the intended post-convergence model, not an accident: the 2026-07-14 consultation-only refactor removed the direct-connector source-observed-age PDP gate, renamed the federation field from max_source_observed_age_seconds to max_claim_result_age_seconds, and added a config test that rejects the old name (crates/registry-notary-core/src/config/tests/infrastructure.rs, federation_rejects_removed_source_named_fields).
Two documentation surfaces were not brought along:
docs/site/src/content/docs/spec/rs-pr-notary.mdx:128 (REQ-PR-NOTARY-025) says Notary derives freshness from "the verified Relay consultation provenance" and that stale required provenance must deny. A reader can take this as Notary-enforced source-observation age, which no runtime path provides.
products/manifest/docs/reference.md:171 says max_source_observed_age_seconds "runtime enforcement is in Registry Notary config". Notary config now rejects that exact field name, so the sentence is false. crates/registry-manifest-core/src/lib.rs still serializes the field on EvaluationProfileManifest although nothing enforces it.
Decision
Prefer narrowing the claims over building retention machinery, unless a 1.0 profile genuinely needs Notary-owned source-observation age (no current ticket or roadmap item requires it). Concretely:
- Reword REQ-PR-NOTARY-025 to state what ships: absent or malformed required provenance denies at consultation verification; acquisition-age staleness is enforced by federation
max_claim_result_age_seconds where configured; source-observation and snapshot freshness are owned by Relay's pinned contract (max_snapshot_age_ms).
- Correct the manifest reference row for
max_source_observed_age_seconds and decide the field's fate: remove it from EvaluationProfileManifest before 1.0, or re-document it as an informational public hint with no runtime enforcement. Removing is preferred; do not keep an unused slot.
- If instead source-observation freshness is declared load-bearing for 1.0, retain
source_observed_at in the verified result and stored provenance and bind a maximum age into the pinned contract — but record that decision explicitly before implementing.
Definition of Done
Context
An internal architecture review (2026-07-30) confirmed that Registry Notary validates but does not retain
source_observed_atfrom Relay consultation results:RelayConsultationProvenanceand stored issuance provenance carry onlyacquired_at(crates/registry-notary-server/src/relay_client.rs,crates/registry-notary-server/src/runtime/evaluation.rs). The only Notary freshness control is the federation-profilemax_claim_result_age_seconds, which measures consultation-acquisition age, and Relay owns snapshot freshness throughmax_snapshot_age_ms(crates/registry-relay/src/consultation/executor.rs).History shows this is the intended post-convergence model, not an accident: the 2026-07-14 consultation-only refactor removed the direct-connector source-observed-age PDP gate, renamed the federation field from
max_source_observed_age_secondstomax_claim_result_age_seconds, and added a config test that rejects the old name (crates/registry-notary-core/src/config/tests/infrastructure.rs,federation_rejects_removed_source_named_fields).Two documentation surfaces were not brought along:
docs/site/src/content/docs/spec/rs-pr-notary.mdx:128(REQ-PR-NOTARY-025) says Notary derives freshness from "the verified Relay consultation provenance" and that stale required provenance must deny. A reader can take this as Notary-enforced source-observation age, which no runtime path provides.products/manifest/docs/reference.md:171saysmax_source_observed_age_seconds"runtime enforcement is in Registry Notary config". Notary config now rejects that exact field name, so the sentence is false.crates/registry-manifest-core/src/lib.rsstill serializes the field onEvaluationProfileManifestalthough nothing enforces it.Decision
Prefer narrowing the claims over building retention machinery, unless a 1.0 profile genuinely needs Notary-owned source-observation age (no current ticket or roadmap item requires it). Concretely:
max_claim_result_age_secondswhere configured; source-observation and snapshot freshness are owned by Relay's pinned contract (max_snapshot_age_ms).max_source_observed_age_secondsand decide the field's fate: remove it fromEvaluationProfileManifestbefore 1.0, or re-document it as an informational public hint with no runtime enforcement. Removing is preferred; do not keep an unused slot.source_observed_atin the verified result and stored provenance and bind a maximum age into the pinned contract — but record that decision explicitly before implementing.Definition of Done
products/manifest/docs/reference.mdno longer claims Notary-config runtime enforcement formax_source_observed_age_seconds.