Proposal: optional authorising_event on graduation_history entries

[jjohare]

Summary

graduation_history records the approving human as a string:

{ "from": "local", "to": "remote",
  "approved_by": "human:alice@acme.dev",
  "timestamp": "2025-01-20T11:00:00Z" }

A consumer reading a graduated unit has to take that on trust. Since graduation is the boundary where a unit becomes readable by people who cannot ask anyone what happened, the approval is exactly the field most worth being able to check.

Proposal

Add an optional authorising_event to each graduation entry: an identifier for a signed decision record that carries the approval.

{ "from": "local", "to": "remote",
  "approved_by": "did:nostr:8f2c…",
  "timestamp": "2025-01-20T11:00:00Z",
  "authorising_event": "e3a1…" }

The field is opaque to the schema — it means "resolvable in whatever signed decision log this deployment keeps". In ours it is the event id of a signed Nostr approval event, which any reader can fetch and verify the signature of. A deployment with no signed-decision substrate omits the field and loses nothing.

Why additive is the whole point

Omitted when absent, so a unit written by an implementation that does not know the field round-trips byte-identically. We have this under test against the published knowledge_unit.json: it parses, and re-serialising rewrites no cq-defined field.

Suggested spec wording

authorising_event (optional, string) — identifier of a signed decision record that authorises this promotion, resolvable within the deployment's decision log. Where present, consumers MAY verify it and SHOULD treat a promotion whose authorising_event fails verification as un-graduated. Absence means the approval is asserted rather than attestable, which is valid; it is not evidence of a problem.

Reference implementation

colloquy-core (Apache-2.0, Rust) implements the field and the policy that a promotion to the public tier is refused without it. Happy to open a PR against docs/architecture.md if the direction is welcome.