Use Case
An operator or integrator authoring Registry Notary claim configuration. RS-DM-CLAIM Section 10 documents a set of invariants the configuration loader deliberately does not enforce at load — they surface only at request/evaluation time:
- Duplicate claim ids are not rejected; uniqueness is left to the operator (REQ-DM-CLAIM-001).
- Disclosure
default outside allowed is not caught at load; it surfaces as a request error when a result is rendered (REQ-DM-CLAIM-008).
- A rule
source naming an undeclared binding is not caught at load; the dangling reference surfaces when the source is read at evaluation (REQ-DM-CLAIM-006).
The default ∉ allowed case is the most consequential: a privacy-sensitive claim can load cleanly while its disclosure policy is internally inconsistent, and the misconfiguration only becomes visible on the first evaluation that renders the result — potentially in production.
Proposed Behavior
Validate these three invariants earlier — at configuration load and/or as a check in registryctl doctor — and fail fast (or warn) instead of deferring to a runtime error:
- Reject (or warn on) two claims sharing an
id.
- Reject a claim whose disclosure
default is not a member of its allowed set.
- Reject (or warn on) a rule whose
source does not name a declared source binding.
registryctl doctor already produces a structured validation report, so these could land there first without changing service startup semantics.
Boundaries
- Section 10 currently states these are intentionally not enforced at load ("stated so a reader does not infer an invariant the reviewed implementation does not enforce at configuration load"). This request is to move the check earlier (fail-fast validation), not to change runtime evaluation semantics.
- The
default ∈ allowed rule is a SHOULD in REQ-DM-CLAIM-008; a load-time check could reasonably be a warning rather than a hard failure to respect that modality.
- Privacy constraint: the
default ∉ allowed case can silently widen disclosure until first render — that is the motivation for surfacing it early.
Surfaced while reviewing the Stage-1 trust/privacy documentation against RS-DM-CLAIM §10. Spec refs: REQ-DM-CLAIM-001, REQ-DM-CLAIM-006, REQ-DM-CLAIM-008.
Use Case
An operator or integrator authoring Registry Notary claim configuration. RS-DM-CLAIM Section 10 documents a set of invariants the configuration loader deliberately does not enforce at load — they surface only at request/evaluation time:
defaultoutsideallowedis not caught at load; it surfaces as a request error when a result is rendered (REQ-DM-CLAIM-008).sourcenaming an undeclared binding is not caught at load; the dangling reference surfaces when the source is read at evaluation (REQ-DM-CLAIM-006).The
default ∉ allowedcase is the most consequential: a privacy-sensitive claim can load cleanly while its disclosure policy is internally inconsistent, and the misconfiguration only becomes visible on the first evaluation that renders the result — potentially in production.Proposed Behavior
Validate these three invariants earlier — at configuration load and/or as a check in
registryctl doctor— and fail fast (or warn) instead of deferring to a runtime error:id.defaultis not a member of itsallowedset.sourcedoes not name a declared source binding.registryctl doctoralready produces a structured validation report, so these could land there first without changing service startup semantics.Boundaries
default ∈ allowedrule is aSHOULDin REQ-DM-CLAIM-008; a load-time check could reasonably be a warning rather than a hard failure to respect that modality.default ∉ allowedcase can silently widen disclosure until first render — that is the motivation for surfacing it early.Surfaced while reviewing the Stage-1 trust/privacy documentation against RS-DM-CLAIM §10. Spec refs: REQ-DM-CLAIM-001, REQ-DM-CLAIM-006, REQ-DM-CLAIM-008.