Resident Council platform model
The Resident Council uses small, independently deployed services rather than one application. Residents usually start at the Resident Council website.
Resident Council documentation covers:
- the Resident Council website, the public directory and information hub;
- Resident voting, which manages invitations, ballots, and published results;
- IHNYC Games, which publishes events, signup links, rosters, results, and standings;
- the RC Console, which manages the council roster, positions, terms, handover, and public-member publishing;
- the in-development mobile app shell and the decommissioned Gallery as lifecycle records.
House Desk and Pub remain discoverable from the Resident Council website, but they are separate products with their own repositories, access, permissions, releases, and documentation.
Separate product boundary
RC Console does not authorize House Desk or Pub operators. Affective Technologies publishes their canonical documentation at docs.ihnyc.affectivetech.com.
Public and protected surfaces
| Surface | Access model | Role |
|---|---|---|
| Resident Council website | Public, with protected data tools | Council information and service directory |
| Resident voting | Invitation or magic-link token; protected administration | Elections, ballots, and approved results |
| IHNYC Games | Public site; protected administration | Events, signups, results, and standings |
| RC Console | Protected council access | Council roster, terms, handover, and publishing |
Service map
flowchart LR RESIDENT["Residents and guests"] --> SITE["Resident Council website"] SITE --> VOTE["Voting"] SITE --> GAMES["IHNYC Games"] COUNCIL["Authorized council operators"] --> CONSOLE["RC Console"] CONSOLE -->|"public member feed"| SITE CONSOLE -.->|"role-owner feed only"| CASEWORK["Council casework"] SITE -.->|"external product"| DESK["House Desk"] SITE -.->|"external product"| PUB["Pub"]
The dotted product links show discovery, not shared administration or runtime dependence.
Common Resident Council patterns
- Public information remains available without administrator credentials.
- Protected areas use edge access controls and application checks appropriate to each service.
- Secrets are deployment configuration and never belong in documentation.
- Structured operational data is commonly stored in D1; files and generated artifacts may use R2.
- Public APIs use explicit response and error contracts documented in API contracts.
See Security model for trust boundaries and Naming conventions for exact RC vocabulary. For House Desk and Pub architecture, use the IHNYC Service Docs.