# OPEN QUESTIONS — DESIGN ROUND 4
**Disagreements with the July 8 canon, stated sharply, with alternatives · July 8, 2026**

---

## 1. Catalyst and Luminary render wealth as standing — and that collides head-on with "deciding is never fundraising."

Organizations §4 defines Catalyst (≥$100K across Compute) and Luminary (≥$1M) as levels in the same ladder as Organizer and Builder. But the other six levels are earned by *doing* — bringing people, building, writing, being early. These two are held balances. If the gold pip renders identically for "kept eleven people engaged" and "has a million dollars," the pip's meaning collapses to status, and worse: a Luminary pip visible in a Forum discussion is a weight number by another name, precisely what §5's equal-token design spent itself removing.

**Alternative:** Catalyst/Luminary pips render **only in economic contexts** — treasury views, contract counterparty cards, funding proposals where capital standing is the relevant fact — and never beside a name in Forum discussion, sharing flows, or the thread. Same data, scoped rendering. If the founders want wealth levels visible everywhere, the honest version is to say so out loud in the spec, not to inherit it silently from the ladder table. The screens in this round render only earned levels (Organizer) pending the decision.

## 2. The promotion beat borrows the signature's gold ceremony for a moment nobody signed — this is the first crack in the gold grammar since R2.

System-wide, the full gold treatment (stamp + embers + haptic) has meant exactly one thing: *you committed an act*. The promotion beat (MOTION-ADDENDUM-R4 §2) reuses it for something that happened *to* you. I built it as specified because "a promotion should feel gold" is right emotionally — but the precedent is dangerous: next quarter someone will want embers on a birthday, then on a streak, and the seal will mean "the app is pleased."

**Alternative (recommended):** keep the promotion's gold *material* (card border, pip, Goudy) but replace the embers+stamp with the **door grammar** — the ground brightening +4% for one breath, the same light that announces an empty deck. Earned standing announced by light, not by the signature's fireworks. If the full ceremony stays, write the rule that makes it non-precedent: *embers mark acts and promotions, closed list, amendable only here.*

## 3. Command names will drift from their prose sentences, and the receipt render can't detect the lie.

The command receipt pairs a plain verb ("$310,000 leaves the treasury") with a named command (`transfer_usdc`). The sentence is written by the Drafter; the command is what executes. Nothing structural guarantees they match — and a receipt that renders a comforting sentence next to a command that does something subtly different is worse than no receipt, because it *launders* the command. This is the same class of failure as a misleading diff summary, in the one place members are being taught to trust the summary.

**Ask (build-side, but the render depends on it):** the prose sentence must be **generated from the command's parameters** by the Renderer — never hand-written per proposal — so sentence and command cannot diverge. Command families whose parameters can't yet generate an honest sentence (e.g. `modify_constitutional_rules`) render their raw name in the verb slot, ugly on purpose, until they can. Ugly and true beats smooth and unverifiable. If hand-written summaries are allowed anyway, the receipt needs a visible provenance mark distinguishing *rendered from parameters* vs *Drafter's words*.

## 4. "Trusted domain" is the wrong word in the UI, and the spec's own mechanics prove it.

Protocol §4 calls a TXT-bound domain "trusted." But the binding proves *attribution*, not virtue: it tells you who answers, not whether they're good. A member who reads "trusted" will hear *vetted* — and the first time a bound domain runs a scam, the word will have taught ten thousand members the wrong lesson at the protocol's expense. The mechanism is genuinely strong (DNS + chain, both public); the label oversells it.

**Alternative (rendered in 5d, flagged here for ratification):** the UI word is **accountable** — "accountable to Lightbrush, institution of record" — and the unbound state is **unverified — a stranger, not a threat**, with no red and no shield iconography anywhere. "Trusted" can remain a protocol-layer term of art; it should never reach a member's eyes. Also flagged: the ally's line "they can bind their domain in one line of DNS" is the right recovery path and should be a standard offer, not ad-hoc copy.

## 5. Institutions reload their enrolled members' Compute — invisible patronage inside a system that made voting equal.

An Institution can pay for up to ten members' Compute, ongoing (Protocol §2). Those members vote — equally, costlessly — in Forums deciding contracts that may benefit that Institution (5c is exactly this scene). The vote stays equal; the *livelihood* doesn't. Today nothing in the render distinguishes a member whose Compute is self-funded from one funded by the counterparty on the table.

**Alternative:** on the specific surface where it matters — a Forum proposal whose counterparty is an Institution — members enrolled with that Institution carry their existing enrollment mark (the small square chip they already wear) beside their words in the discussion. Not a scarlet letter: the same disclosure standard the weighted-listening grammar already applies to standing. No new data, no new judgment, just the existing fact rendered where it's material. Declaring it structurally (enrolled members can't vote on their Institution's contracts) is Foundation's call, not design's — but the render should not pretend the question doesn't exist.

## 6. The guild's featherweight render will be loved to death — it needs a stated promotion path before launch, not after.

Guilds are deliberately nothing: a name, some people, a sharing scope. That lightness is why people will use them — and usage is exactly how a guild becomes a de facto alliance (the Winter Crew starts collecting gear money in someone's personal wallet, because the guild can't hold it). At that moment the system's honest answer is "become an alliance," but nothing in the UI says so, and the member discovers the boundary as a wall.

**Alternative:** the ally watches for wallet-shaped behavior around a guild (money mentioned in its scope, recurring shared costs) and offers the promotion as a sentence: *"The Winter Crew keeps fronting each other gear money — want to make it an alliance, with a wallet of its own? Takes a minute; the name comes along."* One contextual action, already within the existing grammar (Foundation: an Alliance is always first — guilds would simply join that on-ramp). The anti-pattern to refuse: adding features to guilds (mini-wallets, guild badges) until they're alliances with worse guarantees.


---

## Resolutions

- **Q1 — RESOLVED, beyond the alternative:** holdings-based recognition does not exist at all. No role, badge, pip, or standing derives from balances; balances are never surfaced publicly or to other members, for any purpose of recognition. (Roles §2.)
- **Q2 — RESOLVED as recommended (Option A):** promotions are announced by light (the ground brightening); the gold ceremony marks signed acts and nothing else, forever. MOTION-ADDENDUM-R4 §2 (the promotion beat) is superseded accordingly. (Experience §2, Roles §2.)
- **Q3 — RESOLVED as asked:** the receipt's prose sentence is generated from the command's own parameters — never hand-written per proposal — so sentence and command cannot diverge; commands that can't yet generate an honest sentence render their raw name until they can. A build requirement of the graph service. (Protocol §3, Actions §2, Foundation §6.)
- **Q4 — RESOLVED, beyond both alternatives:** the word is **registered** (unbound: **unregistered — a stranger, not a threat**). Neither "trusted" nor "accountable" reaches a member's eyes as a verdict on an artifact — registration proves traceability only. The scope also grew: any domain, page, or artifact can register (DNS TXT, embedded code, or hash) via the decentralized registry and Kinship Code JWT claims. Read screen 5d's "accountable" labels as "registered." (Protocol §4, Actions §2.)
- **Q5 — RESOLVED, beyond the alternative:** structural recusal — members enrolled with an Institution cannot vote in Forums deciding that Institution's contracts (enforced at the vote command) — and enrollment is always disclosed as part of identity. (Protocol §2, Foundation §6, Actions §2.)
- **Q6 — RESOLVED as recommended:** the ally offers guild→alliance promotion when money-shaped activity appears; guilds never grow wallet features. (Actions §2.)
