284 lines
13 KiB
Markdown
284 lines
13 KiB
Markdown
# Requirements Charter — AI-First Design Plan
|
||
|
||
---
|
||
|
||
## Core Principle
|
||
|
||
> **AI drives the process. Humans only veto, choose, or initiate.**
|
||
|
||
---
|
||
|
||
## Human Role (Redefined)
|
||
|
||
| Action | When | Cost |
|
||
|---|---|---|
|
||
| **Veto** | AI judgment is wrong | < 10s |
|
||
| **Choose** | AI cannot auto-converge | Pick from AI options, < 30s |
|
||
| **Initiate** | New direction or project | One trigger, AI takes over |
|
||
|
||
Everything else — writing, aligning, versioning, risk detection, scheduling, notifying — is fully owned by AI.
|
||
|
||
---
|
||
|
||
## 5 Hard Rules (AI-Enforced)
|
||
|
||
- [ ] **Upstream binding** — Charter is auto-generated from signal source; blank creation is blocked by AI
|
||
- [ ] **Alignment gate** — Downstream unlocks automatically after AI confirms alignment; no manual gate-keeping
|
||
- [ ] **Non-deletable structure** — 6 core modules enforced by AI at the logic layer, not just UI
|
||
- [ ] **Version lock** — AI auto-classifies minor fix vs. major version change; humans never manage versions manually
|
||
- [ ] **Full traceability** — All content, alignment records, versions, and tasks are bidirectionally linked and maintained by AI
|
||
|
||
---
|
||
|
||
## Page Layout
|
||
|
||
### Left Panel (280px, fixed)
|
||
|
||
- [ ] **SSTC Chain Status Card (120px)** — 6-node chain; AI highlights current node and auto-locks downstream until aligned; clicking a locked node shows AI-generated reason
|
||
- [ ] **Version List** — AI-managed; users see only the `Active` version by default; history visible on demand; AI auto-archives stale versions
|
||
- [ ] **Create Charter Button** — "From Signal Source" (primary); AI intercepts and blocks if no signal source exists; offers to auto-generate one from pasted content (chat logs, emails, meeting notes)
|
||
|
||
### Right Panel (75%)
|
||
|
||
#### Top Bar (100px, fixed)
|
||
- [ ] Charter name, version tag, status badge, bound project, last modified, owner — all AI-maintained
|
||
- [ ] Context actions by status:
|
||
|
||
| Status | Available Actions |
|
||
|---|---|
|
||
| Draft | `Save Draft` / `Initiate Alignment` |
|
||
| Aligning | `Veto Alignment` / `View AI Progress` |
|
||
| Aligned | `New Version` / `Export` / `View History` |
|
||
| Archived | `View History` / `Copy as New` |
|
||
|
||
---
|
||
|
||
## 6 Core Modules (Non-Deletable, AI-Driven)
|
||
|
||
Every module follows the same contract:
|
||
- [ ] Required metadata: `status`, `confidence_score`, `last_validated_at`, `evidence_refs[]`, `escalation_reason`
|
||
- [ ] AI must maintain traceability from each generated field back to signal source evidence
|
||
- [ ] If `confidence_score < 0.75` or source evidence conflicts, AI escalates for one human veto/accept decision
|
||
|
||
### Module 1 — Trigger & Goal
|
||
*Auto-generated from signal source. Human is veto-only.*
|
||
|
||
- [ ] **Inputs (required):** bound signal source IDs, target user segment, business context
|
||
- [ ] **Outputs (required):**
|
||
- One-sentence problem statement (max 120 chars, no vague terms)
|
||
- One-sentence goal with baseline, target, and due date
|
||
- 3–5 measurable KPIs (business + AI quality), each with `formula`, `baseline`, `target`, `owner`, `data_source`, `measurement_cadence`
|
||
- [ ] **AI validations:**
|
||
- KPI-to-source evidence mapping is complete
|
||
- KPI definitions are testable (no unverifiable wording)
|
||
- Goal and KPI are semantically consistent
|
||
- [ ] **Escalation trigger:** inconsistent evidence, non-testable KPI, or unresolved goal ambiguity
|
||
|
||
### Module 2 — Scope & Alignment Checklist
|
||
*AI auto-fills; humans review only low-confidence exceptions.*
|
||
|
||
- [ ] **Outputs (required):**
|
||
- In-scope: 3–7 features, each with acceptance condition
|
||
- Out-of-scope: 3–7 explicit exclusions, each with boundary example
|
||
- Fixed alignment Q&A (5 questions), each with answer + confidence + evidence ref:
|
||
- Who is the core user and what pain is prioritized?
|
||
- What is the launch date and immovable constraint?
|
||
- What is explicitly out of scope?
|
||
- What tech/model/third-party dependencies are required?
|
||
- What are top risks and mitigations?
|
||
- [ ] **AI validations:**
|
||
- Detect overlap/conflict between in-scope and out-of-scope
|
||
- Detect missing constraints (security, compliance, data/privacy, performance)
|
||
- Block alignment if unanswered critical checklist items exist
|
||
- [ ] **Escalation trigger:** any critical question with low confidence or conflicting source evidence
|
||
|
||
### Module 3 — AI Model & Tech Dependencies
|
||
*AI generates one canonical dependency model and serves role-specific views from it.*
|
||
|
||
- [ ] **Outputs (required):**
|
||
- Primary model + fallback model with selection rationale
|
||
- Capability table: context window, rate limits, latency range, token cost, known boundaries
|
||
- Dependency map: frameworks, external APIs, data stores, observability requirements
|
||
- Two synchronized views from one source of truth:
|
||
- Business view (non-technical language)
|
||
- Engineering view (technical specs and limits)
|
||
- [ ] **AI validations:**
|
||
- Budget simulation for P50/P90 workload
|
||
- Boundary stress check against expected input size and concurrency
|
||
- Semantic consistency check between business and engineering views
|
||
- [ ] **Escalation trigger:** no feasible model stack under budget/SLA constraints
|
||
|
||
### Module 4 — Timeline & Resource Planning
|
||
*AI schedules and allocates automatically; humans only veto exceptions.*
|
||
|
||
- [ ] **Outputs (required):**
|
||
- Milestone plan with `start`, `end`, `dependency`, `critical_path`
|
||
- Role-level effort estimates with confidence intervals
|
||
- Owner assignment from capability graph (not manual guessing)
|
||
- Buffer policy for delivery risk and handoff delays
|
||
- [ ] **AI validations:**
|
||
- Capacity check: default cap at 85% utilization per member
|
||
- Calendar check: timezone, holiday, leave windows
|
||
- Deadline risk simulation and recommended reallocation when risk exceeds threshold
|
||
- [ ] **Escalation trigger:** unresolved overload, missing capability match, or launch risk above allowed threshold
|
||
|
||
### Module 5 — Risks & Mitigations
|
||
*AI owns risk detection, monitoring, and first-response execution.*
|
||
|
||
- [ ] **Outputs (required):**
|
||
- Risk register with `category`, `probability`, `impact`, `trigger_signal`, `owner`, `mitigation`, `fallback_plan`
|
||
- Minimum coverage categories: tech, model, schedule, market, compliance/security
|
||
- Runtime trigger rules bound to alert center
|
||
- [ ] **AI validations:**
|
||
- High-risk items must include executable fallback steps and ETA
|
||
- Trigger signals must map to observable metrics/events
|
||
- Risk owner must exist in org graph and match capability domain
|
||
- [ ] **Execution rule:** when trigger fires, AI executes fallback, records action trail, and notifies affected owners
|
||
- [ ] **Escalation trigger:** fallback unavailable, owner missing, or mitigation fails repeatedly
|
||
|
||
### Module 6 — Attachments & Notes
|
||
*Optional in UI, mandatory in indexing and governance.*
|
||
|
||
- [ ] **Outputs (required):**
|
||
- Structured attachment metadata: `type`, `source`, `version`, `owner`, `confidentiality_level`, `linked_module`
|
||
- AI-generated summary and decision extraction for each attachment
|
||
- Search index + semantic tags for cross-project retrieval
|
||
- [ ] **AI validations:**
|
||
- Duplicate/conflict detection across attachment versions
|
||
- Broken link and inaccessible file detection
|
||
- Sensitive content scan with masking/redaction suggestion
|
||
- [ ] **Governance rule:** attachments are references only; source-of-truth fields must live in Modules 1–5
|
||
|
||
### Module Definition of Done (DoD)
|
||
|
||
- [ ] 100% required fields completed with evidence refs
|
||
- [ ] All module validations pass with no critical blockers
|
||
- [ ] Any escalated items resolved by single human veto/accept
|
||
- [ ] Module state is auditable and traceable in version history
|
||
|
||
---
|
||
|
||
## AI Alignment Engine (Replaces Manual Alignment Flow)
|
||
|
||
### New Alignment Logic: No Opposition = Aligned
|
||
|
||
- [ ] Charter locked and distributed to all members on alignment initiation
|
||
- [ ] Members have **24 hours** to raise objections; silence = consent
|
||
- [ ] AI monitors behavior signals (opened charter, acted on related tasks, no objection raised) to infer stance
|
||
- [ ] AI auto-records: `Active Confirmed` / `Implicit Consent` / `Objected` — all auditable
|
||
- [ ] If objection raised: AI analyzes disagreement, generates resolution proposal, pushes to relevant parties for a single accept/veto
|
||
- [ ] 100% resolved (by active confirmation or implicit consent) → AI auto-marks as `Aligned`, unlocks downstream
|
||
|
||
### Alignment Status Views
|
||
|
||
**Aligning**
|
||
- [ ] AI progress card: `X/N resolved` — breakdown of active confirms, implicit consents, pending objections
|
||
- [ ] Unresolved objections show AI-generated resolution proposals inline
|
||
- [ ] No manual "remind" buttons — AI handles follow-up autonomously
|
||
|
||
**Aligned**
|
||
- [ ] Green banner: "Charter aligned by AI. Downstream task breakdown unlocked."
|
||
- [ ] Permanent alignment record: timestamps, consent type, immutable
|
||
- [ ] `New Version` + `AI Breakdown Tasks` buttons
|
||
|
||
---
|
||
|
||
## AI Version Management
|
||
|
||
- [ ] AI classifies every change: **minor fix** (auto-merged, no new version) vs. **major change** (new version + re-alignment)
|
||
- [ ] Classification based on semantic diff + learned team behavior patterns
|
||
- [ ] If two parallel versions exceed 80% similarity, AI proposes merge
|
||
- [ ] Version tree auto-maintained by AI; stale branches auto-archived
|
||
- [ ] Humans always see only the current active version; history on demand
|
||
|
||
---
|
||
|
||
## AI Signal Source Engine (Cold Start Solution)
|
||
|
||
- [ ] AI connects to Feishu, email, meeting notes — continuously monitors for requirement signals in the background
|
||
- [ ] When a signal is detected, AI auto-generates a structured signal source draft and notifies PM: "Potential requirement detected. Create charter?"
|
||
- [ ] PM one-tap confirms → signal source + charter draft generated simultaneously
|
||
- [ ] If no integrations available: paste any raw content (chat screenshot, email, voice transcript) → AI structures it into a signal source + charter draft
|
||
- [ ] Cold-start rule: signal source binding is a **warning**, not a hard block, during first 30 days; AI tracks and prompts completion
|
||
|
||
---
|
||
|
||
## AI Capability Graph (Cold Start Solution)
|
||
|
||
- [ ] On first use: member confirms role + seniority (10 seconds)
|
||
- [ ] AI uses industry benchmark data as baseline
|
||
- [ ] After each task: AI auto-captures actual vs. estimated hours, updates capability model silently
|
||
- [ ] No manual input ever required again; model improves with every project
|
||
|
||
---
|
||
|
||
## AI Toolbar (Fixed, Below Modules)
|
||
|
||
| Button | Trigger | AI Action |
|
||
|---|---|---|
|
||
| Re-validate Charter | Before alignment | Full charter scan: vague expressions, missing fields, logical inconsistencies — auto-fixed where possible |
|
||
| Compare Versions | Has history | AI-generated semantic diff with change summary |
|
||
| Export Charter | Any status | PDF / Markdown with full alignment record |
|
||
|
||
---
|
||
|
||
## SSTC Chain Integration
|
||
|
||
- [ ] **Upstream**: signal source changes auto-trigger charter refresh; AI notifies owner of delta
|
||
- [ ] **Downstream lock**: task breakdown stays locked until AI confirms `Aligned` status
|
||
- [ ] **Task generation**: on alignment, AI auto-generates full task tree from charter — assigns owners, estimates hours, zero manual input
|
||
- [ ] **Execution sync**: major task delays auto-trigger charter change assessment by AI; escalates to human only if major revision needed
|
||
- [ ] **Retrospective**: AI auto-compares charter goals vs. actuals → generates retrospective report → feeds into team knowledge graph
|
||
|
||
---
|
||
|
||
## Mobile
|
||
|
||
- [ ] View-only (no editing on mobile)
|
||
- [ ] Collapsed module list, tap to expand
|
||
- [ ] One-tap veto or confirm
|
||
- [ ] Voice input for objections (AI transcribes + structures)
|
||
- [ ] Swipe left = version history, swipe right = alignment record
|
||
- [ ] Push notifications for alignment requests and AI-escalated decisions
|
||
|
||
---
|
||
|
||
## Dev Rollout — 3 Phases
|
||
|
||
### Phase 1 — Core Loop (Week 1)
|
||
- [ ] Left panel: AI-managed version list + chain status card
|
||
- [ ] 6 structured module editors with AI auto-fill
|
||
- [ ] AI alignment engine: 24h implicit consent, objection handling
|
||
- [ ] Downstream auto-unlock on alignment
|
||
- [ ] AI version classification (minor fix vs. major change)
|
||
|
||
### Phase 2 — AI-Native (Week 2)
|
||
- [ ] Real-time vague expression detection + auto-fix
|
||
- [ ] AI self-validation (cross-check generated content)
|
||
- [ ] Role-aware dual-language view for Module 3
|
||
- [ ] Model binding + match evaluation + capability boundary validation
|
||
- [ ] Signal source auto-detection (Feishu / email integration)
|
||
- [ ] Task auto-generation from charter on alignment
|
||
|
||
### Phase 3 — Polish & Advanced (Week 3+)
|
||
- [ ] Capability graph auto-learning from task execution
|
||
- [ ] Version merge suggestions + version tree visualization
|
||
- [ ] Mobile adaptation
|
||
- [ ] Feishu card actions (veto / confirm directly in Feishu)
|
||
- [ ] Retrospective auto-report generation
|
||
- [ ] Charter template library
|
||
|
||
---
|
||
|
||
## Summary: What Changed vs. Original Plan
|
||
|
||
| Original | AI-First |
|
||
|---|---|
|
||
| 100% manual confirmation to unlock downstream | 24h no-objection = aligned, AI records |
|
||
| AI assists human writing | AI writes + self-validates; human vetoes |
|
||
| Human creates signal sources | AI detects signals proactively; human one-tap confirms |
|
||
| Human manages versions | AI fully manages; human sees active version only |
|
||
| All members see one charter | AI serves role-appropriate language view per member |
|
||
| Human fills capability graph | AI learns from task execution automatically |
|
||
| AI is a feature | AI is the process engine; humans are veto holders |
|