# Player agreements / program boundaries

Owner clarification: 2026-09-22. This records RP participation design, not legal advice or a claim of enforceability. No agreement-signing backend is connected.

## Two independent projects

| Dimension | Hardcore 64 | DGen / Wall of Degenerates |
|---|---|---|
| Server | NoPixel 4.0 | NoPixel 5.0 / V |
| Scope | Character stakes, conduct, qualifying encounters, permaroll outcomes | Opted-in observation, crime interpretation, scene credit, publication |
| Cap | 64 simultaneously active hardcore characters within the user-specified 240-character city | No participant cap supplied |
| Roster | No confirmed hardcore roster supplied | Harry, Reed, Luka_Aus are organizer-reported onboard |
| Draft version | hardcore64-4.0-draft-0.3.1 | dgen-5.0-draft-0.1 |

One shared Discord identity can own multiple characters and participation records. Each acceptance remains scoped to a program, server, character or channel, and version. Channel-observation permission does not accept character-death stakes. Imported roster names are not acceptance records.

## Purpose of the hardcore compact

Jack's direction is a voluntary public commitment to contribute more to the shared city while risking an established character's money, influence, relationships, and future. Accept good and bad outcomes, take responsibility for junior members, and leave opportunities for rivals, PD, EMS, civilians, and newcomers. The value is the RP created in 4.0 now. It is not an official audition, invitation guarantee, moral ranking of players, death quota, or server-wide wipe.

Version 0.3.1 is the ten-rule workshop draft. It adds “Play what your character knows” as rule ten; existing proposed operating terms remain unresolved. The following conduct principles reflect the owner's direction; the operating safeguards below are proposals requiring agreement before use.

- Respond to others and give them meaningful opportunities to affect a scene. This does not promise equal firepower, escape, a monologue, or a preferred ending.
- Permit surprising, violent, asymmetric, or short scenes when their context and the accepted terms support them. Scene length alone cannot determine eligibility.
- Judge observable conduct and story context. Fame, affiliation, player tenure, audience size, and shooting ability are not proxies for good or bad conduct.
- Do not exploit the existence of a perma pledge as a target or use proxy participants and staged handoffs to bypass the accepted scope.
- Accept a fair loss, including the aftermath. Disappointment, an unplanned ending, or lack of a cinematic farewell does not invalidate an otherwise eligible outcome.
- Give inexperienced players opportunities and feedback. Do not infer consent from participation in an ordinary scene, nor exclude people merely because they are new.
- Keep streams, DGen interpretations, public pledge lists, and private out-of-character discussions out of character decisions. A visible hardcore pledge is not an in-character motive. Establish knowledge through roleplay; server rules take priority over this compact.
- Keep viewer pressure, accusations, and dogpiles out of the process. Players' public commitments do not authorize an audience to demand a perma or adjudicate conduct.

### Proposed encounter and dispute safeguards

Before activation, settle the qualifying attacker/opponent scope, escalation expectations, participation opportunity, capture/handoff/proxy cases, PD scope, roll mechanism, and exceptions. There is no agreed minimum scene duration or universal warning requirement. The original hardcore-versus-hardcore trigger remains a proposal.

For a disputed permanent outcome, the proposed process is to identify a specific accepted term, consider the full relevant scene and both players' accounts, and use a process accepted in advance. Resolve eligibility before executing a contested permanent outcome. Choose how a decision becomes binding, conflict-of-interest handling, deadlines, and what happens if the players cannot agree; a complaint must not create an indefinite veto or an automatic reset. These are open design decisions, not a live review service. AI interpretation, chat votes, and clipped popularity contests cannot authorize a perma.

Prospective withdrawal and what happens to already-triggered or disputed scenes must be explicit before acceptance. Withdrawal from stream observation stops future collection under that permission; it must not silently rewrite separate character-stakes history. Define past-publication removal and evidence retention separately. Do not implement either irrevocable consent or retroactive deletion of an outcome by assumption.

### Consent and public participation

Record character-stakes acceptance, permission to show a public participation pledge, stream-observation permission, and interpretation/scoring publication permission as distinct choices with defined scope. Hardcore participation must not automatically turn on DGen. A streaming channel being public is not project consent. A participant's permission does not enroll other people appearing in their stream or authorize creating ranked profiles for them. Set a publication/redaction policy for incidental players before going live.

Friendly conversations, interest, and organizer-reported onboarding are not verified acceptances. Do not add prospective hardcore players to an accepted roster. Do not publish unrevealed in-character plans or personal background from workshop conversations in any site asset, downloadable document, example, or public feed.

## Proposed acceptance record

For a future implementation, retain an immutable record containing `acceptance_id`, verified `player_discord_id`, `program_id`, `server_era`, `character_id`, optional verified `channel_id`, `agreement_version`, document hash, acceptance timestamp, and applicable observation/publication permissions. The server must derive the verified account and accepted document version rather than trusting a client assertion. Keep subsequent revocation/amendment records; do not overwrite historical acceptance.

These fields are a proposed implementation shape. Do not create fake signed records from a profile draft, a chat quote, organizer-reported onboarding, or an incoming bot payload.

## Hardcore 64 participation

Enrollment/acceptance and an active hardcore slot are different states. A possible lifecycle is draft → accepted → active → inactive/closed, but activation, reservations, disconnects, and termination rules still need an owner decision.

Enforce the cap of 64 concurrent active characters atomically on the server when this backend is implemented. A front-end count or browser-local flag cannot enforce it. This is not a separate 64-player server, not a limit of 64 lifetime signers, and not a quota for deaths. At the supplied capacity, 64/240 is about 26.7%; it is neither the perma probability nor a promise of one hardcore character per vehicle.

The accepted agreement defines eligible downs, attacker/opponent scope, PD encounters, roll odds, exceptions, dispute handling, and outcome acknowledgment. The earlier hardcore-versus-hardcore trigger is a proposal, not the only possible final scope. Deeper PD/EMS/witness stories are intended consequences of the RP; other players do not inherit character-death obligations merely by entering a scene.

## DGen participation

Maintain a separate 5.0 crime catalog and rubric version. Link observations to verified opted-in channels and the relevant agreement record. Count activity, interpretations, and confirmed outcomes separately. No observed down or model prediction signs a hardcore agreement or orders a permanent death.

Observation/consent verification, publication timing/redaction, evidence retention, reviews, appeals, and scoring weights are unfinished. The current API validates payload shape only.

## Reusing the rubric in 5.0

A 5.0 group may choose the hardcore rubric. Create a separate adoption/version scoped to that group, then obtain the applicable player/character acceptances. Do not reuse DGen observation consent, import a 4.0 acceptance, or automatically inherit the 64/240 capacity model. Reuse ideas and definitions; preserve project-specific agreement records and history.