Change logVersion control

Product Requirements Document - Quorum

Author: James
Date: 2026-04-10

Document conventions

Source file: prd.md — Markdown body plus YAML workflow frontmatter (BMAD checkpoint, visionDiscovery, pipeline, roster). Regenerate published copies after substantive edits:

Run python3 _gen_prd_exports.py in _bmad-output/planning-artifacts/. Optional: quorum-prd-executive-summary.pdf (exec summary only). In-product Quorum PRDs use the same HTML + .docx pairing from one source (pipeline step 4, FR26).

Traceability map

Executive Summary

Quorum is an AI-native product development platform where named agents are the cross-functional team—not a chat sidebar on a ticket tool. Solo founders and enterprise product groups start from a full vision, run it through a disciplined three-pillar filter (Desirability, Feasibility, Viability) with transparent reasoning, and generate aligned downstream artifacts (PRD, journeys, roadmap, cost, pitch, sprint stories) from one evolving source of truth. The human stays conductor; agents challenge the user and each other with structural differentiation (not five identical personas).

Entry is a design-thinking-style session: core idea, ideation, and constraints, closing with a detailed Figma Make prompt so the first concept UI is explorable before scope is locked. Concept visuals update live during the filter. High-fidelity UI, design tokens, and design system are intentionally deferred until after PRD and journey maps (step 5.25), when flows and architecture are known—then Luca (Motion Designer) layers motion on refined screens (5.5) before roadmap and cost absorb motion scope. Quorum does not write application code; it orchestrates external AI coding tools via rich stories—Jaymes (frontend, always in build), Damien (backend, when needed), Quinn (QA), Cipher (mandatory security audit post-build), Bob (Scrum Master). Primary MVP audience: solo founders and indie builders; secondary: enterprise teams that want the same methodology with human specialists leading agents.

Why now: Large founder population already using AI assistants, but no product owns the input side of decisions—methodology as architecture—while models are strong enough to sustain multi-agent product critique.

What Makes This Special

• Agents are the team: Named roster (John, Winston, Mary, Kinsley, Luca, Jaymes, Damien, Quinn, Cipher, Bob) maps to real roles; backbone behavior toward the user is a deliberate differentiator.
• Methodology as architecture: The pipeline is the product logic—not a template library bolted onto Jira-shaped software.
• Vision-first, filter second: Capture and organize, then argue scope with research-grade transparency; nothing important disappears without a logged decision.
• Staged design fidelity: Fast concept in Figma Make (V1 handoff; V2 deeper integration) without token/DS tax up front; refine after journeys; motion on stable pixels—reduces wasted polish on cut or reshaped flows.
• Build orchestration, not an IDE: Quorum produces the thinking and handoffs; Cursor/Claude Code-class tools execute implementation under agent direction.
• One truth, many outputs: Pitch and exec artifacts are cheap because the methodology already produced the underlying data.

Core insight: Existing tools manage the outputs of decisions (tickets, roadmaps, docs). Quorum owns the inputs—thinking, filtering, evidence—and generates outputs from that spine.

Project Classification

Note: V2-critical expansion (documented in vision notes): domain-specific agent packs for regulated industries (e.g. healthcare, fintech) as a marketplace-style capability.

Success Criteria

User Success

• Decision quality (solo): Users report clearer tradeoffs and fewer regretful scope decisions after running the three-pillar filter (qualitative interviews / in-product prompts).
• Time-to-plan: Idea to a validated MVP plan (filtered vision, PRD slice, roadmap + cost confidence) in under two weeks for a motivated solo founder using the guided path—not months of unstructured docs.
• Ship outcomes: Teams that complete the filter and follow generated stories show higher satisfaction or adoption on shipped features vs. pre-Quorum baseline (self-reported or tagged cohort where measurable).
• Scope discipline: When feedback-loop findings exist (V2), items that re-enter the filter show less unmanaged scope creep than ad-hoc backlog growth (process metric).

Business Success

• Solo adoption: 1,000 active users on solo tier within first 6 months of launch (definition: monthly active completing at least one meaningful pipeline segment).
• Enterprise funnel: >20% demo-to-pilot conversion for qualified enterprise conversations.
• Unit economics: Tiered + usage-based pricing validated so power-user cost (high session volume) is modeled and does not break margins at the solo price point.
• Positioning signal: Strong NPS theme: users describe Quorum as “my team,” not “my tool.”

Technical Success

• Orchestration reliability: Story export and handoff to supported AI coding tools (V1: Claude Code / Cursor) is repeatable—stories contain enough context that implementers rarely block on missing spec (measured by support tickets or completion rate).
• Single source of truth: Screen/feature state has one canonical representation through organize → filter → PRD → journeys → refinement (no conflicting “which design is real” drift without explicit versioning).
• Security gate: Cipher audit runs after build; critical/high issues block ship until resolved or explicitly waived with record.
• Quality guardrails: Agent outputs are scored or gated where feasible; distinguishability between agent roles does not collapse in early evals (per product quality bar in vision notes).

Measurable Outcomes

Product Scope

MVP - Minimum Viable Product

• Vision capture spine — mandatory in V1 (non-negotiable): Steps 1 → 2a → 2b → 2c are core V1, not optional and not deferrable. Step 1 (design-thinking-style session, problem/user/constraints/risks, ideation, closing Figma Make prompt), 2a (concept alignment), 2b (initial concept visuals / Figma Make handoff), and 2c (organize the vision) are the start of the methodology—the reversed-flow entry that differentiates Quorum. Shipping “Quorum” without this spine invalidates the product thesis. Ideation must support multiple proposed concept directions and external iteration (user works in another tab or window, then carries results back) per FR46. Incremental enhancements (e.g. voice-first capture, Socratic mode, mood board) are V1 candidates that add to this spine—they do not replace it.
• Full named agent team in workflow: John, Winston, Mary, Kinsley, Luca, Jaymes, Quinn, Cipher, Bob; Damien when backend is in scope.
• Guided pipeline from idea through pitch-ready artifacts: design-thinking session + Figma Make prompt → concept (2a/2b) → organize → three-pillar filter with live concept visuals → PRD → journey maps → design refinement (5.25) → motion (5.5) → roadmap → cost → pitch → sprint planning → build orchestration (10a) → QA (10b) → Cipher (10c) → UAT (10d) → ship.
• Quorum does not author app code—generates detailed stories for external AI coding tools; Jaymes always in UI path; Damien conditional.
• Team room GUI: conversational center, not dashboard-first; AI challenger behavior (push back on user, not only agents).
• Solo and enterprise experiences both present; toggle for demo (exact UX TBD).
• Built-in sprint board, backlog, roadmap (Bob).
• V1 integration priority: one primary coding-tool path (e.g. Cursor / Claude Code) with story format optimized for consumption.

Growth Features (Post-MVP)

• Feedback loop productized: passive collection, milestone activation, digest, ceremony; findings re-enter filter (scope creep firewall).
• Hospital / Morgue / Decomposer finding lifecycle.
• JIRA / Linear (or similar) bi-directional sync for enterprise.
• Confidence × complexity decision grid in ceremonies.
• Visible agent-to-agent debate (V1 stays synthesized disagreement).
• Dynamic sub-agent scaling under load.
• Deeper Figma Make ↔ Quorum integration (beyond link/export handoff).
• Product snapshots & branching (“git for product strategy”).
• Animated prototypes (beyond motion specs).

Vision (Future)

• Domain-specific agent marketplace (regulated industries: healthcare/HIPAA, fintech/PCI, legal, etc.).
• Full automated brownfield ingestion (codebase scan, multi-tool imports, design-system parse, velocity calibration).
• Multi-tool coding orchestration with API-level progress sync.
• Third-party research platform partnerships (e.g. Userlytics-class)—not in core product initially.

Explicitly Out (All Versions)

• Mobile-native app (web-first).
• Self-hosted / on-prem deployment (for stated horizon).
• End-user custom agent training (no user-trained models in scope).

MVP Boundaries & Open Decisions

• Default path: guided sequential pipeline vs. menu / non-linear access—decision required for V1 (Party Mode flagged).
• Canonical artifact schema for screen state and story export—spec TBD before build-heavy phases.
• Enterprise: one automated integration (e.g. Jira or Notion import) per premortem—pick for V1.
• PRD export formats (locked): HTML and Microsoft Word (.docx)—both from a single canonical PRD representation; styling/templates may vary by tier.

User Journeys

Narrative journeys below map who uses Quorum, how they move through the pipeline, and what must exist in the product. Personas align with the product brief: solo founder / indie builder as primary MVP; enterprise product trio as secondary; plus admin, implementer, and recovery paths.

Journey 1 — Maya (solo founder): From spark to pitch-ready plan

Persona: Maya is building a B2B SaaS alone. She has a strong idea but no PM, designer, or eng lead to challenge her. She burns time in Notion lists that never become decisions.

• Opening: Late night, Maya dumps her idea into Quorum. She expects another generic chatbot. Instead, John opens a design-thinking-style session—problem, user, risks—and Kinsley asks about vibe and references. Maya feels heard, not templated.
• Rising action: She receives a detailed Figma Make prompt, refines it with Kinsley (2a), and sees concept frames land in Figma Make (2b). The vision is organized into themes; the three-pillar filter runs as a conversation. When Winston questions feasibility, she pushes back; the UI shows concept screens updating live as features survive or get cut. She trusts the process because reasoning is transparent (sources, caveats).
• Climax: After PRD and journey maps, Kinsley’s refinement pass (5.25) makes the product feel real; Luca adds motion intent before roadmap and cost. Maya opens the pitch output and realizes she could walk into a coffee meeting tomorrow with a coherent story—not a ramble.
• Resolution: Her new normal: Quorum is “the team in the room.” She completes a validated MVP plan in days, not months, and describes the product as partners, not a tool.

Failure / recovery: If Maya abandons during long capture, save points and short aha milestones (organized vision early) pull her back. If she disagrees with a pillar verdict, she can argue, override with audit trail, or re-run a segment.

Journey 2 — Maya (edge): When the filter says “cut” and she refuses

• Opening: Maya is emotionally attached to a feature the filter recommends cutting.
• Rising action: She reads Winston’s feasibility breakdown and Mary’s desirability evidence. She challenges in-thread; agents respond with specific citations, not vibes. Kinsley shows what the concept UI looks like without that feature.
• Climax: She either accepts the cut with understanding, negotiates a scoped-down version that passes pillars, or overrides with the decision logged (for later regret-minimization).
• Resolution: She stays in control but no longer confuses hope with strategy. Requirements: human final say, audit trail, live concept sync, override semantics.

Journey 3 — Sam, Jordan, and Chris (enterprise trio): Shared vision workshop

Personas: Sam (PM) owns outcomes; Jordan (design) owns experience; Chris (eng lead) owns feasibility. They need one shared methodology, not three siloed docs.

• Opening: They import or paste context (MVP: manual + one automated integration option). They enter enterprise mode: roles visible in the team room, each can steer their domain agent.
• Rising action: Multi-user vision capture and organize; filter session becomes a facilitated workshop with pillar cards and live concept updates. Jordan validates flows with Kinsley; Chris pressures estimates with Winston; Sam holds viability and release boundaries with John.
• Climax: They leave with aligned PRD slice, journey maps, refined design targets, motion scope, roadmap, and cost bands—ready for leadership or eng planning.
• Resolution: Enterprise eval lands: “This replaced a week of alignment meetings.”

Failure / recovery: Conflict between design and eng is surfaced, not hidden—orchestrator presents trade-off briefings. Permissions: who can approve overrides and ship gates.

Journey 4 — Dana (workspace admin): Seats, access, and integration

• Opening: Dana must add seats, assign roles (who can run filter vs. view-only), and connect one external system (e.g. Jira or Notion) for enterprise pilot.
• Rising action: Guided OAuth / API key flow (exact UX TBD), sync status, conflict surfacing (“Done in Jira but QA not green”—V2 depth; V1 may be lighter).
• Climax: The trio can work without Dana every day—access is stable and billing matches usage tiers.
• Resolution: Admin work is boring on purpose: fast, auditable, no mystery permissions.

Requirements hinted: RBAC, workspace settings, billing hooks, integration health surface, audit of who changed what.

Journey 5 — Chris (implementer): Story → AI coding tool → back to Quorum

• Opening: Sprint planning (Bob + Winston) produced stories with Kinsley design refs and Luca motion notes. Chris uses Cursor daily.
• Rising action: Chris opens a story file or export from Quorum, runs it in the coding tool with Jaymes-style constraints in context. He commits, runs tests; Quinn-driven QA stories validate acceptance criteria.
• Climax: Story marked done in Quorum; board reflects truth; Cipher runs before UAT; no critical security surprises at the end.
• Resolution: Quorum is the brain; the coding tool is the hands—handoff is low-friction and traceable.

Failure / recovery: If story is under-specified, Chris flags blocked with required fields surfaced; Quorum nudges Winston/Jaymes to enrich. If Cipher finds critical issues, loop to build is explicit.

Journey 6 — Support / “stuck user” recovery (solo or enterprise)

• Opening: A user stalls mid-pipeline (filter anxiety, unclear next step, or session timeout).
• Rising action: Resume prompts from save points; checkpoint copy explains what they already have (“You have organized vision + concept boards”). Optional short recap from agents.
• Climax: They re-enter at the right step without re-doing everything; optional human support ticket references session ID and artifact versions.
• Resolution: Drop-off from “overwhelm” decreases; support has visibility into last good state.

Requirements hinted: Serializable state, step resume, artifact versioning or snapshots (aligns with V2 branching vision; V1 minimum = clear checkpoints).

Journey Requirements Summary

Deferred personas (post-MVP)

Personas noted below are recognized as real users Quorum will eventually serve, but are not scoped for MVP. They shape forward-looking product decisions (see Epic 11 features) without producing their own MVP journeys.

• Content Strategist — In larger organizations and enterprise tiers, the person who drafts poll content is often distinct from the administrator who configures the vote and manages the workspace. They care about question clarity, phrasing consistency, accessibility of question text, and maintaining a shared voice across polls published by their org. Product features addressing their needs (MVP-scoped via Epic 11): poll template library, clarity/bias/accessibility checker, suggested rewordings, inline best-practice guidance. Future considerations (not MVP): distinct permission tier separating "content author" from "workspace admin", content review/approval workflow, shared template libraries scoped to a workspace or org. Revisit when enterprise tier demand materializes.

Innovation & Novel Patterns

BMAD project-types.csv (saas_b2b): Workflow automation; AI agents. Executive differentiators are also stated in Executive Summary § What Makes This Special; this section focuses on novelty vs. market, how to validate, and innovation risks.

Detected Innovation Areas

• Methodology as product architecture: The planning pipeline (capture → organize → three-pillar filter → artifacts → orchestrated build) is not a template bolt-on—it is the core runtime behavior competitors lack.
• Agents as the team, not a feature: Named, role-differentiated agents with backbone (including pushback on the user) and structural evaluation differences—not one model with five skins.
• Input-side ownership: Owning decision inputs (reasoning, evidence, filter outcomes) and generating pitch/PRD/roadmap/stories from one spine—versus tools that only manage ticket outputs.
• Staged design + motion: Concept in Figma Make early (with handoff prompt), refinement after journeys, motion on refined screens—reduces wasted polish and matches how real teams should sequence work.
• Brain vs hands split: Quorum orchestrates AI coding tools via rich stories; it does not compete as an IDE—novel division of labor for “full stack” product development.

Market Context & Competitive Landscape

• Adjacent tools (Jira, Productboard, Notion, Aha!, etc.) optimize tracking and communication after decisions; they do not run a cross-functional methodology with AI-as-team.
• AI coding tools optimize implementation; they do not own vision → filter → roadmap → security gate as a single product surface.
• Risk: Incumbents add “AI sidebars”; differentiation depends on depth of orchestration, artifact consistency, and trust (transparency, audit trail, agent distinguishability).

Validation Approach

• Qualitative: Solo founders report “better decisions” and team framing (NPS theme); enterprise pilots report alignment speed vs. meeting-only process.
• Quantitative: Time to validated MVP plan (<2 weeks target); filter completion correlation with shipped-feature satisfaction where measurable.
• Product metrics: Activation at organized vision / concept in Figma milestones; drop-off by step; story handoff success (blocked rate for under-specified stories).
• Technical evals: Agent distinguishability suite; output quality guardrails from day one (per vision notes).

Risk Mitigation

• Innovation too heavy to build: V1 narrows to synthesized disagreement (not full visible multi-agent debate), one coding-tool integration path, Figma Make via handoff (not full bidirectional sync).
• Trust collapse: Granular pillar transparency (sources, caveats, falsifiable claims); human override with audit; Cipher gate before ship.
• Cost / power users: Per-tenant usage tracking and pricing modeled on high session volumes (premortem).
• “Just ChatGPT” perception: Structured artifacts, pipeline checkpoints, and role-specific outputs—not a single thread.

SaaS B2B Specific Requirements

Derived from BMAD project-types.csv row saas_b2b — key questions: Multi-tenant? Permission model? Subscription tiers? Integrations? Compliance? Required sections: tenant_model, rbac_matrix, subscription_tiers, integration_list, compliance_reqs. Skipped for this type: CLI-first, mobile-native (web-first).

Project-Type Overview

Quorum is a multi-audience B2B SaaS platform: solo users behave as an enterprise-of-one tenant; enterprise customers use seats, roles, and optional tool integrations. The product is web-first, conversation- and artifact-centric (team room, boards, exports)—not a mobile-first or CLI-primary interface.

Technical Architecture Considerations

• Logical isolation: Every workspace’s artifacts (vision, designs, PRD, stories, audit trails) must be tenant-scoped at the data model and API layer; no cross-tenant reads without explicit system-admin break-glass (if ever).
• Session and AI usage: Per-tenant metering for agent sessions and model calls (premortem: power users 45–100+ sessions/month) to protect unit economics.
• Export surfaces: Story and spec exports for external AI coding tools must embed tenant and workspace context without leaking other tenants’ data.
• State for resume: Serializable pipeline state and checkpoints (journey 6) should be tenant-bound and version-stable for support.

Tenant model

• Workspace = primary tenant boundary (recommended): each subscription owns one or more workspaces; enterprise may map workspace ↔ product line or squad.
• Solo: Single user, single (or few) workspace(s)—same isolation rules as enterprise to keep one code path (“solo is enterprise-of-one”).
• Growth path: Multiple workspaces per org in later tiers without merging data across unrelated products.

RBAC matrix (baseline)

Enterprise “human leads AI” mode may map human specialists to delegate or approve subsets of agent proposals—exact matrix TBD in UX.

Subscription tiers

Plans are organized into two categories (matching primary personas) with two tiers each (4 plans total in V1). Naming uses "Team" rather than "Enterprise" — the V1 target persona is a small product trio (J3 Sam/Jordan/Chris), not a Fortune 500 IT buyer; "Enterprise" is reserved as a future tier within Team once SSO/SCIM/SOC2 land.

• Plan selection at sign-up: New users pick a category, then a tier, before creating credentials (FR48, FR49). The selected plan is stored on the workspace and is the source of truth for that workspace's feature limits and billing.
• Auto-promotion: A Solo workspace that issues its first invitation auto-promotes to a Team plan (FR50); the change is recorded in audit history (FR45). No manual "upgrade" action required for this transition.
• Metering transparency: In-product visibility into usage vs. plan limits to avoid surprise throttling.
• Future: A third Enterprise tier within the Team category will land when SSO/SCIM/SOC2 are real product capabilities; not V1.

Integration list

Compliance requirements

• Baseline SaaS: Privacy policy, data processing terms, subprocessor disclosure for model providers; GDPR-aligned export/delete requests for personal data in workspaces (implementation depth TBD).
• Security: Cipher-driven pre-ship audit; secrets handling; dependency scanning—product requirement, not optional flavor text.
• Audit: Filter overrides, ship approvals, and integration connects should be auditable for enterprise customers.
• Regulated verticals: Not V1 core — V2 domain agent marketplace (HIPAA, PCI, etc.) per vision notes; architecture should not preclude BAA/support later but does not commit V1 scope.

Implementation Considerations

• Not in scope for this project type row: Dedicated CLI product surface; mobile-first native apps (responsive web only).
• Web UX: Team room, accessibility baseline for conductor workflows (WCAG target to be set in UX step).
• On-call / reliability: Enterprise expectations for uptime and incident communication—targets to be set in NFR pass.
• Open decisions: Canonical story file schema; guided vs menu pipeline default; which one import (Jira vs Notion) ships in V1.

Project Scoping & Phased Development

MVP feature list is canonical in Product Scope § MVP; this section adds strategy, minimum journey coverage, and explicit deferrals.

MVP Strategy & Philosophy

MVP approach: Experience + learning MVP as an advanced prototype (product brief): prove methodology-as-architecture end-to-end for a solo conductor and demo credibly to enterprise. Users run the full planning spine (see YAML quorumPipeline / Product Scope) with one primary AI-coding integration; some edges stay manual in V1 (Figma link handoff, single PM import choice).

Resource (indicative): Product + design + full-stack eng; ML/ops for routing, metering, guardrails. Highest leverage: story schema, team room, filter transparency.

MVP Feature Set (Phase 1)

Journeys that must be covered in V1 (minimum):

• J1 — Solo happy path: Design-thinking → Figma prompt → concept → organize → filter → artifacts through pitch; save points.
• J5 — Implementer: Story export → coding tool → QA → Cipher → ship path.
• J2 — Filter edge: Disagreement, override, audit trail.
• J3 — Enterprise: Mode toggle + workshop slice (may be scripted demo if realtime collab slips).
• J4 — Admin: Seats, roles, one import, billing basics.
• J6 — Resume: Checkpoint “you left off here.”

Capabilities: Product Scope → MVP (agents, pipeline, team room, filter, artifacts, build orchestration, gates, tenancy). Not repeated here.

Explicit Phase 1 cuts / deferrals (unless risk tests fail):

• Visible multi-agent debate, dynamic sub-agents, full feedback loop productization, Hospital/Morgue, bi-directional Jira at scale, deep Figma sync, SSO (may trail GA), animated prototypes beyond specs.

Post-MVP Features

Phase 2 (growth):

• Full feedback loop (collection, digest, ceremony, re-filter firewall).
• Hospital / Morgue / Decomposer lifecycle.
• JIRA/Linear bi-directional workflows; confidence × complexity grid in ceremonies.
• SSO and richer enterprise admin.
• Deeper Figma Make ↔ Quorum integration.
• Product snapshots / branching.
• Optional visible agent debate; sub-agent scaling.

Phase 3 (expansion):

• Domain agent marketplace (regulated industries).
• Full brownfield automation (codebase ingest, multi-import, DS parse, velocity calibration).
• Multi-tool coding orchestration with API progress sync.
• Third-party research partnerships.

Risk Mitigation Strategy

Technical risks: Narrow V1 contracts (one coding tool, one import, handoff-first Figma); canonical artifact schema decided early; quality guardrails and distinguishability evals to avoid “five ChatGPTs”; power-user metering from day one.

Market risks: 10-minute activation path to organized vision + concept; solo-first UX with enterprise demo toggle; pilot >20% demo-to-pilot tracked; qualitative “my team” signal.

Resource risks: If build bandwidth is tight, preserve filter + story export + team room; thin enterprise collab to demo quality; postpone SSO and second integrations; keep Cipher non-negotiable for any “ship” narrative.

The Three-Pillar Framework

Desirability, Feasibility, Viability is the spine of how Quorum thinks about every product idea. It's older than Quorum — IDEO, design thinking literature, business-model canvases all use the three lenses — but most tools that reference the framework treat it as a slide title, not a working method. Quorum operationalizes it. Every feature, every release decision, every story export descends from a structured evaluation across all three lenses, with named agents who own each one, defined research methods that run under each, and concrete artifacts that come out the other side.

The framework is a process discipline, not a checklist. A pillar isn't "filled in" by a one-line answer. It's earned by running the right methods, capturing the evidence, and letting the agents who own that lens push back on weak conclusions. The gates that come after (next section) only fire on outputs the framework actually produced.

Why this is the differentiator

Most tools manage the outputs of decisions. Tickets. Roadmaps. Specs. Quorum manages the inputs — the thinking, the evidence, the structured argument that produces a defensible go/no-go on every scope question. The three-pillar framework is how that thinking happens. Without it, Quorum is just another tracker.

A user finishing the framework should be able to answer, for any feature in their backlog: Why is this in scope? — and the answer is "Mary's persona research validates the JTBD; Winston's architecture confirms the build path with no blockers; John's market sizing supports the unit economics at the target price." Three lenses, three owners, three artifacts. No hand-waving.

Pillar 1 — Desirability

The lens: Do target users want this enough to change behavior, adopt a workflow, or pay for it? Desirability isn't "is this a good idea" — it's "is there evidence the user feels the need this addresses, and is that evidence strong enough to commit engineering hours to."

Lead agent: Mary (Strategic Business Analyst). Mary owns the desirability lens end-to-end. She runs the research, frames the personas, pressure-tests claims, and signs off on whether evidence is strong enough to clear the gate.

Supporting agents:

• Quentin (Content Strategist + UX research) — voice of customer, accessibility-as-desirability, copy that earns trust.
• John (Product Manager) — translates desirability findings into PRD requirements with measurable success criteria.
• Maya (Design Thinking Maestro) — facilitates empathy work and human-centered exercises when the team needs structured discovery.
• Carson (Brainstorming Specialist) — opens the solution space when desirability research surfaces a need with no obvious answer.
• Sophia (Master Storyteller) — converts persona research into the narrative spine of the pitch and case study.
• Freya (WDS Strategic UX Designer) — runs trigger mapping that connects business goals to user psychology, and scenario design that turns triggers into structured micro-steps.

Process — methods that run under desirability:

• User interviews and synthesis (Mary) — qualitative discovery, voice-of-customer extraction, theme clustering.
• Persona development (Mary, Quentin) — JTBD-framed personas with cited evidence per claim, not invented archetypes.
• Empathy mapping (Maya) — what the user says, thinks, does, feels — structured around the problem space.
• Brainstorming sessions (Carson) — 40+ ideation techniques (SCAMPER, What If, Six Thinking Hats, Worst Possible Idea, etc.) when the team needs divergent thinking before convergent.
• Design-thinking workshops (Maya) — empathize → define → ideate → prototype → test, run as guided sessions with artifacts at each step.
• Trigger mapping (Freya) — structured workshop that maps business goals down to the user-psychology triggers that drive adoption.
• Scenario design (Freya) — micro-step user-flow outlines that test whether the proposed experience earns its desirability claim.
• Moments-that-matter inventory (Quentin) — peak/valley/transition mapping across the product lifecycle, identifying where the user emotionally invests or disengages.
• Voice-of-customer synthesis (Quentin) — turns interview transcripts and feedback into a voice & tone guide that downstream copy must hold to.
• Storytelling-framework analysis (Sophia) — runs the persona's experience through Hero's Journey / SCQA / Pixar / before-and-after frames to surface narrative gaps.

Artifacts that come out:

• personas.md — JTBD-grounded personas with cited evidence per behavioral claim.
• moments-that-matter.md — full lifecycle inventory of peak / valley / transition moments with copy hooks per moment.
• user-flow-map.md — mermaid + prose map of every primary flow the desirability research validated.
• voice-tone-guide.md — the project's voice spine, derived from research, that all user-facing copy traces to.
• trigger-map.md — business goal → user psychology trigger mapping (when WDS workflows run).
• scenarios.md — micro-step scenario outlines per primary flow.
• case-study.md — the narrative shape of the project for portfolio and pitch use.
• research-synthesis.md — interview themes, observation logs, hypothesis tests.

Desirability gate is cleared when: a feature ties to a named persona's JTBD; cited evidence exists for the underlying need (research, prior-art pattern, user statement, measured behavior); Mary's confidence is ≥ moderate; Quentin has signed off that the surface has no voice or accessibility blocker. See the next section for full gate mechanics.

Pillar 2 — Feasibility

The lens: Can the team build, operate, ship, and maintain this with current or achievable capabilities, within the planned horizon, against the stack and integrations on the table? Feasibility isn't "is this possible in principle" — it's "is the path identified, are the blockers resolved, is the operational load survivable."

Lead agent: Winston (System Architect). Winston owns the feasibility lens. He produces the architecture decision records, identifies the build path, names the blockers, and signs off on whether the team can actually ship what desirability says users want.

Supporting agents:

• Damien (Backend Developer) — databases, APIs, auth, deployment; weighs in whenever a feature crosses the server line.
• Jaymes (Frontend Developer) — UI implementability; how a design translates to real components against the stack.
• Murat (Test Architect) — test strategy, NFR feasibility assessment, CI/quality-gate scaffolding.
• Cipher (Offensive Security) — threat modeling and security-feasibility assessment; surfaces "you can't ship this without X" early.
• Kinsley (UX Designer + Design Systems) — design-system feasibility; whether a proposed pattern fits the token / component inventory or requires net-new work.
• Quinn (QA Engineer) — test automation feasibility; what coverage is achievable given the surface area.
• Amelia (Senior Software Engineer) — story-level feasibility; whether the spec is implementable as written or needs decomposition.

Process — methods that run under feasibility:

• Architecture decision records (Winston) — explicit decisions with alternatives considered, trade-offs named, and consequences surfaced; not retrospective documentation.
• Technical research (Winston + Mary) — bounded investigations into stack, library, integration, or pattern viability with a written conclusion.
• Component inventory and design-system audit (Kinsley, Jaymes) — what exists vs what would have to be built; the gap is the feasibility cost.
• Test design (Murat) — system-level or epic-level test strategy that identifies coverage gaps and infrastructure needs before code is written.
• Acceptance test design / ATDD (Murat) — failing acceptance tests written first; if they can't be written, the requirement isn't feasible as specified.
• Test framework scaffolding (Murat) — Playwright/Cypress initialization with the conventions and helpers the team actually needs.
• NFR assessment (Murat) — performance, security, reliability, scalability gates evaluated against the proposed solution.
• Traceability matrix (Murat) — every requirement → every test → every artifact, surfacing coverage gaps as a feasibility flag.
• Security threat modeling (Cipher) — STRIDE / abuse-case analysis with mitigations named, ranked, and gated.
• Code review and adversarial review (Cipher + Murat + Amelia) — multi-layer review that hunts edge cases, blind spots, and acceptance gaps.
• Implementation-readiness check (Winston + John) — validates PRD, UX, architecture, and epics are complete enough to dev against.

Artifacts that come out:

• architecture.md — decisions, alternatives, consequences; not a diagram dump.
• tech-stack.md — stack inventory with rationale per choice.
• technical-research-*.md — bounded research reports with conclusions.
• test-plan.md / test-design.md — system or epic-level test strategy.
• nfr-assessment.md — non-functional gate verdict per requirement.
• traceability-matrix.md — requirements ↔ tests ↔ artifacts coverage.
• security-assessment.md — threat model, mitigations, gate verdicts.
• design-system.md — token + component inventory with usage rules.
• implementation-readiness-report.md — go/no-go on dev start.

Feasibility gate is cleared when: an implementation path is identified (stack, skills, integration surface); no unresolved blockers remain; operational cost (compute, support, complexity) fits the envelope for the target release; Winston's confidence is ≥ moderate; Cipher has cleared the security floor.

Pillar 3 — Viability

The lens: Should the business invest? Does this fit strategy, economics, compliance, timing, and the competitive frame? Viability isn't "could this make money" — it's "given everything else this team could be doing, is THIS the right bet right now."

Lead agent: John (Product Manager). John owns the viability lens. He produces the PRD, defines the success criteria, weighs the strategic fit, and signs off on whether the business case clears the bar.

Supporting agents:

• Victor (Disruptive Innovation Oracle) — strategic positioning, business model innovation, competitive disruption analysis.
• Mary (Strategic Business Analyst) — market research, competitive landscape, sizing data that John's economics depend on.
• Sophia (Master Storyteller) — pitch narrative, investor / executive framing.
• Caravaggio (Presentation Master) — visual communication of the business case in slide decks and pitch decks.
• Bob (Scrum Master) — sprint-level viability; whether the proposed scope fits the planning horizon and team capacity.
• Atticus (Legal SME) — regulatory, compliance, UPL, and ethics checks on viability claims that touch regulated surfaces.

Process — methods that run under viability:

• Market research (Mary) — sizing, segmentation, growth trends, addressable-market analysis with cited sources.
• Competitive landscape research (Mary) — direct and adjacent competitors mapped on positioning, capabilities, pricing, and weaknesses.
• Domain research (Mary) — vertical or industry-specific deep-dives when the project sits in a regulated or specialized space.
• Innovation strategy / disruption mapping (Victor) — disruptor analysis, jobs-to-be-done at market level, blue-ocean canvases.
• Business model architecture (Victor + John) — pricing tiers, monetization mechanics, unit economics modeling.
• PRD authoring (John) — the binding document; success criteria, FR/NFR contract, scope, traceability.
• PRD validation (John) — explicit pass against quality bars (completeness, coherence, testability, alignment).
• Storytelling for pitch (Sophia) — narrative shape of the investor / executive deck; the "why now, why us, why this" frame.
• Pitch deck construction (Caravaggio) — visual translation of the business case into 10-15 high-density slides.
• Sprint planning (Bob) — translates viability claims into a release rhythm; surfaces capacity / horizon mismatches.
• Compliance and ethics review (Atticus) — regulatory blockers, UPL exposure, accessibility-as-legal-floor.
• Critical / adversarial review (any agent) — cynical review pass that argues the viability claim down; if the claim survives, it passes the gate.

Artifacts that come out:

• prd.md — the binding requirements document; this PRD itself.
• market-research.md — sized market with cited sources.
• competitive-landscape-research.md — competitor map with positioning and gap analysis.
• domain-research.md — vertical-specific deep dives.
• methodology-comparison-research.md — how Quorum's approach compares to alternatives.
• innovation-strategy.md — disruption thesis and business-model architecture.
• pitch-deck.md (or .pdf) — investor / executive deck.
• executive-summary.pdf — short-form viability pitch for stakeholders.
• case-study.md — outcome narrative for portfolio and sales.
• sprint-status.yaml — release rhythm and capacity reality check.
• release-notes-format.md — viability narrative continued post-ship.

Viability gate is cleared when: the feature aligns with stated business model and positioning; ROI is positive or defensibly so for the intended horizon; no compliance / legal / timing blockers remain; John's confidence is ≥ moderate; Atticus has cleared regulatory exposure where applicable.

How the three pillars work together

The pillars are independent gates — a feature must clear all three to enter release allocation. They're also mutually informative:

• Desirability without feasibility is wishful thinking. Mary's research can prove users desperately want a feature, but if Winston identifies an unresolved blocker, the gate fails. The user-want signal still matters — it goes into the V2 / V3 hospital for re-evaluation when the blocker is resolved.
• Feasibility without desirability is engineering theater. Winston can confirm a feature is buildable in three days, but if Mary's persona research surfaces no real need, the gate fails. The build path is preserved for if a desirability case emerges later.
• Viability without desirability or feasibility is strategy fiction. John can argue a feature aligns with the business model, but if no user wants it (Mary fails) or no path exists to ship it (Winston fails), the strategic argument doesn't compensate. Override requires explicit rationale and is audit-tracked (FR45).

The framework's strength is that it distributes the argument across three orthogonal owners. A feature that should die dies because at least one of three substantively different evaluations finds it wanting. A feature that should live earns its place by surviving all three. The user can override any verdict — it's their product — but every override is recorded so future readers see where the human-over-agent call was made deliberately.

How this maps to the rest of the PRD

• Filter mechanics — see the next section ("Three-Pillar Checkpoint Gates") for pass / fail / needs-revisit logic.
• Functional requirements — FR21–FR25d cover running the evaluation, surfacing evidence, disputing conclusions, accepting or overriding verdicts, and audit trail.
• User journeys — J2 covers the "filter edge" path where disagreement, override, and audit happen.
• Success criteria — "Decision quality (solo)" and "Scope discipline" are direct measurements of the framework working.
• MVP scope — the framework is non-negotiable in V1. Shipping Quorum without the three-pillar pipeline operating end-to-end invalidates the product thesis (see Product Scope § MVP, vision capture spine).

Three-Pillar Checkpoint Gates

The three pillars — Desirability, Feasibility, Viability — are not just analysis lenses. They are checkpoint gates. A feature cannot advance out of the filter into a release allocation (MVP / V2 / V3) until it has a terminal verdict on all three. Rankings come from the gate results; the gates themselves decide go / no-go.

Why gates, not just rankings. A ranking tells you what's best relative to peers. A gate tells you whether a feature is viable on its own terms. Features that score well against each other can still all fail a viability gate together (e.g. all elegant, all unbuildable). Quorum insists on both — per-pillar verdicts first, then rankings of what passed.

Gate definitions

Desirability gate — Do target users want this enough to change their behavior, adopt a workflow, or pay?

• Passes when: the feature ties to a named persona's job-to-be-done; there is cited evidence of the underlying need (research, prior-art pattern, user statement, or measured behavior); and agent confidence is ≥ moderate.
• Fails when: the feature answers no clear user need, relies on speculative demand, or agents return low confidence with no plan to raise it.
• Needs revisit when: evidence is thin but not absent; the user has disputed the conclusion and the agents are still researching.

Feasibility gate — Can the team build, operate, and maintain this with current or achievable capabilities within the planned horizon?

• Passes when: an implementation path is identified (stack, skills, integration surface); no unresolved blockers remain (tech, team, dependency); operational cost (compute, support, complexity) fits the envelope for the target release; and confidence is ≥ moderate.
• Fails when: an unresolved blocker exists, the estimated effort exceeds the release horizon, or the operational load is incompatible with the staffing model.
• Needs revisit when: a blocker has a plausible mitigation still being explored, or the effort estimate has wide variance the user wants narrowed.

Viability gate — Should the business invest — does this fit strategy, economics, compliance, and timing?

• Passes when: the feature aligns with stated business model and positioning; ROI is positive or defensibly so for the intended horizon; no compliance / legal / timing blockers remain; and confidence is ≥ moderate.
• Fails when: the feature undermines positioning or unit economics, introduces compliance risk with no mitigation, or its competitive timing is materially wrong.
• Needs revisit when: strategy is in flux, ROI depends on an unresolved upstream assumption, or compliance is pending external clarification.

Gate exit criteria

A feature is considered gate-cleared when all three gates have a terminal verdict: pass, fail, or user-override-with-audit. Only gate-cleared features enter the release allocation output (FR25a).

• All three pass → feature enters the ranked-for-allocation pool.
• Any one fails → feature is excluded from allocation unless the user overrides with rationale (FR25, FR25d).
• Any one sits in needs revisit → feature blocks on that gate; it cannot exit the filter until the gate resolves.

Override and audit

Users can override any gate verdict — it's their product, not the agents'. But every override requires captured rationale and is surfaced, not buried:

• Override rationale is stored append-only alongside the original verdict (FR45 audit trail).
• Downstream artifacts (release allocation, PRD narrative, sprint stories) display an override marker against the feature so future readers see the human-over-agent call was made deliberately.
• Overrides never rewrite the original verdict — both stand on the record.

How this maps to functional requirements

• FR21, FR22 — running the pillar evaluation and seeing evidence
• FR23 — disputing a conclusion and keeping a feature in needs revisit while analysis deepens
• FR25 — accepting or overriding a verdict
• FR25a — release allocation output that consumes only gate-cleared features
• FR25b, FR25c, FR25d — explicit gate verdicts, gate-exit enforcement, and override audit (defined below under Organization & three-pillar filter)

Functional Requirements

Capability contract: UX, architecture, and delivery trace to FR1–FR50. Wording is implementation-agnostic (what actors can do, not how). Measurable quality is in Non-Functional Requirements below.

Workspace & access

• FR1: User can create and name a workspace for a product effort.
• FR2: User can authenticate and be associated with one or more workspaces.
• FR2a: User can register a new account by selecting a plan and providing credentials, without requiring an invitation.
• FR3: Workspace owner can invite members and assign roles with differentiated permissions.
• FR4: User can perform only actions permitted by their role within a workspace.
• FR5: System enforces isolation of data and artifacts between workspaces.
• FR6: User can leave or be removed from a workspace according to role rules.

Plan selection & workspace lifecycle

• FR48: System can display subscription plans for selection by category and tier prior to authentication.
• FR49: Plan selection during sign-up creates a workspace associated with the chosen plan; the plan is the source of truth for that workspace's feature limits and billing terms.
• FR50: Workspace plan can be changed by lifecycle events (e.g., first invitation auto-promotes a Solo workspace to a Team plan) with the change recorded in audit history (FR45).

Team room & human-in-the-loop decisions

• FR7: User can interact with the AI product team through a conversational team room.
• FR8: User can see which agent personas are active for the current pipeline step.
• FR9: User can open and navigate workspace artifacts alongside the conversation.
• FR10: Agents can surface conflicting assessments and structured trade-offs for user resolution.
• FR11: User can request clarification on agent reasoning during pipeline steps.
• FR12: Product can record user decisions on contested recommendations.
• FR13: User can resume work from a saved pipeline checkpoint.

Vision ideation & concept design

• FR14: User can participate in a structured ideation session led by the full team that runs an 8-category discovery framework (Core Idea, Features & Functionality, Look & Feel, Visual Identity, User & Audience, Reference Examples, Copy & Voice, Constraints) — each question paired with a conversational prompt and concrete examples — and produces four structured deliverables: (1) Problem & Solution Framing, (2) Features & Capabilities, (3) Master Design Prompt, (4) per-Screen Prompts.
• FR15: User can receive a documented handoff suitable for external concept-design execution — delivered as a tool-agnostic design prompt (works in any generative design tool: Figma Make, Claude, v0, Midjourney, etc.) and downloadable in the user's choice of formats (Doc, HTML, and/or PDF, selectable via checkbox/dropdown).
• FR16: User can align on directional aesthetics for early concepts without establishing a full design system.
• FR17: User can associate initial concept visuals with features and flows in the workspace.
• FR18: User can update concept visual references as the vision evolves.
• FR46: After ideation, the user can review a series of generated concept variations (scroll/browse), select one (or retain multiple) to establish the baseline for later steps, refine a selected concept with natural-language direction and/or iteration in a separate browser tab or window (e.g. Figma Make), and carry results back into the workspace—link, attach, or import—without losing place in Quorum. Quorum remains the conductor; external tabs are scratch space. Organize and three-pillar phases consume the resulting initial designs, concept labels, and core needs from ideation.

Organization & three-pillar filter

• FR19: System can propose a full product sitemap (every section mapped with per-section contents, capabilities, data flows, and relationships to adjacent sections) alongside themed groupings of features with dependencies for user confirmation.
• FR20: User can edit or confirm organized groupings before analysis.
• FR21: User can run structured three-pillar evaluation on feature groups, choosing between two modes upfront: (A) Collaborate — work alongside the AI agents, discuss each evaluation, argue back, and make calls together in real-time; (B) Let AI handle it — agents perform the full analysis independently and user reviews the finished output, overriding where needed.
• FR22: User can view evidence, sources, and rationale tied to pillar conclusions.
• FR23: User can dispute pillar conclusions and receive further agent analysis.
• FR24: Concept representations can reflect additions, removals, and merges of scope driven by filter outcomes.
• FR25: User can finalize acceptance or override of pillar recommendations with rationale retained.
• FR25a: System can produce per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually), an overall combined ranking across all three pillars, and release allocation recommendations (MVP / V2 / V3 / deferred) with reasoning for each allocation.
• FR25b: Each pillar evaluation emits a terminal verdict (pass / fail / needs revisit) against documented pass criteria — not only a ranking score. Verdict, confidence level, and the evidence that supported it are stored with the feature.
• FR25c: Features cannot advance to release allocation (FR25a) unless all three pillar gates have a terminal verdict (pass, fail, or user-override-with-audit). Features sitting in needs revisit block on that gate and are held in the filter until the gate resolves.
• FR25d: User override of a failed or contested gate verdict requires rationale capture and is marked on downstream artifacts (release allocation output, PRD narrative, sprint stories). Original verdict and override both stand on the audit record; the override does not rewrite the underlying evaluation.

Planning artifacts & traceability

• FR26: System can produce a requirements document from the post-filter vision state and deliver it as HTML and as Word (.docx), generated from the same source so exports stay consistent.
• FR27: System can produce journey maps that reflect agreed user and customer flows.
• FR28: User can trigger a refinement pass that (a) updates journey maps based on all pipeline findings since they were first drafted, (b) refreshes all screens and their content against the current truth, (c) increases design fidelity and establishes the design-system structure (tokens + components), and (d) produces a fix-up design prompt for any visual tool that references previous concept designs and updates everything — plus Doc + HTML exports for all contextual material (token inventory, design system plan, screen-by-screen specs, updated journey maps).
• FR29: System can capture motion and interaction intent specifications after refined design, delivered in text and HTML formats — per screen, per transition, per interactive element — with reduced-motion alternatives as a parallel spec.
• FR30: System can produce roadmap and cost estimates informed by agreed scope and motion.
• FR31: System can produce audience-appropriate pitch or executive narrative outputs — generated, then user refines both design and content (not one-shot), then exported as PDF, DOC, and HTML.
• FR32: User can navigate between artifacts that share a consistent underlying scope state.

Sprint planning & implementation handoff

• FR33: System can generate epics and stories with acceptance criteria from approved scope.
• FR34: Stories can carry references to design and motion artifacts when applicable.
• FR35: User can export stories in a form consumable by external AI-assisted implementation tools.
• FR36: User can record implementation progress against stories in the workspace.
• FR37: System can include backend-related planning when the product definition requires it.

Quality, security & user acceptance

• FR38: User can execute or trigger QA flows tied to story acceptance criteria.
• FR39: System can require a security review pass after implementation and before release declaration.
• FR40: User can perform acceptance review comparing delivered work to design and motion intent.
• FR41: User can mark a release blocked or unblocked according to security and quality policy.

Administration, usage & integrations

• FR42: Administrator can configure subscription tier limits and seat allocation for a workspace.
• FR43: Administrator can connect an external work-tracking or knowledge import according to V1 integration policy.
• FR44: User can view usage relative to subscription limits.
• FR45: System can record auditable history of security-sensitive configuration and override actions.

Portfolio documentation and case study

• FR47: System can produce a Portfolio Document summarizing the end-to-end process the user followed (from initial idea through ship and feedback) — covering original problem/hypothesis, discovery insights, concept evolution (before/after at each stage), design decisions and rationale, three-pillar highlights, architecture choices, build process, QA/security findings, final screenshots, post-ship metrics (when available), and lessons learned — delivered as HTML, PDF, and Doc. Output shows the evolution, not just the result, and is suitable for stakeholder-retrospective or long-form internal record use.
• FR60: System can produce a Case Study as a distinct artifact from the Portfolio Document. Case Study is shorter and more polished than the Portfolio Document, optimized for external sharing with portfolio reviewers, prospective clients, or a public audience. Same data sources as the Portfolio Document (workspace audit trail, filter decisions, rationale log, artifact highlights, post-ship metrics), different selection and tone.
• FR61: At pipeline step 13 (post-ship), system prompts the user to generate the Portfolio Document, the Case Study, or both. The prompt offers tone and length options: Portfolio reviewer (short, polished, externally shareable), Internal retrospective (longer, candid, for the team), or Public case study (mid-length, shareable on a user's own channels).
• FR62: Case Study and Portfolio Document outputs apply the user's project visual identity — color palette, typography, logo — so every generated artifact looks like it belongs to the product the user built. Quorum's own meta case study uses Quorum's dark-space cyan aesthetic as a worked example.
• FR63: User can publish the Case Study to a personal portfolio endpoint: a user-owned URL, a connected portfolio website (v1 integration list TBD), or a shareable live link hosted by Quorum. Published case studies keep a canonical URL and can be updated as the product evolves post-ship.

Desktop distribution

Introduced by Epic 10 (macOS wrapper). See epics.md and adrs/adr-001-macos-wrapper-platform.md for platform rationale (Tauri + thin wrapper).

• FR51: User can download and install a signed, notarized macOS application (Quorum.app) from quorum.app/download.
• FR52: Quorum.app presents the full Quorum web experience in a native macOS window with proper dock and menubar presence (thin-wrapper scope — native menus and offline mode deferred to future iterations).
• FR53: Quorum.app checks for and applies updates on launch via a signed update manifest; unsigned or tampered manifests SHALL be rejected.
• FR54: System produces macOS distribution artifacts via automated CI — signed + notarized .dmg on tagged release — with no manual signing or notarization steps required.
• FR55: Quorum.app passes security review covering Apple entitlements (minimum-necessary), hardened runtime enablement, and network egress posture (all outbound hosts Quorum-owned or documented) before each public release.

Question crafting & content quality

Introduced by Epic 11. Accessibility-aware by default per Quorum's cross-cutting accessibility posture (see NFR-A section).

• FR56: User can browse and apply a library of WCAG 2.2 AA compliant poll templates categorized by vote type (Yes/No, Ranked Choice, Approval Voting, Sentiment, Multiple Choice, Free Response).
• FR57: System analyzes user-drafted poll questions in near-real time (debounced under 500 ms) and flags clarity, bias, and accessibility issues inline without blocking — leading phrasing, jargon, reading-level exceedance, ambiguous options, missing alt text on attached images.
• FR58: System offers plain-language alternative phrasings for flagged poll questions, preserving the original question's intent and answer options; suggestions render within 3 seconds.
• FR59: System surfaces contextual best-practice guidance and accessibility tips during poll drafting (non-blocking, dismissible, full library accessible on demand).

Non-Functional Requirements

NFRs define how well the system must perform. Only categories that matter for Quorum are included; targets should be refined into SLOs during architecture and ops planning.

Performance

• NFR-P1 (interactive UX): Primary user interactions in the team room and artifact sidebar (load panel, switch step, open artifact) SHALL achieve sub-second perceived response for cached reads under normal load; any operation exceeding 2 seconds P95 SHALL show explicit progress or streaming feedback.
• NFR-P2 (agent turns): Multi-step agent workflows SHALL surface incremental progress (partial summaries, streaming, or step labels) so users are not left >10 seconds without feedback during long model calls.
• NFR-P3 (heavy jobs): Full three-pillar analysis, large organize passes, and bulk exports MAY run as async jobs with durable status and resumability; the UI SHALL communicate queued / running / failed states.
• NFR-P4 (exports): PRD HTML and Word generation for typical workspace sizes SHALL complete within a documented upper bound (to be set per tier) or degrade gracefully with user messaging.

Security & privacy

• NFR-S1 (isolation): Workspace data SHALL be logically isolated; cross-tenant access MUST be impossible through normal APIs (enforced at authorization + data layer).
• NFR-S2 (transport & storage): Traffic SHALL use TLS in production; sensitive configuration (API keys, integration tokens) SHALL not appear in client-visible logs or exports by default.
• NFR-S3 (authN/Z): Authentication and session handling SHALL follow industry baseline practices (secure cookies or tokens, rotation, lockout policies TBD); authorization MUST align with RBAC in FR3–FR4.
• NFR-S4 (Cipher alignment): Security audit findings (FR39–FR41) SHALL map to severity, remediation state, and block-ship rules consistent with product policy.
• NFR-S5 (privacy): The product SHALL support tenant data export and deletion requests for personal data held in workspaces to a GDPR-aligned baseline (exact DPA and subprocessors documented commercially).
• NFR-S6 (audit): Security-sensitive actions (FR45, FR43, overrides) SHALL be append-only auditable with actor, timestamp, and workspace context.

Scalability & reliability

• NFR-R1 (multi-tenant growth): Architecture SHALL support horizontal scaling of stateless app tiers and partitioned persistence so new tenants do not require manual resharding for V1–V2 scale targets.
• NFR-R2 (concurrency): Multiple users in one enterprise workspace SHALL be able to work concurrently without silent data loss; conflicts SHALL be detected and surfaced (merge, refresh, or lock—UX TBD).
• NFR-R3 (usage metering): Per-tenant session and token usage (premortem power users) SHALL be metered accurately for billing and fairness.
• NFR-R4 (availability): A target uptime SLO SHALL be defined pre-GA (e.g. 99.x% excluding planned maintenance); incident communication expectations SHALL be documented for enterprise.

Accessibility

Quorum's accessibility posture applies cross-cutting to every epic. Individual stories embed accessibility-specific acceptance criteria (see NFR-A3 below); this subsection captures the product-wide commitments, target compliance level, and ownership map across agent roles.

Target compliance level: WCAG 2.2 Level AA — minimum shippable bar, not an aspiration. Stories that cannot meet AA at ship time MUST document the gap and remediation plan before shipping.

Why this matters for Quorum specifically: Quorum sits in civic-adjacent territory (voting, governance, decision workflows). Public-sector, university, and nonprofit buyers routinely require VPATs or equivalent accessibility disclosures as a procurement gate. Accessibility is a market-access commitment, not just an ethical one.

• NFR-A1: The web application SHALL conform to WCAG 2.2 Level AA for all user-facing flows (team room, workspace navigation, poll drafting, voting, results, settings, onboarding) within V1 scope — or with documented phased remediation plans dated before GA for any gaps.
• NFR-A2: Motion and animation outputs SHALL respect prefers-reduced-motion preferences; Luca's motion specs include non-animated alternatives by default.
• NFR-A3 (cross-cutting AC requirement): Every shipped story SHALL include at least one accessibility-specific acceptance criterion (e.g., keyboard navigation verified, screen-reader sanity-checked, reading level confirmed, alt text present). Stories without this AC MUST be rejected in sprint planning review.
• NFR-A4 (content reading level): User-facing copy SHALL target grade 9 reading level or below (Flesch-Kincaid or equivalent) unless a documented domain requirement makes this impractical (e.g., legal consent language).
• NFR-A5 (accessibility statement): A public accessibility statement SHALL be published at quorum.app/accessibility listing current compliance target, known gaps, remediation timeline, and a contact for reporting issues.
• NFR-A6 (VPAT readiness): The product SHALL be prepared to produce a VPAT (Voluntary Product Accessibility Template) on request for enterprise procurement.
• NFR-A7 (regression discipline): Accessibility regressions caught in QA or post-ship SHALL be logged with severity and remediation timeline consistent with the security-severity ladder (NFR-S4).

Ownership map — which agent owns which slice of WCAG:

Path to a standalone Epic 12: If an enterprise customer demands a formal VPAT with remediation commitments or a third-party audit with blocking findings, the commitments in this section can be promoted to a dedicated Epic 12 — Accessibility program with its own stories (formal audit, remediation backlog, published statement with version history). Not scoped for MVP — embedded as cross-cutting requirements instead.

Integration & interoperability

• NFR-I1 (story handoff): Exported story artifacts SHALL validate against the published schema version and include version metadata so external tools can detect incompatibility.
• NFR-I2 (external APIs): Integrations (e.g. Jira/Notion) SHALL handle rate limits, timeouts, and partial failure with user-visible status and retry-safe behavior where idempotent.
• NFR-I3 (Figma handoff): Figma Make link/export flows SHALL preserve stable references (URL + workspace association) so concept drift is traceable.

Observability & operations

• NFR-O1: Production SHALL emit structured logs and metrics sufficient to debug tenant-specific issues without exposing other tenants’ content.
• NFR-O2: Critical background jobs SHALL support alerting on failure rates and queue backlog.