Problem
Two clauses in v0.2 become contradictory when Bless composes with the Starlight Runtime Fabric:
- SPEC §11.5 currently permits an instrument to be blessed when it does not conform to the non-waivable benevolence charter, as long as the reason names the non-conformance. SPEC §13 says those clauses are inherited downward and never relaxed. A nonconforming instrument can be recorded, but calling it whole weakens the charter.
- SPEC §12 names
palace/intentions.jsonl as an intention ledger. In a composed personal system, Second Brain OS is the canonical owner of private intention and decision context. Bless should not become a second canonical intention store.
Proposed normative clarification
- Change §11.5 condition 3 to require charter conformance. A nonconforming instrument receives a retained
WITHHELD or nonconformance record with reason and remedy; it does not receive a blessing or room until it conforms.
- Clarify §12 as the standalone/public-builder intention format. In a composed system, a Bless intention record MAY be a sanitized public projection of a canonical intention held elsewhere, and MUST carry the canonical record's stable id and full digest. It cannot silently override or fork that source.
- Keep Bless strictly witness-oriented: intention projections and withheld records remain evidence, never credentials, approvals, or activation tokens.
Acceptance criteria
- §11.5 no longer allows naming nonconformance to substitute for conformance.
- The retained refusal path is explicit and append-only.
- §12 distinguishes standalone ownership from composed projection.
- Projection linkage uses a stable id plus full SHA-256 digest.
- README and CHANGELOG state the boundary without implying a new runtime authority surface.
- Existing standalone v0.2 adopters remain valid; the clarification is additive except for the contradictory nonconforming-blessing path.
Why now
The Runtime Fabric authority review found that an approval, authority grant, intention, and blessing must remain distinct objects with one canonical owner each. This proposal closes the two places where Bless could otherwise become a competing truth or weaken its own non-waivable charter.
Problem
Two clauses in v0.2 become contradictory when Bless composes with the Starlight Runtime Fabric:
palace/intentions.jsonlas an intention ledger. In a composed personal system, Second Brain OS is the canonical owner of private intention and decision context. Bless should not become a second canonical intention store.Proposed normative clarification
WITHHELDor nonconformance record with reason and remedy; it does not receive a blessing or room until it conforms.Acceptance criteria
Why now
The Runtime Fabric authority review found that an approval, authority grant, intention, and blessing must remain distinct objects with one canonical owner each. This proposal closes the two places where Bless could otherwise become a competing truth or weaken its own non-waivable charter.