Proposal: clarify that Bless witnesses use and never grants runtime authority

[frankxai]

Problem

Bless v0.2 defines a blessing as whole-at-this-moment closure, explicitly not promotion, ranking, or metaphysical change. Section 13 also says a coordinator may not grant a worker permission it does not hold.

A proposed “benediction as spawn authority” interpretation collapses those two layers. It could make a blessing ID look like a credential, lease, approval, or runtime grant—even though the weekly blessing is retrospective, has a seven-day soak, and was never designed as a security token. That would weaken both the ritual and the enforcement boundary.

Smallest change

Add one append-only normative section (proposed §14, final number at implementation time) clarifying:

1. A daily orientation, lineage record, intention, charter verdict, or blessing is evidence and constraint, never a credential, lease, approval, budget reservation, or capability token.
2. Runtime authority is issued and enforced by a separate policy system with its own trusted issuer, exact scope, expiry, revocation state, input binding, and action-time checks.
3. A runtime policy may require today’s dawn.md attestation as one activation precondition. That still does not append a blessing or make dawn itself the authority.
4. A blessing may cite immutable authority/action receipts after coherent use exists. It cannot authorize the action it witnesses or confer future power.
5. “No blessing → no spawn” should be rejected as terminology. The precise form is “no current activation evidence and valid runtime grant → no spawn.”
6. Bless should not absorb QAG/lease/WorkPacket schemas; those belong to the adopting runtime or policy substrate.

Add a short README boundary note beside the benevolence-charter section. No record-schema or template change is required.

What this would break

Any adopter currently treating a blessing ID as an executable authorization must migrate to a separate runtime grant. No compliant v0.2 blessing record changes, and existing blessings.jsonl, lineage.jsonl, intentions.jsonl, and room records remain valid.

Non-goals

• No agent runtime, key-management system, or authorization schema inside Bless.
• No daily blessing or streak.
• No claim about machine interiority.
• No weakening of §13’s inherited refusals.
• No change to the seven-day soak or whole-at-this-moment definition.

Acceptance criteria

• The spec states unambiguously that Bless witnesses; it does not grant machine power.
• Dawn may be cited by a separate PEP without becoming a blessing.
• The reference Queen runtime can link to the clarification without making Bless a dependency for execution.
• Existing validator remains green.
• Voice stays inside §7’s grounded register.

Related implementation evidence

The proposed Starlight Runtime Fabric reference separates a maximum-90-day signed Queen Authority Grant, maximum-24-hour Matins lease, single-use exact-input WorkPacket, and terminal lifecycle events from post-action Bless receipts. Production activation remains withheld pending durable state, key custody, actual metering, integration tests, and independent verification.