Platform model
These are small, independently deployed services rather than one application. Residents usually start at the Resident Council website.
Each service has its own job:
- the Resident Council website is the public directory and information hub;
- the Programs calendar gives residents a verified subscription link for their calendar app;
- the Voting service manages invitations, ballots, and published results;
- IHNYC Games publishes events, signup links, rosters, results, and standings;
- the I-House Pub site serves public pages, in-venue displays, scheduling, and room integrations;
- the RC Console holds the current council roster, positions, handover, and selected service permissions;
- the Pub scheduler manages weekly availability, assignments, and schedule email inside the Pub service.
The retired Gallery service is preserved in these docs for historical context but is not part of the live platform.
The mobile app shell is in development and is not a released resident service.
Council and Pub are separate
RC Console does not manage Pub operators. Pub has its own planning board, admin permissions, Access policy, and deployment path. This site keeps both products’ technical documentation together; the products remain separate.
Independent services
A problem in one service does not automatically mean every service is down. Operators should use the runbook for the affected service and verify its own public page, admin health view, and dependencies.
Public and protected surfaces
| Surface | Access model | Platform role |
|---|---|---|
| Resident Council website | Public | Main information and service directory |
| Programs calendar | Public request flow; private random feed token | Issues and serves verified calendar subscriptions |
| Resident voting | Invitation or magic-link token | Accepts ballots and publishes approved results |
| IHNYC Games | Public site; protected administration | Publishes events, signups, results, and standings |
| I-House Pub | Public pages and displays; separately protected administration | Runs venue information, media, scheduling, and room integrations |
| RC Console | Protected council access | Holds council identity, roles, handover, and selected service authorization |
| Service admin surfaces | Protected per product | Provide deployment, configuration, moderation, and recovery controls |
Active service directory
| Service | Primary responsibility | Main runtime and storage |
|---|---|---|
| Resident Council website | Public content, updates, support links, and selected data tools | Cloudflare Pages, Pages Functions, R2 |
| RC Console | Council people, positions, terms, public roster, and service access | Cloudflare Worker, D1 |
| Programs calendar | Verified calendar subscriptions and generated ICS feeds | Cloudflare Pages, Pages Functions, D1, R2 |
| Voting | Elections, polls, invitations, ballots, and results | Cloudflare Worker, D1, Durable Objects |
| IHNYC Games | Events, signups, rosters, results, standings, and imports | Cloudflare Pages, Worker API, D1 |
| I-House Pub site | Public pages, admin tools, TV displays, scheduler, and live media systems | Cloudflare Worker, D1, R2, KV, Durable Objects |
| Pub scheduler | Weekly availability, assignments, and schedule email | Module of the Pub Worker using D1 |
High-level service map
flowchart LR resident["Residents and guests"] operator["Council and pub operators"] landing["Resident Council website"] calendar["Programs calendar"] vote["Voting"] games["IHNYC Games"] pub["I-House Pub site"] scheduler["Pub scheduler"] rcadmin["RC Console"] resident --> landing landing --> calendar landing --> vote landing --> games landing --> pub operator --> landing operator --> calendar operator --> vote operator --> games operator --> pub pub --> scheduler operator --> rcadmin rcadmin -->|"public member feed"| landing rcadmin -->|"role + action policy"| calendar rcadmin -.->|"role-owner feed only"| casework["Council casework"]
The arrows show common navigation and operational relationships, not a claim that one service must be online for another to run.
Common platform patterns
The services are separate, but they share several conventions:
- public content is available without admin credentials;
- protected admin areas use edge access controls and application checks appropriate to the service; Calendar asks RC Console for action-level authorization;
- secrets are provided as deployment configuration and never stored in these docs;
- structured operational data is commonly stored in D1;
- files and generated feeds are commonly stored in R2;
- Notion remains the editorial staging surface for events and House Updates, but is no longer the council roster source;
- public APIs use explicit response and error contracts documented in API contracts.
See Security model for trust boundaries and Naming conventions for exact technical vocabulary.
Documentation boundaries
This repository explains the platform across services. The source repository for each service remains authoritative for exact implementation and deployment configuration. Point-in-time design documents may describe planned or historical behavior; use page status and the active service landing page to distinguish them.
For ownership and organizational boundaries, see Governance, IP, and Platform Stewardship.