Skip to content

Proposal: withhold nonconforming instrument blessings and make intentions explicit projections #6

Description

@frankxai

Problem

Two clauses in v0.2 become contradictory when Bless composes with the Starlight Runtime Fabric:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions