Background
The conservative-by-default rules in CLAUDE.md distinguish detected candidates from confirmed values for user-judgment keys. auto_detect = false marks a key as requiring human confirmation before any control, remediation, attestation, or persisted context may consume its value.
Today, .project/project.yaml and the in-memory context passed to the sieve orchestrator represent these values as plain dicts. There is no type-level distinction between "confirmed by a person" and "detected candidate not yet confirmed."
Problem
The safety property (unconfirmed values never leak into verdicts, remediation inputs, attestations, or persisted state) is enforced by convention and code review, not by the type system. A future change that hands a candidate dict to a code path expecting a confirmed value will pass type checks and tests but silently violate the constitution's conservative-by-default principle.
Proposal
Introduce a pydantic model in packages/darnit/src/darnit/config/ along the lines of:
ConfirmedValue[T] carrying the confirmed value plus provenance (who/when/how confirmed).
CandidateValue[T] carrying the candidate plus origin (which detector produced it, at what confidence).
- Loader for
.project/project.yaml returns a typed struct where user-judgment keys are ConfirmedValue | None (never a bare value).
- Control verification, remediation, attestation, and context-persistence code paths accept
ConfirmedValue only.
This makes the "unconfirmed cannot be consumed" property a type error rather than a review comment.
Scope
Framework-only change. Implementations can migrate opportunistically. Backward compatibility for existing .project/project.yaml files should be preserved (bare values continue to load, but land as candidates or errors depending on the key's auto_detect flag).
Related
CLAUDE.md conservative-by-default section
packages/darnit/src/darnit/config/ (context loading)
Background
The conservative-by-default rules in
CLAUDE.mddistinguish detected candidates from confirmed values for user-judgment keys.auto_detect = falsemarks a key as requiring human confirmation before any control, remediation, attestation, or persisted context may consume its value.Today,
.project/project.yamland the in-memory context passed to the sieve orchestrator represent these values as plain dicts. There is no type-level distinction between "confirmed by a person" and "detected candidate not yet confirmed."Problem
The safety property (unconfirmed values never leak into verdicts, remediation inputs, attestations, or persisted state) is enforced by convention and code review, not by the type system. A future change that hands a candidate dict to a code path expecting a confirmed value will pass type checks and tests but silently violate the constitution's conservative-by-default principle.
Proposal
Introduce a pydantic model in
packages/darnit/src/darnit/config/along the lines of:ConfirmedValue[T]carrying the confirmed value plus provenance (who/when/how confirmed).CandidateValue[T]carrying the candidate plus origin (which detector produced it, at what confidence)..project/project.yamlreturns a typed struct where user-judgment keys areConfirmedValue | None(never a bare value).ConfirmedValueonly.This makes the "unconfirmed cannot be consumed" property a type error rather than a review comment.
Scope
Framework-only change. Implementations can migrate opportunistically. Backward compatibility for existing
.project/project.yamlfiles should be preserved (bare values continue to load, but land as candidates or errors depending on the key'sauto_detectflag).Related
CLAUDE.mdconservative-by-default sectionpackages/darnit/src/darnit/config/(context loading)