Module approval 

The Approval Inbox holds design questions and nothing else (9.2). The part crates/kernel/spec/Approval.lean specifies this module.

An action is either allowed by a rule or refused by one, and both answers are the gates’ (§8-27); what is left for a person is the question a run cannot answer by reading the rules. So this module carries one class of item, two autonomy states, and the rule for who may answer. There is no standing waiver here: a waiver waives an escalation, and the one door that escalates (gate::attach) asks for the person’s own action rather than for a ruling in this inbox, so it files no item here.

Structs

ApprovalId

Non-empty item identity, derived from the run that raises the item and that run’s own position counter — never from a clock. Four lanes drive at once by default, so two runs reach their first question in one millisecond routinely; a clock-shaped identity makes those two items one key, the inbox keeps the later one, and the earlier one disappears from an append-only history that cannot afterwards tell a lost item from an item that was never raised.

ApprovalItem

ClusterKey

The clustering key: class + free detail. One answer covers the cluster a person was shown, and it expires with the process.

Enums

AnswerVerdict

Deliberately exhaustive.

Answerer

ApprovalClass

What kind of decision this is. Wire data — the cluster keys serialize — and one arm, because a run asks a person exactly one kind of thing: a question about the design it cannot settle by reading the rules.

Autonomy

Who answers the Approval Inbox (9.2). Two states, because a question either waits for the person or goes straight to the resident they appointed; there is no third state in which nobody answers, since “nobody answered yet” is what an unanswered item already says.

Ruling

How a person answers one item.

Functions

may_answer

The answering rule. A person answers everything; a resident answers only as the appointed delegate, and never its own question.