Parties

A Party is a Tower/System mechanic — a formal hierarchy primitive that the world recognizes and around which other mechanics (Mask circumvention, treasury, Bounty status) take account.

Parties are one of the tools the Simulation provides for Inhabitants to form Hierarchies. The mechanic is intentionally minimal: a way to declare “this set of Ascenders is associated,” with a few structural consequences. The richer social patterns that emerge — leadership, role differentiation, parties-of-parties — are Social Constructs that Ascenders build on top of the Party primitive.

Confirmed mechanics

Invite and membership. An Ascender joins a Party by accepting a Party invite. Membership is a binary state: an Ascender is or is not in a given Party.

Mask circumvention. A Party invite, once accepted, completely circumvents the Mask. Party members see each other’s true identity regardless of what Mask is being worn. See masks.md for the Mask-and-Party interaction in detail.

Bounty status is not auto-shared. A Party member learns who their fellow members are (Persona-reveal), but not that they are Wanted (Bounty-reveal). The Persona/Bounty separation at the Party boundary is canon. A Party member who wants to know whether their fellow members carry Bounties must learn that independently.

Treasury. Parties have treasuries — Treasury is a Faction or Party attribute (the Tower has no treasury). A Party treasury can fund Mundane Bounties issued by the Party, hold pooled Currency, or serve other purposes the Party chooses.

Bounty issuance. Faction Bounties and Ascender Bounties are detailed in bounties.md. The canonical taxonomy currently names Tower Bounties (structural), Faction Bounties, and Ascender Bounties — Party-issued Bounties as a distinct category are open canon. A Party may collectively act as an Ascender-Bounty Issuer, or may be subsumed under Faction Bounties if the Party is a Faction unit; both are open.

What’s not formalized

Everything beyond the above is open canon or self-evident. The design intent is to keep the Party primitive minimal and let social patterns emerge.

Open canon includes:

• Party size limits (if any)
• Party formation rules — does a Party form on first accepted invite, or by a creation action? Who can invite (any member, only an originator)?
• Party leaving — voluntary departure mechanics, kick mechanics, conditions
• Combat coordination — does Party membership affect threat-targeting, ally/non-ally status in combat, friendly-fire rules?
• Loot distribution — Party-level loot pool, individual rights, default rules
• Party-as-Bounty-Issuer — distinct category or covered by existing taxonomy?
• Dissolution — what happens to a Party with one remaining member? With zero?
• Hierarchies within a Party — leadership, ranks, roles (if any) — likely Social Construct territory rather than Tower/System

The Party-as-Faction-unit relationship is also open: whether Parties can be nested under Factions, whether a Faction is itself a kind of Party, or whether the two are orthogonal hierarchy tools.

Ally classification

The ally/non-ally distinction is load-bearing across other canon (Mask Un-Masking, Bounty Claim witness rules). Party membership is one clear basis for ally classification, but the full criteria are open canon.

Open questions for ally classification:

• Are Party members always allies for the purposes of Mask Un-Masking?
• Are Faction members allies?
• Are Sponsorship-graph linked Ascenders allies?
• Past allies (former Party members, former Faction members)?
• Is the classification per-encounter or persistent?
• Can an ally relationship be unilaterally revoked, or does it require mutual agreement?

A future allies.md may consolidate ally-classification canon once enough has been established.