HVHOA AgentSingle source of truth · cite or decline
Seat: Director-APLATFORM STEWARD

About this dashboard

Attribution doctrine, role registry, and the workflow-approval floor that the platform operates under.

Platform attribution

LayerOwner
Platform architecture, software, control-plane designZahirudeen Premji (current Platform Steward) · © 2026
HOA governance content — corpus, minutes, policies, financials, decisionsHyland Village HOA
Future transfer rightsHeld in reserve for a later board governance decision

The platform never claims ownership over HOA documents. The HOA never claims ownership over the platform itself. Transfer of the platform to board stewardship is anticipated and built into the architecture (see deploy/RAILWAY_DEPLOY.md → Transfer readiness).

Platform Steward

Zahirudeen Premji  ·  seat: Director-A

The Platform Steward is an operator role — not an HOA officer role. It exists to maintain the system itself and to prepare the platform for future transfer to board control.

Responsibilities:
  • maintain operational continuity
  • maintain corpus integrity
  • maintain audit-chain integrity
  • maintain deployment/auth infrastructure
  • supervise onboarding framework
  • supervise institutional-memory continuity
  • prepare transfer-readiness for future board stewardship

Director seats

SeatStatusDisplay nameAdditional authorityNotes
Director-AACTIVEZahirudeen PremjiPLATFORM STEWARDOperational seat. Holds Platform Steward authority pending future transfer.
Director-BOPENnoneOnboarding pending.

Officer roles

Officer responsibilities derive from the corpus (Bylaws, Conduct of Meetings, Rules & Regs). The platform does not invent officer duties — it surfaces what the corpus defines. Until the relevant Bylaws sections are cited and verified, each officer role shows [derived from corpus — see Bylaws § officer duties].

OfficerStatusHolder seatNotes
PresidentUNASSIGNEDvacantOfficer workflow not initialized.
TreasurerUNASSIGNEDvacantFinance workflow not initialized.
SecretaryUNASSIGNEDvacantMinutes/governance workflow not initialized.

Workflow-approval doctrine

The platform may propose role workflows — for example, a President-onboarding checklist, a Treasurer reconciliation cadence, or a Secretary minutes pipeline.

The board must approve any workflow that materially affects governance before that workflow becomes binding. Proposed-but-unapproved workflows surface in the dashboard with explicit PROPOSED / NEEDS BOARD GUIDANCE labels and never execute by themselves.

This floor preserves: continuity, legitimacy, future transferability, and non-authoritarian operation of the platform. It is the same floor that holds for content (the agent never invents HOA facts) — extended to process (the platform never invents binding governance procedure).

Source documents (lane)

The institutional source of truth for the registry lives in the lane (Railway volume hvhoa-lane). Code in lib/roles.ts is a thin reflection of these lane documents.

  • lane/roles/ROLE_REGISTRY.md — the registry itself
  • lane/roles/{DIRECTOR_A,DIRECTOR_B,PRESIDENT,TREASURER,SECRETARY}.md — per-seat profiles
  • lane/roles/onboarding/ — onboarding skeletons (derive from corpus)
  • lane/roles/acknowledgements/ — signed acknowledgements (append-only)

← Back to seat home