# Project Governance

Project charter, brief, risk register, RACI, communication plan

# Project Charter: Drop — Fintech Payment App

# Project Charter: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.1
> **Date:** 2026-02-08 (updated 2026-02-23)
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-08 | John | Initial draft |
| 1.0 | 2026-02-13 | John | Updated after Phase 0.5 security sprint |
| 1.1 | 2026-02-23 | John | Aligned with ROADMAP.md and current pipeline state |

---

## 1. Vision & Mission

**Vision:** Drop becomes the default payment tool for all residents in Norway who need to send money abroad or pay at local businesses — capturing the remittance + QR payments market that no single app currently serves together.

**Mission:** Build a PSD2 pass-through fintech app (never holding customer money) that offers remittance at 0.5% and QR merchant payments at 1%, powered by Open Banking — cheaper and simpler than every existing alternative.

**Strategic Alignment:** Drop is ALAI Holding AS's flagship product, demonstrating AI-native product development from zero to market. It aligns with ALAI's mission to "build digital" and generates recurring revenue through transaction fees. Innovasjon Norge Oppstartstilskudd (150K NOK) provides initial runway.

---

## 2. Scope

### 2.1 In Scope — Deliverables

| # | Deliverable | Description | Acceptance Criteria Summary |
|---|-------------|-------------|-----------------------------|
| D-01 | Web App (Next.js) | Full-featured payment app with 10 screens | All pages functional, deployed to staging at drop-staging.fly.dev |
| D-02 | Remittance Flow | Send money to 30+ countries at 0.5% fee via PISP | User can initiate transfer; 6 corridors working (RS, BA, PK, TR, PL, EUR) |
| D-03 | QR Payment Flow | Pay merchants by scanning QR code at 1% fee | Merchant QR generated; customer scan + payment flow functional |
| D-04 | Open Banking Integration | AISP (read balance) + PISP (initiate payments) via BaaS partner | Real bank connection via BankID + selected BaaS provider |
| D-05 | KYC + BankID Onboarding | Identity verification, age 18+, Norwegian residency | Users verified via BankID; KYC status tracked per user |
| D-06 | Landing Page | Marketing site at getdrop.no with waitlist | Live on Vercel; waitlist collecting emails |
| D-07 | CI/CD + Monitoring | GitHub Actions pipeline + Fly.io deployment | All tests green in CI; staging auto-deploys on merge |

### 2.2 Out of Scope

- Physical card issuance (feature-flagged, requires card partner)
- Wallet / balance holding (Drop is pass-through — no float)
- Crypto payments or asset trading
- Lending or credit products
- Under-18 user support (requires separate legal review)
- White-label product for other companies (Phase 4 roadmap item)
- Real money movement in MVP demo (mock Open Banking until licence obtained)
- Content creation, translations beyond Norwegian/English

### 2.3 Assumptions

| # | Assumption | Risk if False | Owner to Validate |
|---|------------|---------------|-------------------|
| A-01 | BaaS partner (Swan or SpareBank1) confirms by Phase 2 | Phase 2 blocked indefinitely | Alem |
| A-02 | Finanstilsynet PISP/AISP registration process takes ~3 months | Launch delayed | Alem + Legal advisor |
| A-03 | Users have Norwegian BankID and +47 phone | Onboarding conversion low | Alem (user research) |
| A-04 | Open Banking APIs from BaaS provider are stable | Integration rework required | John |
| A-05 | Innovasjon Norge grant (150K NOK) is approved | Cash flow gap before revenue | Alem |

### 2.4 Constraints

| # | Constraint | Category | Impact |
|---|------------|----------|--------|
| C-01 | Drop NEVER holds customer money (PSD2 pass-through model) | Legal / Regulatory | Architecture must use AISP/PISP only |
| C-02 | Minimum user age: 18 (BankID DOB validation) | Legal | Onboarding must validate DOB |
| C-03 | NEVER use word "banking" without licence disclaimer | Legal | All copy must be reviewed |
| C-04 | Norwegian BankID required for onboarding | Technical | Locks market to Norway initially |
| C-05 | Budget: ~250K NOK total (150K Innovasjon Norge + bootstrap) | Financial | AI-first development to minimise costs |
| C-06 | PCI-DSS: NEVER store or expose full card numbers/CVV | Security | Cards feature requires tokenisation partner |

---

## 3. Stakeholder Register

| ID | Name | Organization | Role | Interest | Influence | Engagement Strategy | Contact |
|----|------|--------------|------|----------|-----------|---------------------|---------|
| S-01 | Alem Bašić | ALAI Holding AS | CEO / Sponsor | Strategic success, revenue, brand | High | Direct sessions, all major decisions | alem@alai.no |
| S-02 | John | ALAI Holding AS | AI Director / Product Owner | Technical delivery, product quality | High | Daily async, all sprint reviews | — |
| S-03 | SpareBank1 contact | SpareBank1 | Banking Partner Candidate | Partnership revenue, market expansion | High | Quarterly meetings, pitch materials | Via Alem |
| S-04 | Swan (BaaS) | Swan.io | BaaS Provider Candidate | API adoption, merchant fees | Medium | Technical integration discussions | Via John |
| S-05 | Finanstilsynet | Norwegian FSA | Regulator | PSD2 compliance, consumer protection | High | Formal registration process | Via legal advisor |
| S-06 | Early users (waitlist) | — | End Users | Cheap remittance, easy QR payments | Low | Waitlist comms, beta invitations | hei@getdrop.no |
| S-07 | Local merchants | Oslo area | Merchant Users | Lower fees than Vipps, easy setup | Medium | Door-to-door onboarding | Alem |

**Key Decision Makers:**
- Final scope decisions: Alem Bašić (CEO)
- Technical architecture approval: John (AI Director)
- Budget approval: Alem Bašić
- Contract/legal: Alem Bašić + external legal advisor

---

## 4. Budget Summary

| Line Item | Amount (NOK) | % of Total | Notes |
|-----------|-------------|------------|-------|
| Development (AI-first) | 10,000 | 4% | Claude Code + tooling costs |
| Open Banking integration (PSD2) | 15,000 | 6% | BaaS setup + API costs |
| Legal + compliance setup | 50,000 | 20% | Finanstilsynet registration, legal review |
| Marketing launch | 100,000 | 40% | Social media, local merchant onboarding |
| QR stickers + merchant kits | 20,000 | 8% | Physical materials |
| Buffer / contingency | 55,000 | 22% | Unexpected costs |
| **Total Budget** | **250,000** | **100%** | |

**Payment Schedule:** Internal project — Innovasjon Norge Oppstartstilskudd (~150K NOK) + bootstrapped by ALAI.

| Milestone | Amount (NOK) | Source |
|-----------|-------------|--------|
| Phase 0.5 completion (security hardening) | 0 (AI cost only) | ALAI bootstrap |
| Phase 1 (demo app) | ~25,000 | Innovasjon Norge |
| Phase 2 (bank integration) | ~125,000 | Innovasjon Norge |
| Phase 3 (launch) | ~100,000 | Revenue + grant |

---

## 5. Timeline & Milestones

| # | Milestone | Target Date | Gate Condition | Owner |
|---|-----------|-------------|----------------|-------|
| M-01 | Phase 0 — Foundation | 2026-02-08 | Landing page live, brand done, pipeline test passed | John |
| M-02 | Phase 0.5 — MVP Hardening | 2026-02-20 | Security audit passed, 217 tests green, staging live | John |
| M-03 | Phase 1 — Demo App | 2026-03-15 | Full 10-screen app functional, investor-ready demo | John |
| M-04 | BaaS Partner Decision | 2026-03-01 | SpareBank1 answer or Swan signed | Alem |
| M-05 | Phase 2 — Banking Integration | 2026-04-30 | Real BankID, AISP, PISP working with 10 beta users | John |
| M-06 | Finanstilsynet Registration | 2026-05-15 | PISP/AISP licence submitted | Alem + Legal |
| M-07 | Phase 3 — Production Launch | 2026-06-15 | App Store + Play Store live, 200 merchants onboarded | John + Alem |
| M-08 | Post-launch Review | 2026-07-15 | 1,000 users, monitoring active, external pentest done | John |

**Gantt Diagram:**

```mermaid
gantt
    title Drop — Project Timeline
    dateFormat  YYYY-MM-DD
    section Foundation
    Phase 0 Foundation       :done, p0, 2026-02-08, 7d
    Phase 0.5 Hardening      :done, p05, after p0, 14d
    section Demo
    Phase 1 Demo App         :active, p1, 2026-02-20, 28d
    section Integration
    BaaS Partner Decision    :milestone, baas, 2026-03-01, 1d
    Phase 2 Banking          :p2, after p1, 56d
    Finanstilsynet Filing    :milestone, reg, 2026-05-15, 1d
    section Launch
    Phase 3 Production       :p3, 2026-05-15, 30d
    Go Live                  :milestone, live, 2026-06-15, 1d
```

---

## 6. Success Criteria & KPIs

| # | Success Criterion | KPI / Metric | Target | Measurement Method | Evaluation Point |
|---|-------------------|-------------|--------|--------------------|------------------|
| SC-01 | Revenue generation | Monthly Recurring Revenue | 130,000 NOK/month | Transaction logs | Month 12 post-launch |
| SC-02 | User acquisition | Registered users | 3,000 | App analytics | Month 12 post-launch |
| SC-03 | Merchant adoption | Onboarded merchants | 200 | Merchant dashboard | Month 12 post-launch |
| SC-04 | System performance | API response time p95 | < 500ms | Monitoring | Launch + 30 days |
| SC-05 | Security posture | Security score | ≥ 80/100 | Security audit | Pre-launch |
| SC-06 | Transaction reliability | Payment success rate | ≥ 99% | Transaction logs | Ongoing post-launch |
| SC-07 | Fee competitiveness | Remittance fee vs Wise | 0.5% vs 0.7-1.5% | Competitor monitoring | Ongoing |

---

## 7. Dependencies

| # | Dependency | Type | Impact if Delayed | Owner | Target Date | Status |
|---|-----------|------|-------------------|-------|-------------|--------|
| DEP-01 | BaaS provider (Swan or SpareBank1) | External | Phase 2+ blocked | Alem | 2026-03-01 | SpareBank1 pitched; awaiting |
| DEP-02 | Finanstilsynet PISP/AISP registration | External / Regulatory | Real payments blocked | Alem + Legal | 2026-05-15 | Not started |
| DEP-03 | BankID integration via BaaS | External | SCA/onboarding blocked | John | After BaaS selected | Pending BaaS |
| DEP-04 | KYC provider (Sumsub or partner KYC) | External | AML compliance blocked | John | After BaaS selected | Mock in place |
| DEP-05 | Phase 0.5 security hardening | Internal | Phase 1 blocked | John | 2026-02-20 | In progress |

---

## 8. Governance Model

### 8.1 Decision-Making Authority

| Decision Category | Authority | Must Consult | Must Inform |
|-------------------|-----------|--------------|-------------|
| Scope changes | Alem (CEO) | John | All stakeholders |
| Architecture decisions | John (AI Director) | Tech Lead agents | Alem |
| Budget changes > 10% | Alem | John | — |
| Release go/no-go | John | QA agents | Alem |
| Partner/legal decisions | Alem | John + Legal advisor | — |
| Team / agent changes | John | — | Alem |

### 8.2 Change Control Process Summary

1. **Request:** Any stakeholder raises change request via `change-request.md` template
2. **Impact Analysis:** John assesses scope, timeline, budget within 3 business days
3. **Decision:** Alem approves/rejects within 2 business days
4. **Budget changes > 10%:** Require Alem explicit approval via session
5. **Implementation:** Approved changes logged in `comms/decisions/`, scheduled in roadmap
6. **Communication:** All stakeholders notified within 24 hours

### 8.3 Escalation Hierarchy

```
L1: Agent → John (response: 4 hours)
L2: John → Alem (response: 24 hours — strategic/financial only)
L3: Alem → External advisor (legal/regulatory only)
```

---

## 9. Team & Roles

| Role | Agent / Person | Responsibilities | Availability |
|------|---------------|-----------------|--------------|
| Project Sponsor / CEO | Alem Bašić | Strategic direction, partnerships, budget approvals, regulatory | Part-time (decisions + partnerships) |
| AI Director | John (Claude Opus) | Delivery accountability, architecture, agent coordination | Full-time |
| Developer / Builder | Builder (Claude Sonnet) | Feature implementation, API routes, frontend pages | Per-task |
| QA / Validator | Validator (Claude Sonnet) | Testing, validation, code review | Per-task |
| Security | Security agent (Claude) | Threat modelling, audit, compliance | Per-sprint |
| Legal | Legal agent (Claude) | Regulatory review, document drafting | As needed |
| Finance | Finance agent (Claude) | Budget analysis, projections | As needed |

---

## 10. Risk Summary

| # | Risk | Probability | Impact | Mitigation |
|---|------|------------|--------|------------|
| R-01 | Banking partner / BaaS not secured in time | High | High | Multi-provider approach; Swan as backup to SpareBank1 |
| R-02 | Finanstilsynet registration delayed | Medium | High | Start process early; operate under bank partner licence initially |
| R-03 | Security breach before production hardening | Low | Critical | Security audit completed; 8 critical fixes tracked; no real money in MVP |
| R-04 | Vipps launches remittance product | Medium | High | Already ahead in market; community trust and lower fees are moat |
| R-05 | Slow merchant adoption | Medium | Medium | Door-to-door in local communities; 0% fee for first 3 months |

> Full risk register: `[risk-register.md](risk-register.md)`

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-08 | Approved (AI) |
| Reviewer | John (AI Director) | 2026-02-23 | Reviewed (AI) |
| AI Director (John) | John | 2026-02-08 | Approved |
| Project Sponsor | Alem Bašić | 2026-02-08 | Approved |
| CEO | Alem Bašić | 2026-02-08 | Approved |

# Project Brief: Drop — Fintech Payment App

# Project Brief: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments for Scandinavia
> **Version:** 1.0
> **Date:** 2026-02-08
> **Author:** John (AI Director) + product agent
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-08 | product agent | Initial discovery brief |
| 1.0 | 2026-02-08 | John | Finalised after 2-round agent analysis |

---

## 1. Executive Summary

Drop is a fintech payment app for all residents in Norway/Scandinavia, offering remittance at 0.5% fee (vs Western Union 5-10%, Wise 0.7-1.5%) and QR merchant payments at 1% (vs Vipps 1.75-2.75%). Built on PSD2 Open Banking — Drop never holds customer money; payments are initiated directly from users' bank accounts via PISP. The Norwegian remittance market is worth 5.7 billion NOK annually, and no existing app combines both remittance and QR payments. ALAI Holding AS (org.nr 932 516 136), led by CEO Alem Bašić, is building Drop as an AI-native product with total startup costs of ~250K NOK, targeting break-even within 7-9 months of launch. Decision: GO.

---

## 2. Business Context & Market Opportunity

### 2.1 Business Context

Norway has ~1,000,000 immigrants (SSB data) who collectively send 5.7 billion NOK abroad annually. They are systematically overcharged by Western Union (5-10% fees), and underserved by Wise and Revolut (generic, not community-focused). At the same time, local immigrant-owned businesses are paying Vipps 1.75-2.75% per transaction — a significant cost for low-margin businesses (kebab shops, kiosks, bakeries, barbers). Alem Bašić identified this dual pain from personal experience as a community member.

### 2.2 Market Opportunity

| Dimension | Current State | Opportunity |
|-----------|--------------|-------------|
| Market Size | 5.7B NOK annual remittance from Norway | Capture 1% = 57M NOK ARR potential |
| Target Segment | ~1M immigrants + ~195K SMEs in Norway | Broad appeal beyond diaspora |
| Growth Rate | Remittance market growing 8% YoY | Early mover advantage |
| Key Trend | PSD2 Open Banking enabling pass-through payments | No legacy infrastructure cost |

### 2.3 Strategic Fit

This project directly supports:
- **Strategic Goal:** ALAI Holding AS establishing recurring revenue through own fintech product
- **OKR / Initiative:** Innovasjon Norge Oppstartstilskudd application — drop as flagship product
- **Alignment with ALAI mission:** "Build digital. You build business." — Drop demonstrates AI-native product delivery and generates recurring transaction fee revenue for ALAI

---

## 3. Problem Statement

### 3.1 Core Problem

Residents of Norway with international money transfer needs and local payment needs are served by fragmented, expensive, or poorly designed tools. No single app combines affordable international remittance (< 1% fee) with QR-based local merchant payments (< 1.5% fee) in the Norwegian market.

### 3.2 Pain Points

| # | Pain Point | Affected Stakeholder | Measurable Impact |
|---|-----------|---------------------|-------------------|
| P-01 | International transfers cost 5-10% (Western Union) | Immigrants sending money home | ~285M NOK/year overcharged on 5.7B NOK market at 5% avg |
| P-02 | Vipps merchant fees (1.75-2.75%) eat into thin margins | Local small businesses | Kebab shop at 50K NOK/month pays 875-1,375 NOK in fees |
| P-03 | Existing remittance apps (Wise, Revolut) not designed for community trust | Immigrant communities | Low adoption due to UX and cultural mismatch |
| P-04 | No combined remittance + QR app exists in Norway | All residents | Users need 2+ apps; no flywheel effect |

### 3.3 Current State Gaps

**Current Process/System:** Users use Western Union / MoneyGram for remittance and Vipps for local payments. Two separate apps, two fee structures, zero integration.

**Key Gaps:**
- No single app covers remittance + QR payments in Norway
- Existing remittance providers charge 5-10x more than technically necessary with Open Banking
- Vipps dominates local payments but has no international capability and charges merchants heavily
- No PSD2 pass-through model used by remittance apps — they all hold money (compliance risk for users)

**Cost of Inaction:** ALAI has no recurring product revenue. The window to enter before a major player copies the remittance + QR combo is estimated at 12-18 months.

---

## 4. Proposed Solution Overview

### 4.1 Solution Description

Drop is a mobile-first web app (PWA/React Native path) built on PSD2 Open Banking. Users link their Norwegian bank account via BankID. Remittances are initiated as PISP bank transfers directly from the user's account (no top-up, no wallet). QR payments work the same way — merchant generates a QR code, customer scans and confirms, payment goes directly from bank account to merchant settlement. Drop never holds funds. Revenue: 0.5% remittance fee + 1% merchant fee.

### 4.2 Key Capabilities

| # | Capability | Addresses Pain Point | Priority |
|---|-----------|---------------------|----------|
| CAP-01 | Remittance to 30+ countries at 0.5% | P-01 | Must Have |
| CAP-02 | QR merchant payments at 1% | P-02 | Must Have |
| CAP-03 | BankID onboarding + KYC | P-03 | Must Have |
| CAP-04 | Open Banking AISP (balance view) | P-04 | Must Have |
| CAP-05 | Transaction history and notifications | P-04 | Should Have |
| CAP-06 | Merchant dashboard (analytics + QR generation) | P-02 | Should Have |
| CAP-07 | Loyalty / rewards programme | P-03 | Could Have |

### 4.3 Solution Architecture (High Level)

```mermaid
graph LR
    A[User / Merchant] --> B[Drop Web App - Next.js]
    B --> C[Drop API - Next.js API Routes]
    C --> D[PostgreSQL Database]
    C --> E[BaaS Provider - Swan or SpareBank1]
    E --> F[Norwegian Banks via PSD2]
    E --> G[BankID - SCA]
    E --> H[KYC Provider - Sumsub]
    C --> I[Remittance Corridors - 30+ countries]
```

### 4.4 Platforms & Channels

- [x] Web Application (Next.js — primary platform)
- [x] iOS Mobile App (Expo React Native — Phase 2+)
- [x] Android Mobile App (Expo React Native — Phase 2+)
- [x] API / Backend Service (Next.js API Routes)
- [x] Admin/Merchant Dashboard (included in web app)
- [ ] Other: Landing page at getdrop.no (Vercel, live)

---

## 5. Key Benefits & ROI Projection

### 5.1 Quantified Benefits

| Benefit Category | Description | Estimated Annual Value |
|-----------------|-------------|------------------------|
| Revenue (remittance fees) | 3,000 users × 2 tx/month × 1,000 NOK × 0.5% | 360,000 NOK/year (Year 1) |
| Revenue (merchant fees) | 200 merchants × 50,000 NOK/month × 1% | 1,200,000 NOK/year (Year 1) |
| Cost reduction vs agencies | AI-first dev: 10K vs typical 500K NOK agency cost | 490,000 NOK saved |
| **Total Annual Benefit (Year 1)** | | **~1,560,000 NOK** |

### 5.2 ROI Calculation

| Metric | Value |
|--------|-------|
| Total Investment (Year 1) | 250,000 NOK |
| Total Annual Benefit (Year 1) | ~1,560,000 NOK |
| Payback Period | 7-9 months |
| 3-Year ROI | ~1,800% |
| Net Present Value (3yr) | ~10,000,000 NOK |

> _Assumptions: 200 merchants at 50K NOK/month average transaction volume; 3,000 consumers sending 1,000 NOK twice per month; 0.5% remittance fee; 1% merchant fee. Conservative projections per business case v2.1._

### 5.3 Qualitative Benefits

- **Brand/Reputation:** ALAI positioned as community-first fintech builder in Norway; trust from immigrant communities
- **Competitive Advantage:** Only app combining remittance + QR payments in Norway; 2-4x cheaper than alternatives
- **Risk Reduction:** PSD2 pass-through model eliminates e-money licence requirement; no money held = lower regulatory burden
- **Employee/User Experience:** BankID-native, Norwegian-language UX; designed for local community trust

---

## 6. High-Level Requirements

| # | Requirement | Type | Priority | Notes |
|---|------------|------|----------|-------|
| HLR-01 | Users must verify identity via Norwegian BankID | Functional | Must Have | Age ≥ 18, Norwegian residency |
| HLR-02 | Remittance to 30+ countries via PISP | Functional | Must Have | 6 corridors in MVP: RS, BA, PK, TR, PL, EUR |
| HLR-03 | QR merchant payments via PISP | Functional | Must Have | Merchant generates QR; user scans + pays |
| HLR-04 | Drop NEVER holds customer money | Legal | Must Have | PSD2 pass-through only |
| HLR-05 | GDPR compliance for Norwegian users | Non-Functional | Must Have | Data minimisation, consent, right to deletion |
| HLR-06 | NEVER use word "banking" without licence disclaimer | Legal | Must Have | Marketing and UI copy constraint |
| HLR-07 | 99.9% uptime SLA for payment flows | Non-Functional | Should Have | Financial reliability requirement |
| HLR-08 | Transaction history with filters | Functional | Should Have | User-facing transaction log |

---

## 7. Competitive Landscape

| Alternative | Type | Strengths | Weaknesses | Why Drop Wins |
|------------|------|-----------|------------|---------------|
| Western Union / MoneyGram | Direct (remittance) | Brand recognition, physical presence | 5-10% fees, outdated UX | 10-20x cheaper, mobile-native |
| Wise | Direct (remittance) | Low fees (0.7-1.5%), trusted brand | No QR payments, generic/not local | 0.5% vs 0.7-1.5%; QR combo unique |
| Vipps | Direct (QR payments) | Massive Norwegian market share | No remittance, 1.75-2.75% merchant fee | Drop does both; 50% cheaper for merchants |
| Revolut | Indirect | Feature-rich, international | Complex, not community-focused, no QR | Simpler UX, community trust, QR payments |

**Our Unique Value Proposition:** Drop is the only app in Norway combining cheap remittance (0.5%) AND QR merchant payments (1%) in a single, BankID-native, community-trusted platform. No wallet. No top-up. Money stays in your bank.

---

## 8. Resource Requirements

### 8.1 Team

| Role | Effort | Source |
|------|--------|--------|
| CEO / Sponsor | 20% time (decisions, partnerships) | Alem Bašić (ALAI) |
| AI Director / Product Owner | Full-time | John (ALAI internal AI) |
| Builder agents | Per-task (Claude Sonnet) | ALAI internal AI |
| Validator agents | Per-task (Claude Sonnet) | ALAI internal AI |
| Legal advisor | As needed | External (TBD) |

### 8.2 Budget Summary

| Category | Estimated Cost (NOK) |
|----------|---------------------|
| Development (AI-first) | 10,000 |
| Open Banking / BaaS integration | 15,000 |
| Legal + compliance | 50,000 |
| Marketing launch | 100,000 |
| QR stickers + merchant kits | 20,000 |
| Contingency (22%) | 55,000 |
| **Total** | **250,000** |

### 8.3 Timeline

| Phase | Duration | Start |
|-------|----------|-------|
| Phase 0.5 — Security Hardening | 2 weeks | 2026-02-08 |
| Phase 1 — Demo App | 4 weeks | 2026-02-20 |
| Phase 2 — Banking Integration | 8 weeks | 2026-03-20 |
| Phase 3 — Launch | 6 weeks | 2026-05-15 |
| **Total Duration** | **~20 weeks** | **2026-02-08** |

---

## 9. Go / No-Go Decision Criteria

### 9.1 Go Criteria (ALL must be met)

- [x] Budget approved: 250,000 NOK (Innovasjon Norge + bootstrap)
- [x] CEO aligned on scope and timeline
- [x] MVP security hardening complete before demo
- [x] Legal review completed (no "banking" in copy; pass-through model validated)
- [x] AI-first development approach validated (10K NOK dev cost)

### 9.2 No-Go Triggers (ANY is sufficient to stop)

- [ ] BaaS partner unavailable and no alternative within 3 months of Phase 2 start
- [ ] Finanstilsynet identifies blocker to PISP/AISP registration
- [ ] Security breach before production hardening complete
- [ ] Budget overrun > 30% without revenue to cover

### 9.3 Decision

| Dimension | Decision | Decision Maker | Date |
|-----------|---------|---------------|------|
| Proceed with planning | GO | Alem Bašić | 2026-02-08 |
| Budget approved | Yes | Alem Bašić | 2026-02-08 |
| Resource allocation approved | Yes | Alem Bašić | 2026-02-08 |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-08 | Approved (AI) |
| Reviewer | John (AI Director) | 2026-02-08 | Reviewed |
| AI Director (John) | John | 2026-02-08 | Approved |
| Project Sponsor | Alem Bašić | 2026-02-08 | Approved |
| CEO | Alem Bašić | 2026-02-08 | Approved |

# Risk Register: Drop — Fintech Payment App

# Risk Register: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.1
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Active
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-08 | legal agent + finance agent | Initial 2-round risk identification |
| 1.0 | 2026-02-11 | John | Added technical risks from security audit |
| 1.1 | 2026-02-23 | John | Closed resolved risks; updated statuses |

---

## 1. Risk Identification Methodology

**Identification Methods Used:**
- [x] 2-round multi-agent analysis (8 agents: legal, finance, security, dev, marketer, data-engineer, product, nicksaraev)
- [x] Security audit (2026-02-11, John — 1,102 lines of API code reviewed)
- [x] Regulatory risk checklist (PSD2, AML, GDPR, DORA — gap analysis in security/COMPLIANCE.md)
- [x] Business case risk matrix (zica-business-case-v2.md section 10)
- [x] Assumption analysis (project charter)

**Initial Risk Assessment Date:** 2026-02-08
**Next Scheduled Review:** 2026-03-01 (sprint planning)
**Risk Owner:** John (AI Director)

---

## 2. Risk Categories

| Category | Description | Common Examples |
|----------|-------------|----------------|
| **Technical** | Technology failures, integration issues, performance, security | JWT secrets, SQLite limits, API race conditions |
| **Resource** | Team availability, skill gaps, single points of failure | Alem sole decision-maker, AI cost overruns |
| **External** | Third-party dependencies, regulatory changes, market shifts | BaaS partner, Finanstilsynet, Vipps competition |
| **Financial** | Budget overruns, payment delays, cost estimates | Grant approval delay, marketing burn |
| **Regulatory** | Compliance failures, licence requirements, penalties | PSD2 licence, AML, GDPR, PCI-DSS |
| **Quality** | Defect rate, technical debt, process failures | Security vulnerabilities, untested integrations |

---

## 3. Risk Probability & Impact Scale

### 3.1 Probability Scale

| Level | Score | Definition |
|-------|-------|------------|
| Very Low | 1 | < 10% chance |
| Low | 2 | 10–30% chance |
| Medium | 3 | 30–50% chance |
| High | 4 | 50–70% chance |
| Very High | 5 | > 70% chance |

### 3.2 Impact Scale

| Level | Score | Schedule Impact | Financial Impact |
|-------|-------|----------------|-----------------|
| Negligible | 1 | < 1 day | < 1% budget |
| Minor | 2 | 1–3 days | 1–5% budget |
| Moderate | 3 | 3–7 days | 5–10% budget |
| Major | 4 | 1–2 weeks | 10–20% budget |
| Critical | 5 | > 2 weeks | Project failure |

### 3.3 Risk Matrix

| Score | Risk Level | Response Required | Escalation |
|-------|-----------|-------------------|------------|
| 1–4 | LOW | Monitor monthly | PM awareness |
| 5–9 | MEDIUM | Active mitigation plan | John awareness |
| 10–14 | HIGH | Immediate action + weekly review | John escalation |
| 15–25 | CRITICAL | Emergency response | John + Alem |

---

## 4. Risk Appetite Statement

**Overall Risk Appetite:** LOW (fintech — money movement requires high safety standards)

| Risk Category | Appetite | Rationale |
|--------------|----------|-----------|
| Technical (security) | Very Low | Financial app — zero tolerance for data breaches |
| Regulatory | Very Low | GDPR, PSD2, AML violations have criminal penalties |
| Financial | Low | Fixed budget; overruns require Alem approval |
| External (BaaS) | Medium | Modular architecture allows provider swap |
| Timeline | Medium | Some schedule flexibility acceptable |
| Competition | High | Market risk accepted; innovation is our moat |

---

## 5. Active Risk Register

| ID | Risk Description | Category | Prob (1-5) | Impact (1-5) | Score | Response Strategy | Owner | Status | Date Identified |
|----|-----------------|----------|------------|-------------|-------|-------------------|-------|--------|-----------------|
| R-001 | BaaS partner (Swan or SpareBank1) not confirmed — blocks Phase 2 Open Banking integration | External | 4 | 5 | 20 | Mitigate | Alem | Mitigating — SpareBank1 pitched; Swan backup | 2026-02-08 |
| R-002 | Finanstilsynet PISP/AISP registration delayed beyond planned timeline | Regulatory | 4 | 5 | 20 | Mitigate | Alem + Legal | Open — not started | 2026-02-08 |
| R-003 | Security breach before production hardening complete | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — audit done; 8 critical fixes tracked | 2026-02-11 |
| R-004 | Vipps launches competing remittance feature | External | 3 | 4 | 12 | Accept | Alem | Monitoring | 2026-02-08 |
| R-005 | Slow merchant adoption — QR revenue below projection | External | 3 | 3 | 9 | Mitigate | Alem | Open — door-to-door strategy planned | 2026-02-08 |
| R-006 | Hardcoded JWT_SECRET fallback active in production | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — fix tracked in Phase 0.5 | 2026-02-11 |
| R-007 | CVV/card data exposed via GET API endpoint (PCI-DSS violation) | Regulatory | 2 | 5 | 10 | Mitigate | John | Mitigating — last_four only; fix in Phase 0.5 | 2026-02-11 |
| R-008 | SQLite single-writer bottleneck at 200+ concurrent users | Technical | 2 | 3 | 6 | Accept | John | Accepted for MVP; PostgreSQL migration planned | 2026-02-13 |
| R-009 | Alem is sole human decision-maker — decision bottleneck | Resource | 3 | 3 | 9 | Mitigate | Alem | Mitigating — decisions logged in comms/decisions/ | 2026-02-08 |
| R-010 | KYC mock in production — AML compliance not active | Regulatory | 2 | 5 | 10 | Mitigate | John | Open — Sumsub production required before real money | 2026-02-13 |
| R-011 | No real BankID — DOB proxy insufficient for SCA | Technical / Regulatory | 2 | 4 | 8 | Mitigate | John | Open — Phase 1 is demo only; BankID in Phase 2 | 2026-02-13 |
| R-012 | In-memory rate limiter resets on process restart — brute force risk | Technical | 2 | 4 | 8 | Mitigate | John | Mitigating — DB-backed rate limits in Phase 0.5 | 2026-02-11 |
| R-013 | No CSRF protection on state-changing API endpoints | Technical | 2 | 4 | 8 | Mitigate | John | Mitigating — CSRF middleware in Phase 0.5 | 2026-02-11 |
| R-014 | Cash flow gap if Innovasjon Norge grant delayed | Financial | 3 | 3 | 9 | Mitigate | Alem | Monitoring — AI costs keep burn < 10K/month | 2026-02-08 |
| R-015 | Race condition on concurrent remittance transactions (double-spend) | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — per-user transaction lock implementation | 2026-02-11 |

---

## 6. Risk Response Strategies

| Risk ID | Strategy | Response Actions | Contingency Plan |
|---------|----------|-----------------|------------------|
| R-001 | Mitigate | 1. SpareBank1 pitch submitted; 2. Swan evaluated as backup; 3. Modular BaaS interface in architecture | If neither works: explore Wio Bank, Finom, Treezor |
| R-002 | Mitigate | 1. Engage external legal advisor for Finanstilsynet process; 2. Apply early; 3. Operate under bank partner licence initially | If delayed: launch in limited beta under partner licence |
| R-003 | Mitigate | 1. Security audit complete; 2. Phase 0.5 sprint fixes 8 critical issues; 3. No real money in MVP | If breach occurs: incident response plan in security/incident-response.md |
| R-004 | Accept | Monitor Vipps announcements monthly; accelerate community adoption | Emphasise 0.5% vs Vipps fees; focus on trust advantage |
| R-005 | Mitigate | 1. Door-to-door onboarding; 2. 0% fee for first 3 months; 3. 200-merchant target Month 12 | Adjust fee structure; focus on high-volume corridors |
| R-006 | Mitigate | 1. JWT_SECRET required env var — fail fast; 2. Secrets via Vaultwarden | Rotate secrets immediately; force re-auth |
| R-007 | Mitigate | 1. Remove CVV from GET response; 2. Store only last_four + token_ref; 3. Tokenisation via card partner | Suspend cards feature until fixed |
| R-010 | Mitigate | 1. Sumsub integration contract; 2. Mock clearly gated by feature flag; 3. No real money until KYC live | Suspend onboarding until KYC active |
| R-015 | Mitigate | 1. Per-user transaction lock (in-process); 2. DB-level constraint as backup; 3. PostgreSQL advisory locks in Phase 2 | Suspend concurrent transactions; queue-based processing |

---

## 7. Risk Heat Map

```mermaid
quadrantChart
    title Drop Risk Heat Map — 2026-02-23
    x-axis Low Impact --> High Impact
    y-axis Low Probability --> High Probability
    quadrant-1 "CRITICAL — Immediate Action"
    quadrant-2 "HIGH — Active Management"
    quadrant-3 "LOW — Monitor"
    quadrant-4 "MEDIUM — Watch"
    R-001 (BaaS partner): [1.0, 0.8]
    R-002 (Finanstilsynet): [1.0, 0.8]
    R-004 (Vipps): [0.8, 0.6]
    R-003 (Security): [1.0, 0.4]
    R-006 (JWT): [1.0, 0.4]
    R-007 (CVV): [1.0, 0.4]
    R-015 (Race condition): [1.0, 0.4]
    R-009 (Alem bottleneck): [0.6, 0.6]
    R-014 (Cash flow): [0.6, 0.6]
    R-008 (SQLite): [0.6, 0.4]
```

---

## 8. Escalation Thresholds

| Threshold | Action | Responsible | Timeframe |
|-----------|--------|-------------|-----------|
| Any new risk Score ≥ 15 | Escalate to Alem + John | John | Within 4 hours |
| Any existing risk score increases by ≥ 5 | Escalate to John | John | Within 24 hours |
| > 3 risks at Score ≥ 10 simultaneously | Emergency risk review | John + Alem | Within 48 hours |
| Risk triggers contingency plan | Notify all stakeholders | John | Immediately |
| Risk causes milestone slip > 3 days | Formal change request | John | Within 24 hours |

---

## 9. Review Schedule

| Frequency | Activity | Participants | Output |
|-----------|----------|-------------|--------|
| Weekly (Sprint Planning) | Review all active risks, update scores | John | Updated register |
| Sprint Retrospective | New risks identified; closed risks archived | John | New risks logged |
| Monthly | Full register review + heat map | John, Alem | Risk report |
| Milestone | Risk review before go/no-go | John, Alem | Go/no-go input |

### Review Log

| Date | Reviewer | Risks Reviewed | New Added | Closed | Key Changes |
|------|----------|---------------|-----------|--------|-------------|
| 2026-02-08 | legal + finance agents | — | 6 | 0 | Initial identification |
| 2026-02-11 | John (security audit) | 6 | 10 | 0 | Added R-006 through R-015 |
| 2026-02-23 | John | 15 | 0 | 5 | Closed R-C01 to R-C05; updated statuses |

---

## 10. Closed Risks Archive

| ID | Risk Description | Resolution Type | Resolution Notes | Date Closed |
|----|-----------------|----------------|-----------------|-------------|
| R-C01 | Wallet/balance model requires e-money licence | Avoided | Pivoted to PSD2 pass-through model (ADR-003) | 2026-02-12 |
| R-C02 | FontelePay tightly coupled to Drop — regulatory risk | Avoided | Separated to own module (ADR-002) | 2026-02-12 |
| R-C03 | Zica brand name has cultural sensitivity | Avoided | Rebranded to Drop (Alem decision 2026-02-09) | 2026-02-09 |
| R-C04 | "Banking" language in UI creates regulatory exposure | Mitigated | Removed all "banking" references from UI (task #197) | 2026-02-09 |
| R-C05 | SHA-256 password support creates rainbow table vulnerability | Mitigated | SHA-256 support removed; bcrypt-only policy enforced | 2026-02-13 |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-08 | Approved (AI) |
| Reviewer | John (AI Director) | 2026-02-23 | Reviewed |
| AI Director (John) | John | 2026-02-23 | Approved |
| Project Sponsor | Alem Bašić | TBD — requires review | |

# RACI Matrix: Drop — Fintech Payment App

# RACI Matrix: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-23 | John | Initial draft — Drop-specific roles and activities |

---

## 1. Purpose

This RACI matrix defines responsibility assignments for all Drop project activities. Drop is an AI-native internal product of ALAI Holding AS. Most "team" roles are filled by AI agents coordinated by John (AI Director). Alem Bašić (CEO) is the sole human, responsible for strategic decisions, partnerships, and regulatory submissions.

**Conflict resolution:** Disputes escalate to John (AI Director), then Alem (CEO) for strategic/financial issues.

---

## 2. RACI Definitions

| Letter | Role | Definition |
|--------|------|------------|
| **R** | **Responsible** | Does the work |
| **A** | **Accountable** | Ultimately answerable; one per activity |
| **C** | **Consulted** | Provides input; two-way communication |
| **I** | **Informed** | Kept updated; one-way communication |

---

## 3. Project Roles

| Role Code | Role Title | Person / Agent | Notes |
|-----------|-----------|---------------|-------|
| CEO | Chief Executive Officer | Alem Bašić | Strategic decisions, partnerships, budget, regulatory submissions |
| JD | AI Director | John (Claude Opus) | Delivery accountability, architecture, agent coordination |
| BUILD | Builder Agent | Claude Sonnet (per-task) | Feature implementation, API routes, frontend |
| VAL | Validator Agent | Claude Sonnet (per-task) | Testing, validation, code review (read-only) |
| SEC | Security Agent | Claude (per-sprint) | Threat modelling, security audit, compliance checks |
| LEGAL | Legal Agent | Claude (as needed) | Regulatory review, document drafting |
| FIN | Finance Agent | Claude (as needed) | Budget analysis, financial projections |
| EXT | External Advisor | TBD (human) | Legal advisor for Finanstilsynet, BaaS contracts |

---

## 4. RACI Matrix — Project Phases & Activities

### 4.1 Project Initiation & Planning

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Project Charter | I | A | | | | C | | |
| Project Brief | I | A | | | | C | C | |
| Budget approval | A | C | | | | | R | |
| Risk Register (initial) | I | A | | | C | C | C | |
| RACI Matrix | I | A | | | | | | |
| Stakeholder identification | C | A | | | | R | | |
| Communication Plan | I | A | | | | | | |

### 4.2 Requirements & Analysis

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Business Requirements Document (BRD) | C | A | | | | R | R | |
| Functional Requirements (FRS) | C | A | R | | C | | | |
| Non-Functional Requirements | C | A | R | | C | | | |
| User Stories | I | A | R | | | | | |
| Acceptance Criteria | I | A | R | C | | | | |
| Requirements Traceability Matrix | I | A | R | C | | | | |
| Regulatory requirements mapping | C | C | | | | A | | R |

### 4.3 Architecture & Design

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| System architecture (ADRs) | I | A | R | | C | | | |
| Database schema design | I | A | R | | C | | | |
| API contract design | I | A | R | | C | | | |
| Security architecture | I | C | | | A | | | |
| PSD2 pass-through model design | I | A | R | | C | | | C |
| UI/UX design (Figma) | I | A | | | | | | |
| Infrastructure design (Fly.io / Docker) | I | A | R | | | | | |

### 4.4 Development

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Backend API routes (26 endpoints) | | A | R | | C | | | |
| Frontend pages (Next.js — 10 screens) | | A | R | | | | | |
| Database schema + migrations | | A | R | | C | | | |
| Authentication (JWT + BankID mock) | | A | R | | C | | | |
| Remittance flow implementation | | A | R | | C | | | |
| QR payment flow implementation | | A | R | | C | | | |
| Merchant dashboard implementation | | A | R | | | | | |
| Feature flags implementation | | A | R | | | | | |
| CI/CD pipeline (GitHub Actions) | | A | R | | | | | |
| Docker containerisation | | A | R | | | | | |
| Code review | | A | | R | | | | |
| Unit test writing | | A | R | C | | | | |

### 4.5 Security Hardening (Phase 0.5)

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Security audit (full codebase) | I | C | | | A | | | |
| JWT secret hardening | | A | R | | C | | | |
| CVV/card data removal | | A | R | | C | | | |
| CSRF protection implementation | | A | R | | C | | | |
| Rate limiting (persistent) | | A | R | | C | | | |
| CSP headers implementation | | A | R | | C | | | |
| Session management | | A | R | | C | | | |
| Demo credential removal | | A | R | | C | | | |
| Compliance documentation (gap analysis) | I | C | | | A | R | | |
| Penetration testing (pre-launch) | I | C | | | C | | | A |

### 4.6 Testing & QA

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Test strategy | I | A | C | R | C | | | |
| Test plan | I | A | C | R | | | | |
| Unit tests (Vitest — 40 tests) | | A | R | C | | | | |
| Integration tests (20+ tests) | | A | R | C | | | | |
| E2E tests (Playwright — 3 projects) | | A | C | R | | | | |
| Performance tests (benchmarks) | | A | C | R | C | | | |
| Security tests (input chaos) | | A | C | R | A | | | |
| Regression tests | | A | R | C | | | | |
| Definition of Done validation | | A | | R | | | | |
| Go/No-Go decision | A | C | | R | C | | | |

### 4.7 Compliance & Regulatory

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| PSD2 regulatory gap analysis | C | C | | | R | A | | |
| GDPR compliance review | C | C | | | C | A | | |
| AML/KYC compliance setup | C | C | | | C | A | | R |
| Finanstilsynet PISP/AISP registration | A | C | | | | C | | R |
| Legal terms + privacy policy | C | C | | | | A | | |
| BaaS partner contract negotiation | A | C | | | | C | | R |

### 4.8 Deployment & Launch

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Deployment checklist | I | A | C | C | C | | | |
| Staging deployment (Fly.io) | I | A | R | C | | | | |
| Production deployment | I | A | R | R | C | | | |
| Monitoring + alerting setup | I | A | R | | | | | |
| App Store submission (iOS) | I | A | R | | | | | |
| Google Play submission (Android) | I | A | R | | | | | |
| Go-live communication | A | C | | | | | | |
| Merchant onboarding (200 targets) | A | I | | | | | | |
| Post-launch monitoring (48h) | I | A | | R | | | | |

### 4.9 Post-Launch & Maintenance

| Activity / Deliverable | CEO | JD | BUILD | VAL | SEC | LEGAL | FIN | EXT |
|------------------------|-----|----|----|----|----|----|----|-----|
| Post-launch review (30 days) | C | A | R | R | | | | |
| Bug fix triage + resolution | I | A | R | C | | | | |
| Performance optimisation | I | A | R | C | | | | |
| Lessons learned documentation | I | A | R | R | C | C | C | |
| Incident response | I | A | R | | C | | | |
| Monthly financial reporting | A | C | | | | | R | |
| User feedback analysis | C | A | R | | | | | |
| Project closure sign-off | A | C | | | | | | |

---

## 5. Escalation Matrix

| Escalation Level | Trigger | Escalate To | Response Time |
|-----------------|---------|-------------|--------------|
| L1 | Task-level blocker | John (JD) | 4 hours |
| L2 | Architecture/scope dispute | John (JD) | 4 hours |
| L3 | Strategic/financial decision | Alem (CEO) | 24 hours |
| L4 | Legal/regulatory blocker | Alem + External Advisor | 48 hours |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| AI Director (John) | John | 2026-02-23 | Approved |
| Project Sponsor / CEO | Alem Bašić | TBD | |

# Communication Plan: Drop — Fintech Payment App

# Communication Plan: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-23 | John | Initial draft — Drop-specific communication structure |

---

## 1. Communication Objectives

Drop is an AI-native internal product of ALAI Holding AS. Communication is primarily between John (AI Director) and Alem Bašić (CEO), with AI agents reporting asynchronously. Objectives:

1. **Transparency** — Alem always knows Drop status, blockers, and decisions at a glance
2. **Alignment** — Requirements and priorities confirmed before implementation begins
3. **Accountability** — Blockers surfaced immediately; decisions recorded in `comms/decisions/`
4. **Regulatory readiness** — All compliance-relevant decisions documented for Finanstilsynet
5. **Documentation** — Drop is AI-native; decisions persist in comms/decisions/ and HiveMind

---

## 2. Stakeholder Communication Needs

| Stakeholder | Role | Information Needs | Channel | Frequency | Detail Level |
|-------------|------|-------------------|---------|-----------|-------------|
| Alem Bašić | CEO / Sponsor | Milestone status, budget, strategic risks, partner decisions | Direct session | Weekly + ad-hoc | Executive summary |
| John | AI Director | Full project status, risks, agent output, technical decisions | Mission Control | Daily | Detailed |
| AI Builder agents | Implementers | Task specs, acceptance criteria, schema refs | Task prompt | Per-task | Technical |
| AI Validator agents | QA | Feature to validate, test criteria, DoD | Task prompt | Per-task | Technical |
| SpareBank1 / BaaS partners | External partners | Drop capabilities, partnership terms | Email via Alem | Quarterly + as needed | Executive |
| Finanstilsynet | Regulator | PISP/AISP registration documentation | Formal submission | Annual + milestones | Formal |
| Waitlist users | Early adopters | Launch updates, beta invitations | Email (hei@getdrop.no) | Monthly | Simple |
| Local merchants | Merchant users | Onboarding, QR setup, fee structure | In-person + email | On onboarding | Simple |

---

## 3. Communication Channels & Tools

| Channel | Tool | Purpose | Access |
|---------|------|---------|--------|
| AI Director ↔ CEO sessions | Direct Claude session | Strategic decisions, major blockers, reviews | Alem + John |
| Task management | Mission Control (`mc.js`) | Task status, agent coordination | John + agents |
| Decision records | `comms/decisions/` (ADRs) | Architectural and strategic decisions | All team |
| Knowledge base | BookStack (localhost:6875) | Documentation, guides, specs | All team |
| Persistent memory | HiveMind (`hivemind.js`) | Cross-session learnings, agent intel | John + agents |
| Email (external) | MCP email — john / info accounts | Partner communications, waitlist, regulatory | John + Alem |
| Partner documents | Documenso (sign.basicconsulting.no) | Contracts, NDAs, formal agreements | Alem |
| Slack | alai-talk.slack.com | Optional team-wide announcements | Alem + John |
| Incident reports | `project/docs/incident-report.md` | Production incidents | John |

---

## 4. Meeting Schedule

### 4.1 Regular Ceremonies (AI-Native Cadence)

| Meeting | Purpose | Frequency | Format | Facilitator | Output |
|---------|---------|-----------|--------|-------------|--------|
| Sprint Planning | Backlog review, task assignment to agents | Every 2 weeks | Async (John prepares) + Alem review | John | Sprint tasks in Mission Control |
| Sprint Review | Demo completed features | Every 2 weeks | Alem session — John demos | John | Sprint log entry in PIPELINE.md |
| Sprint Retrospective | Process improvement, learning opportunity | Every 2 weeks | Async by John + `/learning-opportunity` | John | Updated MEMORY.md / rules |
| Weekly Status Check | Drop status for Alem | Weekly | Written status in HiveMind + direct session if needed | John | Status report |
| Risk Review | Update risk register | Weekly | Embedded in sprint planning | John | Updated risk-register.md |
| Strategic Review | Partner decisions, regulatory updates | Monthly | Alem session | Alem | Decision record |

### 4.2 Event-Triggered Communications

| Trigger | Action | Channel | Response Time |
|---------|--------|---------|---------------|
| New critical risk (Score ≥ 15) | Escalate to Alem | Direct session | Within 4 hours |
| Security incident | Incident report + Alem notification | Direct + email | Immediately |
| BaaS partner response received | Alem briefing + decision session | Direct session | Within 24 hours |
| Milestone completed | Update PIPELINE.md + notify Alem | HiveMind post | Same day |
| Finanstilsynet correspondence | Legal review + Alem briefing | Direct + email | Within 48 hours |
| Agent task failure / blocked | John investigation + Alem if strategic | Mission Control | Within 4 hours |

---

## 5. Reporting Cadence

| Report | Frequency | Prepared By | Audience | Location |
|--------|-----------|-------------|----------|----------|
| Sprint Report | Per sprint | John | Alem | PIPELINE.md sprint log |
| Weekly Status | Weekly | John | Alem | HiveMind + direct session |
| Risk Report | Monthly | John | Alem | risk-register.md |
| Budget Report | Monthly | Finance agent | Alem | comms/reports/ |
| Milestone Report | Per milestone | John | Alem + partners | PIPELINE.md + email |
| Security Report | Per sprint | Security agent | John + Alem | security/ directory |
| Post-launch Report | 30 days post-launch | John | Alem + investors | comms/reports/ |

### 5.1 Weekly Status Template

```
SUBJECT: Drop — Weekly Status — Week of [DATE]

STATUS: ON TRACK / AT RISK / DELAYED

PHASE: [Current phase from ROADMAP.md]
STAGING: https://drop-staging.fly.dev/ — [UP/DOWN]

THIS WEEK:
- [completed item 1]
- [completed item 2]

NEXT WEEK:
- [planned item 1]
- [planned item 2]

BLOCKERS:
- [blocker] → [action needed from Alem]

TOP RISKS:
| Risk | Score | Status |
|------|-------|--------|
| [R-001] BaaS partner | 20 | [current status] |

DECISIONS NEEDED FROM ALEM:
- [ ] [decision by date]
```

---

## 6. Escalation Paths

| Level | Trigger | Escalate To | Channel | Response SLA |
|-------|---------|-------------|---------|-------------|
| L1 | Agent blocker (technical) | John (self-resolve) | Mission Control | 4 hours |
| L2 | Architecture decision required | John (makes decision) | ADR in comms/decisions/ | Same day |
| L3 | Strategic / partnership decision | Alem | Direct session | 24 hours |
| L4 | Budget change > 10% | Alem | Direct session | 24 hours |
| L5 | Legal / regulatory blocker | Alem + external legal | Email + direct | 48 hours |
| P1 | Security incident / data breach | Alem immediately | Direct + email | 15 minutes |

---

## 7. Documentation Standards

### 7.1 File Naming Convention

```
[DOCUMENT_TYPE]-[DATE]-[VERSION].[ext]
Example: drop-sprint-report-2026-02-20-v1.0.md
Example: drop-meeting-notes-2026-02-20.md
```

### 7.2 Document Storage Locations

| Document Type | Location |
|--------------|----------|
| Project governance (charter, brief, RACI, risks) | `docs/PROJECT-GOVERNANCE/` |
| Business requirements | `docs/BUSINESS-REQUIREMENTS/` |
| Decision records / ADRs | `comms/decisions/` |
| Meeting notes | `comms/meetings/` |
| Status reports | `comms/reports/` |
| Partner communications | `comms/client/` |
| Technical documentation | `docs/` (see INDEX.md) |
| Security reports | `security/` |

### 7.3 Decision Record Format (ADR)

All significant decisions must be logged in `comms/decisions/` as ADR files:

```markdown
# ADR-XXX: [Decision Title]

**Date:** YYYY-MM-DD
**Status:** Proposed | Accepted | Deprecated | Superseded
**Decider:** [Name/Agent]
**Context:** [Why this decision was needed]
**Decision:** [What was decided]
**Consequences:** [What changes as a result]
**Alternatives considered:** [What else was evaluated]
```

---

## 8. External Communication Protocols

| Communication Type | Authorized | Approval Required | Notes |
|-------------------|------------|-------------------|-------|
| BaaS partner updates | Alem | None | Document outcomes |
| Finanstilsynet submissions | Alem + Legal advisor | Alem sign-off | Formal; keep copies |
| Press / public statements about Drop | Alem only | Alem | No product details without approval |
| Merchant onboarding comms | Alem | None | Track in merchant dashboard |
| Waitlist email updates | John | Alem approval for major announcements | Via MCP email — info account |
| Investor communications | Alem | Alem | John prepares materials |

---

## 9. Crisis Communication Plan

### 9.1 Crisis Triggers

- Production security breach or data exposure
- Payment processing failure affecting users
- Regulatory action or investigation by Finanstilsynet
- BaaS partner contract failure
- > 4-week unplanned delay to any Phase 2+ milestone

### 9.2 Crisis Protocol

1. **Identify** — John identifies crisis; logs in `project/docs/incident-report.md`
2. **Contain** — John assesses scope and implements immediate mitigations (within 1 hour)
3. **Escalate** — John notifies Alem via direct session within 1 hour of identification
4. **Communicate** — John drafts external communication; Alem approves before sending
5. **Update** — Alem and affected parties receive updates every 4 hours until resolved
6. **Resolve** — Crisis closed when all impacts mitigated and systems restored
7. **Learn** — `/learning-opportunity` skill run; memory updated; process improved

### 9.3 Crisis Communication Template

```
SUBJECT: [DROP — URGENT] [Crisis Summary]

Vi vil informere deg om en situasjon som påvirker Drop.

SITUASJON: [What happened]
PÅVIRKNING: [What is affected]
UMIDDELBARE TILTAK: [What we have done]
NESTE STEG: [What we will do]
FORVENTET LØSNING: [Timeline]

Neste oppdatering: [Next update time]

Kontakt: Alem Bašić — alem@alai.no — +47 40 47 42 51
```

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| AI Director (John) | John | 2026-02-23 | Approved |
| CEO / Project Sponsor | Alem Bašić | TBD | |

# Project Charter

# Project Charter: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Vision & Mission

<!-- GUIDANCE: Write a compelling 2-3 sentence vision describing the end state this project creates.
The mission statement explains HOW the project achieves that vision. Be specific to this project. -->

**Vision:** {{VISION_STATEMENT}}
> _What does success look like 12 months after launch? What has changed for the business or users?_

**Mission:** {{MISSION_STATEMENT}}
> _How does this project deliver the vision? What approach, principles, or methods define delivery?_

**Strategic Alignment:**
> _How does this project align with ALAI's or the client's broader business strategy? Reference the relevant OKR or business goal._

---

## 2. Scope

<!-- GUIDANCE: Be precise. Scope misunderstandings are the #1 source of project disputes.
In-scope items are contracted deliverables. Out-of-scope protects both parties. -->

### 2.1 In Scope — Deliverables

| # | Deliverable | Description | Acceptance Criteria Summary |
|---|-------------|-------------|-----------------------------|
| D-01 | {{DELIVERABLE}} | {{DESCRIPTION}} | {{ACCEPTANCE_CRITERIA}} |
| D-02 | | | |
| D-03 | | | |
| D-04 | | | |
| D-05 | | | |

### 2.2 Out of Scope

<!-- GUIDANCE: List explicitly what is NOT included. This prevents scope creep. Common exclusions:
data migration from legacy systems, ongoing hosting/maintenance post-launch, third-party licensing,
content creation, translations, training delivery, future feature phases. -->

- {{OUT_OF_SCOPE_ITEM_1}}
- {{OUT_OF_SCOPE_ITEM_2}}
- {{OUT_OF_SCOPE_ITEM_3}}

### 2.3 Assumptions

<!-- GUIDANCE: List conditions assumed to be true for this project to succeed as scoped.
If an assumption proves false, it may trigger a change request. -->

| # | Assumption | Risk if False | Owner to Validate |
|---|------------|---------------|-------------------|
| A-01 | {{ASSUMPTION}} | {{RISK}} | {{OWNER}} |
| A-02 | | | |

### 2.4 Constraints

<!-- GUIDANCE: Non-negotiable limitations. Technology choices, regulatory requirements,
fixed deadlines, budget ceilings, team size, platform mandates. -->

| # | Constraint | Category | Impact |
|---|------------|----------|--------|
| C-01 | {{CONSTRAINT}} | Technical / Legal / Budget / Time | {{IMPACT}} |
| C-02 | | | |

---

## 3. Stakeholder Register

<!-- GUIDANCE: Every person/organization with an interest in project outcomes.
Interest = what they care about. Influence = their power to affect the project.
Engagement Strategy = how you keep them informed and supportive. -->

| ID | Name | Organization | Role | Interest | Influence | Engagement Strategy | Contact |
|----|------|--------------|------|----------|-----------|---------------------|---------|
| S-01 | {{NAME}} | {{ORG}} | Sponsor | {{INTEREST}} | High | Steering committee monthly | {{EMAIL}} |
| S-02 | | | Product Owner | | High | Sprint reviews, daily | |
| S-03 | | | End User Rep | | Medium | UAT sessions | |
| S-04 | | | Technical Lead | | High | Daily standup | |
| S-05 | | | Finance/Legal | | Medium | Monthly reports | |

**Key Decision Makers:**
- Final scope decisions: {{DECISION_MAKER}}
- Technical architecture approval: {{TECH_APPROVER}}
- Budget approval: {{BUDGET_APPROVER}}
- Contract/legal: {{LEGAL_APPROVER}}

---

## 4. Budget Summary

<!-- GUIDANCE: Provide total budget with breakdown. Include contingency reserve (typically 10-20%).
Payment milestones should align with delivery milestones, not calendar dates. -->

| Line Item | Amount (NOK) | % of Total | Notes |
|-----------|-------------|------------|-------|
| Development | {{AMOUNT}} | | |
| Design | {{AMOUNT}} | | |
| Infrastructure / Hosting | {{AMOUNT}} | | |
| Third-party licenses / APIs | {{AMOUNT}} | | |
| Testing / QA | {{AMOUNT}} | | |
| Project Management | {{AMOUNT}} | | |
| **Subtotal** | **{{SUBTOTAL}}** | **100%** | |
| Contingency Reserve (15%) | {{CONTINGENCY}} | | For approved change requests |
| **Total Budget** | **{{TOTAL}}** | | |

**Payment Schedule:**

| Milestone | % | Amount (NOK) | Due Date |
|-----------|---|-------------|----------|
| Contract signing | 50% | {{AMOUNT}} | {{DATE}} |
| MVP delivery | 25% | {{AMOUNT}} | {{DATE}} |
| Final delivery + UAT sign-off | 25% | {{AMOUNT}} | {{DATE}} |

---

## 5. Timeline & Milestones

<!-- GUIDANCE: List major milestones with gate criteria. A milestone is not complete until
its gate condition is verified. Use the Gantt diagram placeholder below for visual representation. -->

| # | Milestone | Target Date | Gate Condition | Owner |
|---|-----------|-------------|----------------|-------|
| M-01 | Project Kick-off | {{DATE}} | Charter approved, team onboarded | PM |
| M-02 | Requirements Complete | {{DATE}} | BRD/FRS approved by PO + client | BA |
| M-03 | Design Approved | {{DATE}} | All mockups signed off | Designer |
| M-04 | MVP / Alpha Release | {{DATE}} | Core features functional, deployed to staging | Tech Lead |
| M-05 | Beta Release | {{DATE}} | All features complete, regression tests pass | QA |
| M-06 | UAT Complete | {{DATE}} | UAT sign-off document signed | PM |
| M-07 | Production Launch | {{DATE}} | Go-live checklist passed, monitoring active | DevOps |
| M-08 | Post-launch Handover | {{DATE}} | Documentation delivered, support transition done | PM |

**Gantt Diagram (placeholder):**

```mermaid
gantt
    title {{PROJECT_NAME}} — Project Timeline
    dateFormat  YYYY-MM-DD
    section Planning
    Project Kick-off        :done, m1, {{START_DATE}}, 3d
    Requirements Gathering  :active, req, after m1, 14d
    section Design
    UI/UX Design            :des, after req, 14d
    Design Review           :milestone, after des, 1d
    section Development
    Sprint 1                :s1, after des, 14d
    Sprint 2                :s2, after s1, 14d
    Sprint 3                :s3, after s2, 14d
    section Testing & Launch
    UAT                     :uat, after s3, 7d
    Production Launch       :milestone, after uat, 1d
```

---

## 6. Success Criteria & KPIs

<!-- GUIDANCE: Success criteria must be measurable and verifiable. For each criterion,
specify HOW it will be measured and WHEN it will be evaluated. Avoid vague statements. -->

| # | Success Criterion | KPI / Metric | Target | Measurement Method | Evaluation Point |
|---|-------------------|-------------|--------|--------------------|------------------|
| SC-01 | {{CRITERION}} | {{KPI}} | {{TARGET}} | {{METHOD}} | {{WHEN}} |
| SC-02 | System performance | Page load time | < 2 seconds (p95) | Lighthouse / monitoring | Launch + 30 days |
| SC-03 | User adoption | Active users | {{TARGET}} in 90 days | Analytics dashboard | 90 days post-launch |
| SC-04 | Quality | Bug rate | < 5 critical bugs post-launch | Issue tracker | 30 days post-launch |
| SC-05 | Client satisfaction | NPS score | ≥ 8/10 | Post-launch survey | 60 days post-launch |

---

## 7. Dependencies

<!-- GUIDANCE: External dependencies that could block or delay the project.
Each dependency should have an owner responsible for resolving it and a target resolution date. -->

| # | Dependency | Type | Impact if Delayed | Owner | Target Date | Status |
|---|-----------|------|-------------------|-------|-------------|--------|
| DEP-01 | {{DEPENDENCY}} | Internal / External / Client | {{IMPACT}} | {{OWNER}} | {{DATE}} | Pending |
| DEP-02 | | | | | | |

---

## 8. Governance Model

<!-- GUIDANCE: Define who makes what decisions and how disagreements are resolved.
Clear governance prevents escalation spirals and delays. -->

### 8.1 Decision-Making Authority

| Decision Category | Authority | Must Consult | Must Inform |
|-------------------|-----------|--------------|-------------|
| Scope changes | PO + John | Tech Lead, PM | Client, Alem |
| Architecture decisions | Tech Lead | Developer team | PM, John |
| Budget changes > 10% | Alem | John, PM | Client |
| Release go/no-go | Tech Lead + PM | QA, DevOps | John, Client |
| Team changes | John | PM | Alem |
| Contract amendments | Alem | John | Client |

### 8.2 Change Control Process Summary

<!-- GUIDANCE: Define the process for handling scope changes during the project. -->

1. **Request:** Any stakeholder submits a Change Request (CR) using the `change-request.md` template
2. **Impact Analysis:** PM + Tech Lead assess scope, timeline, budget, and risk impact within 3 business days
3. **Decision:** PO + John approve/reject within 2 business days of impact analysis
4. **Budget changes > 10%:** Require Alem approval
5. **Implementation:** Approved CRs are logged, prioritized in backlog, and scheduled
6. **Communication:** All stakeholders notified of approved/rejected CRs within 24 hours

### 8.3 Escalation Hierarchy

```
L1: Team Member → Tech Lead (response: 4 hours)
L2: Tech Lead → PM (response: 8 hours)
L3: PM → John (response: 4 hours)
L4: John → Alem (response: 24 hours — strategic/financial only)
```

---

## 9. Team & Roles

<!-- GUIDANCE: Assign specific named individuals or agent IDs to each role.
Refer to the separate RACI matrix for detailed responsibility assignments. -->

| Role | Agent / Person | Responsibilities | Availability |
|------|---------------|-----------------|--------------|
| Project Sponsor | {{NAME}} | Strategic direction, final approvals, budget | As needed |
| AI Director | John | Delivery accountability, agent coordination | Full-time |
| Project Manager | {{AGENT}} | Coordination, reporting, risk, stakeholder comms | Full-time |
| Business Analyst | {{AGENT}} | Requirements, acceptance criteria, documentation | Full-time |
| Tech Lead | {{AGENT}} | Architecture, code review, technical decisions | Full-time |
| Developer(s) | {{AGENT}} | Feature implementation | Full-time |
| Designer | {{AGENT}} | UI/UX, design system, assets | Part-time |
| QA Engineer | {{AGENT}} | Test planning, execution, sign-off | Full-time |
| DevOps | {{AGENT}} | Infrastructure, CI/CD, deployment | Part-time |

---

## 10. Risk Summary

<!-- GUIDANCE: High-level risk overview. Full risk register maintained in risk-register.md.
Only list top 5 risks here with their mitigation summary. -->

| # | Risk | Probability | Impact | Mitigation |
|---|------|------------|--------|------------|
| R-01 | {{RISK}} | H/M/L | H/M/L | {{MITIGATION}} |
| R-02 | | | | |
| R-03 | | | | |
| R-04 | | | | |
| R-05 | | | | |

> Full risk register: `[risk-register.md](risk-register.md)`

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| AI Director (John) | | | |
| Project Sponsor | | | |
| CEO (Alem) | | | |
| Client Representative | | | |

# Project Brief

# Project Brief: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

<!-- GUIDANCE: This document is an executive summary designed to secure stakeholder buy-in and
budget approval BEFORE a full project charter is written. Keep it concise (4-8 pages max)
but substantive. Decision-makers need enough detail to say "go" or "no-go". -->

## 1. Executive Summary

<!-- GUIDANCE: One paragraph (max 150 words) that answers: What is the problem? What is the solution?
Why now? What does success look like? Who delivers it? What does it cost?
Write this LAST, after completing all other sections. -->

> {{EXECUTIVE_SUMMARY_PARAGRAPH}}

---

## 2. Business Context & Market Opportunity

<!-- GUIDANCE: Describe the business environment, market dynamics, and strategic context.
Why is this the right moment for this project? What market forces (competition, regulation,
technology shift, customer demand) make this urgent? Include data where possible. -->

### 2.1 Business Context

{{BUSINESS_CONTEXT}}

### 2.2 Market Opportunity

| Dimension | Current State | Opportunity |
|-----------|--------------|-------------|
| Market Size | {{CURRENT}} | {{OPPORTUNITY}} |
| Target Segment | {{SEGMENT}} | {{SEGMENT_SIZE}} |
| Growth Rate | {{GROWTH}} | {{PROJECTED}} |
| Key Trend | {{TREND}} | {{IMPLICATION}} |

### 2.3 Strategic Fit

<!-- GUIDANCE: Explain how this project connects to the organization's strategic goals.
Reference specific OKRs, annual priorities, or board-level initiatives if applicable. -->

This project directly supports:
- **Strategic Goal:** {{STRATEGIC_GOAL}}
- **OKR / Initiative:** {{OKR_REFERENCE}}
- **Alignment with ALAI mission:** {{ALIGNMENT_EXPLANATION}}

---

## 3. Problem Statement

<!-- GUIDANCE: Define the problem with precision. A good problem statement is specific, measurable,
and separates symptoms from root causes. Include quantitative data where possible.
Avoid jumping to solutions here — that comes in section 4. -->

### 3.1 Core Problem

{{PROBLEM_STATEMENT}}

### 3.2 Pain Points

<!-- GUIDANCE: List the specific pain points experienced by affected stakeholders.
Each pain point should connect to a measurable impact (time lost, revenue lost, risk created). -->

| # | Pain Point | Affected Stakeholder | Measurable Impact |
|---|-----------|---------------------|-------------------|
| P-01 | {{PAIN_POINT}} | {{STAKEHOLDER}} | {{IMPACT}} |
| P-02 | | | |
| P-03 | | | |

### 3.3 Current State Gaps

<!-- GUIDANCE: Describe what exists today and where it falls short. What workarounds do people use?
What manual processes exist? What risks does the current state create? -->

**Current Process/System:** {{CURRENT_STATE_DESCRIPTION}}

**Key Gaps:**
- {{GAP_1}}
- {{GAP_2}}
- {{GAP_3}}

**Cost of Inaction:** {{COST_OF_NOT_ACTING}} _(e.g., $X/year in manual labor, X% churn risk, regulatory penalty)_

---

## 4. Proposed Solution Overview

<!-- GUIDANCE: Describe the solution at a high level — what will be built, for whom, and how it
solves the stated problem. Avoid technical implementation details here.
Focus on capabilities and outcomes, not architecture. -->

### 4.1 Solution Description

{{SOLUTION_DESCRIPTION}}

### 4.2 Key Capabilities

| # | Capability | Addresses Pain Point | Priority |
|---|-----------|---------------------|----------|
| CAP-01 | {{CAPABILITY}} | P-{{XX}} | Must Have |
| CAP-02 | | | Must Have |
| CAP-03 | | | Should Have |
| CAP-04 | | | Could Have |

### 4.3 Solution Architecture (High Level)

<!-- GUIDANCE: Replace with a simple diagram showing major components.
Don't need full technical depth — just enough for decision-makers to understand the solution shape. -->

```mermaid
graph LR
    A[{{USER_TYPE}}] --> B[{{FRONTEND}}]
    B --> C[{{BACKEND_API}}]
    C --> D[{{DATABASE}}]
    C --> E[{{EXTERNAL_SERVICE}}]
```

### 4.4 Platforms & Channels

- [ ] Web Application
- [ ] iOS Mobile App
- [ ] Android Mobile App
- [ ] API / Backend Service
- [ ] Admin Dashboard
- [ ] Other: {{SPECIFY}}

---

## 5. Key Benefits & ROI Projection

<!-- GUIDANCE: Quantify benefits wherever possible. Decision-makers need to justify the investment.
ROI projection should be conservative — better to under-promise and over-deliver. -->

### 5.1 Quantified Benefits

| Benefit Category | Description | Estimated Annual Value |
|-----------------|-------------|------------------------|
| Revenue increase | {{DESCRIPTION}} | {{NOK_AMOUNT}} |
| Cost reduction | {{DESCRIPTION}} | {{NOK_AMOUNT}} |
| Risk reduction | {{DESCRIPTION}} | {{NOK_AMOUNT}} |
| Productivity gain | {{DESCRIPTION}} | {{NOK_AMOUNT}} |
| **Total Annual Benefit** | | **{{TOTAL}}** |

### 5.2 ROI Calculation

| Metric | Value |
|--------|-------|
| Total Investment (Year 1) | {{INVESTMENT}} NOK |
| Total Annual Benefit | {{ANNUAL_BENEFIT}} NOK |
| Payback Period | {{PAYBACK_MONTHS}} months |
| 3-Year ROI | {{ROI_PERCENTAGE}}% |
| Net Present Value (3yr) | {{NPV}} NOK |

> _Assumptions: {{ROI_ASSUMPTIONS}}_

### 5.3 Qualitative Benefits

<!-- GUIDANCE: Benefits that are real but hard to quantify — brand, morale, compliance, risk posture. -->

- **Brand/Reputation:** {{BRAND_BENEFIT}}
- **Competitive Advantage:** {{COMPETITIVE_BENEFIT}}
- **Risk Reduction:** {{RISK_BENEFIT}}
- **Employee/User Experience:** {{UX_BENEFIT}}

---

## 6. High-Level Requirements

<!-- GUIDANCE: List the most critical functional and non-functional requirements at a business level.
This is NOT a detailed requirements document — that comes in the BRD/FRS phase.
Focus on the requirements that most influence scope, cost, and timeline. -->

| # | Requirement | Type | Priority | Notes |
|---|------------|------|----------|-------|
| HLR-01 | {{REQUIREMENT}} | Functional | Must Have | |
| HLR-02 | | Functional | Must Have | |
| HLR-03 | | Non-Functional | Must Have | {{E.G., GDPR compliance}} |
| HLR-04 | | Functional | Should Have | |
| HLR-05 | | Functional | Could Have | |

---

## 7. Competitive Landscape

<!-- GUIDANCE: Understand what alternatives exist — both direct competitors and substitute solutions.
Why is this proposed solution better or more appropriate than the alternatives? -->

| Alternative | Type | Strengths | Weaknesses | Why We Win |
|------------|------|-----------|------------|------------|
| {{COMPETITOR_1}} | Direct competitor | {{STRENGTHS}} | {{WEAKNESSES}} | {{DIFFERENTIATION}} |
| {{COMPETITOR_2}} | Indirect/substitute | | | |
| {{COMPETITOR_3}} | Build in-house alt | | | |

**Our Unique Value Proposition:** {{VALUE_PROPOSITION}}

---

## 8. Resource Requirements

<!-- GUIDANCE: Summarize the resources needed. High-level only — detailed staffing plan in the charter.
This section helps decision-makers understand the ask before approving full planning. -->

### 8.1 Team

| Role | Effort | Source |
|------|--------|--------|
| Project Manager | {{ESTIMATE}} | ALAI internal |
| Tech Lead | {{ESTIMATE}} | ALAI internal |
| Developer(s) | {{ESTIMATE}} | ALAI internal |
| Designer | {{ESTIMATE}} | ALAI internal / contract |
| QA | {{ESTIMATE}} | ALAI internal |

### 8.2 Budget Summary

| Category | Estimated Cost (NOK) |
|----------|---------------------|
| Development | {{AMOUNT}} |
| Design | {{AMOUNT}} |
| Infrastructure | {{AMOUNT}} |
| Licenses | {{AMOUNT}} |
| Contingency (15%) | {{AMOUNT}} |
| **Total** | **{{TOTAL}}** |

### 8.3 Timeline

| Phase | Duration | Start |
|-------|----------|-------|
| Planning & Requirements | {{DURATION}} | {{DATE}} |
| Design | {{DURATION}} | {{DATE}} |
| Development | {{DURATION}} | {{DATE}} |
| Testing & UAT | {{DURATION}} | {{DATE}} |
| Launch | {{DURATION}} | {{DATE}} |
| **Total Duration** | **{{TOTAL_DURATION}}** | **{{START_DATE}}** |

---

## 9. Go / No-Go Decision Criteria

<!-- GUIDANCE: Define the conditions under which this project should proceed vs. be stopped or redesigned.
These criteria protect stakeholders from committing to a project that shouldn't proceed. -->

### 9.1 Go Criteria (ALL must be met)

- [ ] Budget approved: {{BUDGET_THRESHOLD}}
- [ ] Key stakeholders aligned on scope and timeline
- [ ] {{CRITICAL_DEPENDENCY}} confirmed available
- [ ] Legal/compliance review completed
- [ ] {{ADDITIONAL_GO_CRITERION}}

### 9.2 No-Go Triggers (ANY is sufficient to stop)

- [ ] Budget approval exceeds {{THRESHOLD}}% above estimate
- [ ] Critical dependency {{DEPENDENCY}} unavailable within {{TIMEFRAME}}
- [ ] Regulatory/legal blocker identified
- [ ] {{ADDITIONAL_NO_GO_TRIGGER}}

### 9.3 Decision

| Dimension | Decision | Decision Maker | Date |
|-----------|---------|---------------|------|
| Proceed with planning | Go / No-Go / Hold | {{DECISION_MAKER}} | |
| Budget approved | Yes / No / Conditional | {{BUDGET_APPROVER}} | |
| Resource allocation approved | Yes / No | {{RESOURCE_APPROVER}} | |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| AI Director (John) | | | |
| Project Sponsor | | | |
| CEO (Alem) | | | |

# Risk Register

# Risk Register: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Risk Identification Methodology

<!-- GUIDANCE: Describe how risks were identified for this project. Common techniques include:
brainstorming sessions, expert interviews, lessons-learned reviews, checklists, and assumption analysis.
Document who participated and when the initial risk identification was conducted. -->

**Identification Methods Used:**
- [ ] Team brainstorming session (Date: {{DATE}}, Participants: {{PARTICIPANTS}})
- [ ] Lessons learned review from previous projects
- [ ] Risk category checklist (see Section 2)
- [ ] Stakeholder interviews
- [ ] Assumption analysis (see project charter)
- [ ] Technical spike / proof-of-concept findings

**Initial Risk Assessment Date:** {{DATE}}
**Next Scheduled Review:** {{DATE}}
**Risk Owner:** {{RISK_OWNER}} (typically the Project Manager)

---

## 2. Risk Categories

<!-- GUIDANCE: Use these categories consistently across all risk entries to enable
trend analysis and risk reporting by category. -->

| Category | Description | Common Examples |
|----------|-------------|----------------|
| **Technical** | Technology failures, integration issues, performance, security | API changes, infrastructure limits, unknown complexity |
| **Resource** | Team availability, skill gaps, capacity constraints | Key person sick leave, agent performance degradation |
| **Client** | Client-side decisions, availability, requirement volatility | Delayed approvals, changing priorities, unclear requirements |
| **External** | Third-party dependencies, regulatory changes, market shifts | API deprecation, GDPR change, competitor launch |
| **Financial** | Budget overruns, payment delays, cost estimates | Underestimated effort, currency exposure, vendor price change |
| **Timeline** | Schedule risks, deadline pressure, estimation errors | Milestone slip, hard deadline, dependency delays |
| **Quality** | Defect rate, technical debt, process failures | Insufficient testing, rushed delivery, poor documentation |
| **Organizational** | Internal politics, process changes, leadership decisions | Reprioritization, team restructure, tool changes |

---

## 3. Risk Probability & Impact Scale

<!-- GUIDANCE: Use this 5-point scale consistently for all risk scoring.
Risk Score = Probability × Impact. Score determines required response level. -->

### 3.1 Probability Scale

| Level | Score | Definition | Example |
|-------|-------|------------|---------|
| Very Low | 1 | < 10% chance — rare, theoretical | Unknown-unknown |
| Low | 2 | 10–30% chance — unlikely but possible | Historical precedent rare |
| Medium | 3 | 30–50% chance — may occur | Has happened on similar projects |
| High | 4 | 50–70% chance — likely to occur | Happens regularly |
| Very High | 5 | > 70% chance — almost certain | Happened before on this type |

### 3.2 Impact Scale

| Level | Score | Schedule Impact | Budget Impact | Quality Impact |
|-------|-------|----------------|---------------|----------------|
| Negligible | 1 | < 1 day | < 1% | Minor fix needed |
| Minor | 2 | 1–3 days | 1–5% | Some rework needed |
| Moderate | 3 | 3–7 days | 5–10% | Significant rework |
| Major | 4 | 1–2 weeks | 10–20% | Deliverable at risk |
| Critical | 5 | > 2 weeks | > 20% | Project failure risk |

### 3.3 Risk Matrix (Probability × Impact)

<!-- GUIDANCE: Use this matrix to determine the risk level and required response speed. -->

```
         IMPACT →
         1(Neg) 2(Min) 3(Mod) 4(Maj) 5(Crit)
P  5(VH) |  5  |  10  |  15  |  20  |  25  |  ← CRITICAL ZONE (≥15)
R  4(H)  |  4  |   8  |  12  |  16  |  20  |
O  3(M)  |  3  |   6  |   9  |  12  |  15  |
B  2(L)  |  2  |   4  |   6  |   8  |  10  |  ← MEDIUM ZONE (5-14)
↑  1(VL) |  1  |   2  |   3  |   4  |   5  |  ← LOW ZONE (≤4)
```

| Score | Risk Level | Response Required | Escalation |
|-------|-----------|-------------------|------------|
| 1–4   | LOW | Monitor; review monthly | PM awareness |
| 5–9   | MEDIUM | Active mitigation plan required | PM + Tech Lead |
| 10–14 | HIGH | Immediate action + weekly review | PM + John |
| 15–25 | CRITICAL | Emergency response; may stop project | John + Alem |

---

## 4. Risk Appetite Statement

<!-- GUIDANCE: Document the organization's/project's tolerance for risk.
This guides decisions about which risks to accept vs. actively mitigate. -->

**Overall Risk Appetite:** {{LOW | MEDIUM | HIGH}}

| Risk Category | Appetite | Rationale |
|--------------|----------|-----------|
| Technical | Medium | Innovation requires technical experimentation |
| Financial | Low | Budget is fixed; overruns require CEO approval |
| Quality | Low | Client satisfaction is core to ALAI brand |
| Timeline | Medium | Some schedule flexibility acceptable if quality maintained |
| Security | Very Low | Zero tolerance for data breaches or compliance violations |
| Regulatory | Very Low | Legal exposure is unacceptable |

**Maximum Acceptable Risk Exposure:** Score ≤ 9 without escalation to John.
**Escalation Threshold:** Any risk scoring ≥ 10 must be reported to John within 24 hours.

---

## 5. Active Risk Register

<!-- GUIDANCE: Maintain this table throughout the project lifecycle. Update weekly during sprint planning.
Risk Score = Probability Score × Impact Score. Trigger Indicators = early warning signs to watch for.
Response Strategy: Avoid / Mitigate / Transfer / Accept (see Section 6). -->

| ID | Risk Description | Category | Prob (1-5) | Impact (1-5) | Score | Response Strategy | Owner | Trigger Indicators | Status | Date Identified | Review Date |
|----|-----------------|----------|------------|-------------|-------|-------------------|-------|-------------------|--------|-----------------|-------------|
| R-001 | {{RISK_DESCRIPTION}} | Technical | {{1-5}} | {{1-5}} | {{SCORE}} | Mitigate | {{OWNER}} | {{TRIGGER}} | Open | {{DATE}} | {{DATE}} |
| R-002 | Key client contact unavailable for approvals | Client | 3 | 4 | 12 | Mitigate | PM | Slow email responses; missed meetings | Open | {{DATE}} | {{DATE}} |
| R-003 | Third-party API deprecates required endpoint | External | 2 | 5 | 10 | Mitigate | Tech Lead | Vendor changelog; API versioning notice | Open | {{DATE}} | {{DATE}} |
| R-004 | Scope creep from undiscovered requirements | Client | 4 | 3 | 12 | Mitigate | BA/PM | Frequent "small" change requests | Open | {{DATE}} | {{DATE}} |
| R-005 | Performance targets not met under load | Technical | 3 | 4 | 12 | Mitigate | Tech Lead | Slow response in dev testing | Open | {{DATE}} | {{DATE}} |
| R-006 | {{RISK_DESCRIPTION}} | | | | | | | | Open | {{DATE}} | {{DATE}} |
| R-007 | | | | | | | | | Open | | |
| R-008 | | | | | | | | | Open | | |

---

## 6. Risk Response Strategies

<!-- GUIDANCE: Each active risk must have a documented response strategy with specific actions.
Add new rows for each risk requiring a detailed response plan. -->

| Risk ID | Strategy | Response Actions | Contingency Plan | Resources Required |
|---------|----------|-----------------|------------------|-------------------|
| R-001 | {{STRATEGY}} | 1. {{ACTION_1}}; 2. {{ACTION_2}} | {{CONTINGENCY_IF_RISK_OCCURS}} | {{RESOURCES}} |
| R-002 | Mitigate | 1. Identify backup decision-maker; 2. Set approval deadlines in contract; 3. Async approval process | Escalate to John → client sponsor | PM time: 2h/week |
| R-003 | Mitigate + Accept | 1. Abstract API calls behind service layer; 2. Monitor vendor changelog; 3. Build integration tests | Switch to alternative vendor; allocate 3-day buffer | Tech Lead: 1 day setup |
| R-004 | Avoid + Mitigate | 1. Detailed BRD sign-off before development; 2. Formal change request process enforced; 3. Weekly scope review | Raise change request; negotiate timeline/budget | BA: 2h/week scope monitoring |

### Response Strategy Definitions

| Strategy | When to Use | Action |
|----------|------------|--------|
| **Avoid** | High score + feasible to eliminate | Change plan to remove the risk source |
| **Mitigate** | Cannot avoid; must reduce probability or impact | Implement controls, monitoring, early warning systems |
| **Transfer** | Risk can be shared with third party | Insurance, contractual liability transfer, outsourcing |
| **Accept (Active)** | Low score; mitigation cost > risk cost | Monitor and create contingency plan |
| **Accept (Passive)** | Negligible score | Acknowledge, no action required |
| **Escalate** | Exceeds project authority or appetite | Raise to John / Alem / client sponsor |

---

## 7. Risk Heat Map

<!-- GUIDANCE: Update this heat map monthly. Plot each active risk by its current probability/impact scores.
Replace risk IDs in the appropriate cells below. -->

```mermaid
quadrantChart
    title Risk Heat Map — {{PROJECT_NAME}}
    x-axis Low Impact --> High Impact
    y-axis Low Probability --> High Probability
    quadrant-1 "CRITICAL — Immediate Action"
    quadrant-2 "HIGH — Active Management"
    quadrant-3 "LOW — Monitor"
    quadrant-4 "MEDIUM — Watch"
    R-001: [0.7, 0.5]
    R-002: [0.6, 0.5]
    R-003: [0.8, 0.3]
    R-004: [0.5, 0.7]
    R-005: [0.7, 0.5]
```

> _Update coordinates as Probability/Impact scores change. X = Impact/5, Y = Probability/5._

---

## 8. Escalation Thresholds

<!-- GUIDANCE: Define explicit triggers for escalation. Removes ambiguity and ensures timely response. -->

| Threshold | Action | Responsible | Timeframe |
|-----------|--------|-------------|-----------|
| Any new risk Score ≥ 15 | Immediate escalation to John + Alem | PM | Within 4 hours of identification |
| Any existing risk score increases by ≥ 5 | Escalate to John | PM | Within 24 hours |
| > 3 risks at Score ≥ 10 simultaneously | Emergency risk review meeting | PM + John | Within 48 hours |
| Any risk triggers its contingency plan | Notify all stakeholders | PM | Immediately |
| Risk causes milestone slip > 3 days | Formal change request + escalation | PM | Within 24 hours |

---

## 9. Risk Review Schedule

<!-- GUIDANCE: Consistent review cadence is essential. Log each review in the Review Log table. -->

| Frequency | Activity | Participants | Output |
|-----------|----------|-------------|--------|
| Weekly (Sprint Planning) | Review all active risks, update scores/status | PM, Tech Lead | Updated register |
| Sprint Retrospective | Identify new risks; close resolved risks | Full team | New risks added |
| Monthly | Full risk register review + heat map update | PM, John | Risk report to stakeholders |
| Ad-hoc | New risk identified (any time) | Risk identifier + PM | New risk logged within 24h |
| Milestone | Risk review before each major milestone | PM, Tech Lead, John | Go/no-go input |

### Review Log

| Date | Reviewer | Risks Reviewed | New Risks Added | Risks Closed | Key Changes |
|------|----------|---------------|-----------------|--------------|-------------|
| {{DATE}} | {{NAME}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{SUMMARY}} |

---

## 10. Closed / Accepted Risks Archive

<!-- GUIDANCE: Never delete closed risks — they form the project's risk history and lessons learned.
Resolution types: Mitigated (controls worked), Occurred (risk happened), Avoided (risk eliminated),
Accepted (risk window passed), Transferred (handed to third party). -->

| ID | Risk Description | Resolution Type | Resolution Notes | Date Closed |
|----|-----------------|----------------|-----------------|-------------|
| R-999 | Example: Third-party payment provider delays | Mitigated | Switched to backup provider; no impact | {{DATE}} |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Project Manager | | | |
| AI Director (John) | | | |
| Project Sponsor | | | |

# RACI Matrix

# RACI Matrix: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Purpose & How to Use This Matrix

<!-- GUIDANCE: The RACI matrix prevents gaps and overlaps in accountability. Every deliverable
and key activity must have exactly ONE Accountable (A) and at least one Responsible (R).
Having no A creates ambiguity. Having multiple A's creates conflict. -->

This RACI matrix defines responsibility assignments for all activities and deliverables in the **{{PROJECT_NAME}}** project. It serves as the authoritative reference for:
- Who does the work (Responsible)
- Who is ultimately answerable for the outcome (Accountable)
- Who provides input and expertise (Consulted)
- Who needs to be kept informed (Informed)

**Conflict resolution:** When disagreements arise about ownership, refer to this document. Disputes escalate to the Accountable party, then to John (AI Director) if unresolved.

---

## 2. RACI Definitions

| Letter | Role | Definition | Rule |
|--------|------|------------|------|
| **R** | **Responsible** | The person(s) who do the work to complete the activity | Can be multiple per activity |
| **A** | **Accountable** | The one person who is ultimately answerable; signs off on completion | MUST be exactly ONE per activity |
| **C** | **Consulted** | Provides expertise/input; two-way communication required | Optional; should be minimized |
| **I** | **Informed** | Kept up to date on decisions/progress; one-way communication | Should be only those who need to know |

**Common Mistakes to Avoid:**
- Multiple A's on one activity — pick one, make others C or I
- No R — every activity must have someone doing the work
- Too many C's — consult only who truly adds value; too many slows work down
- Missing I's — key stakeholders left uninformed create escalations

---

## 3. Project Roles

<!-- GUIDANCE: List every role involved in this project. Map to named individuals or agent IDs.
Update this table when team members change. -->

| Role Code | Role Title | Person / Agent | Org | Notes |
|-----------|-----------|---------------|-----|-------|
| CEO | Chief Executive Officer | Alem | ALAI | Strategic decisions, final budget approval |
| JD | AI Director | John | ALAI | Delivery accountability, agent coordination |
| PM | Project Manager | {{NAME/AGENT}} | ALAI | Day-to-day coordination, reporting |
| PO | Product Owner | {{NAME/AGENT}} | ALAI / Client | Backlog, requirements prioritization |
| BA | Business Analyst | {{NAME/AGENT}} | ALAI | Requirements elicitation, documentation |
| TL | Tech Lead | {{NAME/AGENT}} | ALAI | Architecture, code review, technical decisions |
| DEV | Developer(s) | {{NAME/AGENT}} | ALAI | Feature implementation |
| DES | Designer | {{NAME/AGENT}} | ALAI / Contract | UI/UX, visual assets |
| QA | QA Engineer | {{NAME/AGENT}} | ALAI | Test planning, execution, sign-off |
| OPS | DevOps / Infrastructure | {{NAME/AGENT}} | ALAI | CI/CD, deployment, monitoring |
| CS | Client Sponsor | {{NAME}} | {{CLIENT}} | Executive decisions, final acceptance |
| CPO | Client Product Owner | {{NAME}} | {{CLIENT}} | Day-to-day client requirements |

---

## 4. RACI Matrix — Project Phases & Activities

<!-- GUIDANCE: Use role codes from Section 3. R=Responsible, A=Accountable, C=Consulted, I=Informed.
Remember: exactly ONE A per row. Expand rows for project-specific activities. -->

### 4.1 Project Initiation & Planning

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Project Charter creation | I | A | R | C | C | C | | | | | C | I |
| Project Brief / Proposal | I | A | R | R | R | C | | | | | I | I |
| Budget approval | A | C | I | I | | | | | | | I | |
| Stakeholder identification | I | C | R | C | R | | | | | | A | C |
| Communication Plan | I | C | A | C | R | | | | | | I | I |
| Risk Register (initial) | I | C | A | C | C | R | | | | | C | I |
| RACI Matrix | I | A | R | C | | | | | | | I | |
| Project kick-off meeting | I | A | R | R | R | R | R | R | R | R | A | R |

### 4.2 Requirements & Analysis

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Discovery workshops | I | I | C | A | R | C | | | | | C | R |
| Business Requirements Doc (BRD) | I | C | I | A | R | C | | | | | C | R |
| Functional Requirements (FRS) | I | C | I | A | R | R | C | C | C | | I | R |
| Non-Functional Requirements | I | C | I | C | R | A | C | | C | C | I | C |
| User Stories (backlog creation) | I | I | I | A | R | C | C | | | | I | R |
| Requirements sign-off | A | C | I | C | R | I | | | | | A | R |
| Requirements Traceability Matrix | I | I | I | A | R | C | | | R | | I | I |

### 4.3 Design

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| UX research / user flows | I | I | I | C | C | | | A | | | I | R |
| Wireframes | I | I | I | C | C | | | A | | | I | R |
| High-fidelity mockups | I | I | I | C | | C | | A | | | R | C |
| Design system / style guide | I | I | I | C | | C | C | A | | | I | I |
| Design review & approval | I | C | I | C | | C | | R | | | A | C |
| Technical architecture design | I | C | I | C | C | A | R | | | C | | |
| Architecture Decision Records (ADRs) | I | C | | | | A | R | | | C | | |
| Database schema design | I | | I | C | C | A | R | | | C | | |
| API contract design | I | | I | C | C | A | R | | | | | |
| Infrastructure design | I | | I | | | C | | | | A | | |

### 4.4 Development

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Sprint planning | | I | C | A | C | C | R | | C | | | I |
| Feature implementation | | I | I | I | | C | A | | | | | |
| Code review | | | I | | | A | R | | | | | |
| Unit test writing | | | I | | | C | A | | C | | | |
| Integration development | | | I | | C | A | R | | | C | | |
| UI implementation | | | I | C | | C | R | A | | | | |
| Daily standup | | I | A | R | R | R | R | R | R | R | | |
| Sprint demo | | I | R | A | R | R | R | R | R | R | I | R |
| Sprint retrospective | | I | A | R | R | R | R | R | R | R | | |
| Technical documentation | | | I | | | A | R | | | | | |

### 4.5 Testing & Quality Assurance

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Test plan creation | I | | I | C | C | C | | | A | | | I |
| Test case creation | | | I | C | C | C | C | | A | | | I |
| Unit testing execution | | | I | | | C | R | | A | | | |
| Integration testing | | | I | | | C | R | | A | C | | |
| Performance testing | | | I | C | | C | | | A | C | | I |
| Security testing | | C | I | | | C | | | A | C | | |
| UAT preparation | | | R | A | R | | | | R | | I | C |
| UAT execution | | | I | C | | | | | C | | R | A |
| UAT sign-off | I | C | I | C | | | | | C | | A | R |
| Defect triage | | | I | C | | C | R | | A | | | |
| Regression testing | | | I | | | C | R | | A | | | |
| Go/No-Go decision | I | A | C | C | | C | | | R | C | C | C |

### 4.6 Deployment & Launch

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Deployment checklist | | C | I | | | C | C | | C | A | | |
| Staging deployment | | | I | I | | C | R | | R | A | | |
| Production deployment | | C | I | I | | C | R | | R | A | | |
| DNS / SSL setup | | | | | | C | | | | A | | |
| Monitoring / alerting setup | | | I | | | C | | | | A | | |
| Go-live communication | I | I | A | R | | | | | | | I | R |
| Launch announcement | I | I | A | R | | | | C | | | C | C |
| Post-launch monitoring (48h) | | C | I | | | C | | | R | A | I | |

### 4.7 Post-Launch & Maintenance

| Activity / Deliverable | CEO | JD | PM | PO | BA | TL | DEV | DES | QA | OPS | CS | CPO |
|------------------------|-----|----|----|----|----|----|----|-----|----|----|----|----|
| Post-launch review (30 days) | I | C | A | R | R | R | R | | R | R | C | R |
| Lessons learned documentation | I | C | A | R | R | R | R | R | R | R | I | I |
| Handover documentation | I | C | A | R | R | A | R | R | | R | C | I |
| Bug fix triage | | | I | A | | C | R | | R | | I | C |
| Performance optimization | | | I | C | | A | R | | C | C | | |
| Client training | | | C | C | R | C | | | | | I | A |
| Project closure sign-off | A | C | R | | | | | | | | A | |

---

## 5. Escalation Matrix

<!-- GUIDANCE: When RACI ownership is disputed or a decision cannot be made at the current level,
use this escalation path. Response time = time by which escalation must be acknowledged. -->

| Escalation Level | Trigger | Escalate To | Response Time | Resolution Time |
|-----------------|---------|-------------|--------------|-----------------|
| L1 | Task-level disagreement | Tech Lead (technical) / PM (process) | 4 hours | 1 business day |
| L2 | Role/accountability dispute | PM + John | 4 hours | 1 business day |
| L3 | Scope/priority conflict | John + PO | 2 hours | Same day |
| L4 | Contract/budget/strategic decision | John + Alem | 4 hours | 2 business days |
| L5 | External/client dispute | Alem + Client Sponsor | 24 hours | 3 business days |

---

## 6. Handling Common RACI Conflicts

<!-- GUIDANCE: These are the most common issues teams face when implementing RACI. -->

**Issue: Multiple people marked A on same activity**
Action: Hold a 15-minute meeting; the most senior person or domain owner retains A; others become R or C.

**Issue: No one marked R on an activity**
Action: PM escalates to John immediately. A without R = activity will not get done.

**Issue: Too many C's (>4) on a single activity**
Action: Review each C — can they be demoted to I? Consult only those who provide unique value.

**Issue: Key stakeholder says "I didn't know about X"**
Action: Review their I assignments; add missing I designations; improve communication plan frequency.

**Issue: Team member disputes their R assignment**
Action: Discuss with PM; if skill gap, arrange training or reassign; document decision.

---

## 7. Review Cadence

<!-- GUIDANCE: The RACI matrix should be reviewed at key project milestones.
Team changes always trigger a RACI review. -->

| Trigger | Review Type | Owner |
|---------|-------------|-------|
| Project phase change | Full matrix review | PM |
| New team member joins | Role assignments update | PM |
| Team member leaves | Responsibility reassignment | PM |
| Scope change approved | Impact on roles | PM + PO |
| Monthly | Sanity check; any gaps? | PM |
| Project retrospective | Lessons for next RACI | PM |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Project Manager | | | |
| AI Director (John) | | | |
| Project Sponsor | | | |

# Communication Plan

# Communication Plan: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Communication Objectives

<!-- GUIDANCE: Define what this communication plan is designed to achieve.
Good communication reduces escalations, builds trust, and keeps everyone aligned.
Be specific about what "good communication" looks like on this project. -->

This communication plan ensures that all stakeholders on **{{PROJECT_NAME}}** receive accurate, timely, and relevant information throughout the project lifecycle. Specific objectives:

1. **Transparency** — All stakeholders have visibility into project status, risks, and decisions at the appropriate level of detail
2. **Alignment** — Requirements, priorities, and decisions are communicated before work begins, not after
3. **Accountability** — Issues, blockers, and escalations are surfaced quickly and resolved through defined channels
4. **Trust** — Consistent, professional communication builds client confidence and internal cohesion
5. **Documentation** — Key decisions, changes, and approvals are recorded and retrievable

---

## 2. Stakeholder Communication Needs Matrix

<!-- GUIDANCE: Different stakeholders need different information at different frequencies.
Over-communicating to senior stakeholders creates noise; under-communicating creates surprises.
Map each stakeholder's specific information needs and preferred channel. -->

| Stakeholder | Role | Information Needs | Preferred Channel | Frequency | Detail Level | Owner |
|-------------|------|-------------------|------------------|-----------|-------------|-------|
| {{NAME}} | Client Sponsor | Budget, milestone status, risks | Email + Video | Weekly | Executive summary | PM |
| {{NAME}} | Client PO | Feature status, backlog, demos | Video + Chat | Per-sprint | Detailed | PO |
| {{NAME}} | End Users | Launch date, training schedule | Email | Monthly + pre-launch | Simple | PM |
| Alem (CEO) | ALAI CEO | Budget, strategic issues | Direct | As needed / monthly | Executive | John |
| John (AI Director) | AI Director | Full project status, risks, decisions | Daily digest | Daily | Detailed | PM |
| {{NAME}} | PM | Blockers, task progress | Chat | Daily | Detailed | Team |
| {{NAME}} | Tech Lead | Technical decisions, architecture | Chat | Daily | Technical | Team |
| {{NAME}} | QA | Test status, bug counts | Chat | Daily | Detailed | QA |

---

## 3. Communication Channels & Tools

<!-- GUIDANCE: Define which tool is used for which purpose. Mixing channels (e.g., decisions in chat
instead of decision records) creates confusion. Establish norms and enforce them. -->

| Channel | Tool | Purpose | Who Has Access | Response SLA |
|---------|------|---------|---------------|-------------|
| Daily standup | Mattermost / written | Daily progress, blockers | Dev team | Same day |
| Sprint communication | Project chat channel | Sprint-specific updates | Full team | 4 hours |
| Video calls | {{TOOL, e.g., Teams/Zoom/Meet}} | Meetings requiring discussion | Invited parties | N/A (scheduled) |
| Status reports | Email | Formal stakeholder updates | Stakeholders | N/A (push) |
| Decision records | Project wiki / CLAUDE | Architectural & project decisions | Team + future ref | N/A (log) |
| Urgent/P1 issues | Phone + Mattermost | Critical blockers, incidents | All stakeholders | 15 minutes |
| Document sharing | {{TOOL, e.g., Google Drive/Confluence}} | Documents, specs, deliverables | Authorized team | N/A |
| Issue tracking | Mission Control / GitHub Issues | Bugs, tasks, change requests | Team | 24 hours |
| External email | Email | Formal client communication | PM, John, Alem | 24 hours |
| Signing | Documenso (sign.alai.no) | Contracts, NDAs, approvals | Parties to sign | Per agreement |

---

## 4. Meeting Schedule

<!-- GUIDANCE: Document every recurring meeting. Unnecessary meetings are expensive;
missing meetings create gaps. Every meeting needs a purpose, agenda, and owner. -->

### 4.1 Regular Meetings

| Meeting | Purpose | Frequency | Day / Time | Duration | Required Attendees | Facilitator | Output |
|---------|---------|-----------|------------|----------|-------------------|-------------|--------|
| Daily Standup | Progress, blockers, coordination | Daily (weekdays) | {{DAY}} {{TIME}} | 15 min | Dev team + PM | Scrum Master | Written standup log |
| Sprint Planning | Backlog grooming, sprint goal, task assignment | Every 2 weeks (Monday) | {{TIME}} | 2 hours | Team + PO | Scrum Master | Sprint backlog |
| Sprint Review / Demo | Demo completed features to client | Every 2 weeks (Friday) | {{TIME}} | 1 hour | Team + Client | PO | Sprint demo recording |
| Sprint Retrospective | Team process improvement | Every 2 weeks (Friday) | {{TIME}} | 1 hour | Dev team (no client) | Scrum Master | Retro action items |
| Client Sync | Relationship, quick updates, concerns | Weekly | {{DAY}} {{TIME}} | 30 min | PM + Client PO | PM | Meeting notes |
| Steering Committee | Strategic decisions, budget, major risks | Monthly | {{DAY}} {{TIME}} | 1 hour | PM + John + Client Sponsor | PM | Decision record |
| Risk Review | Risk register update | Weekly (sprint planning) | Embedded | 15 min | PM + Tech Lead | PM | Updated risk register |

### 4.2 Event-Triggered Meetings

| Trigger | Meeting Type | Called By | Who | Target Timing |
|---------|-------------|-----------|-----|---------------|
| P1 incident | Incident response call | PM or Tech Lead | All hands | Within 1 hour |
| New risk Score ≥ 15 | Risk escalation | PM | PM + John + Sponsor | Within 24 hours |
| Scope change request received | Change review | PM | PM + TL + PO | Within 3 business days |
| Milestone missed | Recovery planning | PM | PM + TL + John | Within 24 hours |
| Go-live decision point | Go/No-Go review | PM | PM + TL + QA + John | 5 days before planned launch |

---

## 5. Reporting Cadence

<!-- GUIDANCE: Reports are the paper trail of project health. Define what each report contains,
who writes it, and who receives it. Templates for key reports are embedded below. -->

| Report | Frequency | Prepared By | Distributed To | Delivery Method | Deadline |
|--------|-----------|-------------|---------------|-----------------|----------|
| Daily Standup Log | Daily | PM / SM | John + internal team | Mattermost | EOD each day |
| Sprint Report | Per sprint | PM | Client + John | Email | Sprint end + 1 day |
| Weekly Status Report | Weekly | PM | Client Sponsor + John | Email | Every {{WEEKDAY}} by {{TIME}} |
| Monthly Risk Report | Monthly | PM | John + Alem | Email | 1st of each month |
| Monthly Budget Report | Monthly | PM | John + Alem | Email | 1st of each month |
| Milestone Report | Per milestone | PM | All stakeholders | Email | Day of milestone completion |
| Post-Launch Report | Once | PM | John + Client + Alem | Email | 30 days post-launch |

### 5.1 Weekly Status Report Template

<!-- GUIDANCE: Paste this template into your email each week. Keep it under 1 page. -->

```
SUBJECT: [{{PROJECT_NAME}}] Weekly Status — Week of {{DATE}}

STATUS: 🟢 On Track | 🟡 At Risk | 🔴 Delayed

## This Week
- {{COMPLETED_ITEM_1}}
- {{COMPLETED_ITEM_2}}

## Next Week
- {{PLANNED_ITEM_1}}
- {{PLANNED_ITEM_2}}

## Risks & Issues
| # | Issue/Risk | Status | Action Required From Client |
|---|------------|--------|----------------------------|
| 1 | {{ISSUE}} | {{STATUS}} | {{CLIENT_ACTION}} |

## Milestones
| Milestone | Target | Status |
|-----------|--------|--------|
| {{MILESTONE}} | {{DATE}} | ✅ Done / ⏳ In Progress / ⚠️ At Risk |

## Decisions Needed
- [ ] {{DECISION_NEEDED_BY_DATE}}

## Budget
- Spend to date: {{NOK}} / {{TOTAL_NOK}} ({{PERCENT}}%)
```

---

## 6. Escalation Paths & Response SLAs

<!-- GUIDANCE: Document exactly who to contact when and how fast they must respond.
Ambiguity in escalation paths leads to issues sitting unresolved. -->

| Level | Trigger | Escalate To | Channel | Response SLA | Resolution SLA |
|-------|---------|-------------|---------|-------------|----------------|
| L1 | Blocker within team (any) | Tech Lead | Chat | 2 hours | 4 hours |
| L2 | Blocker affecting sprint goal | PM | Chat + call if needed | 1 hour | Same day |
| L3 | Client-impacting issue | PM + John | Chat + email | 1 hour | 4 hours |
| L4 | Milestone risk (>3 days slip) | John + Client PM | Email + video | 4 hours | 2 business days |
| L5 | Budget overrun risk | John → Alem | Direct | 2 hours | 24 hours |
| L6 | Contract/scope dispute | John + Alem | Direct + email | 4 hours | 3 business days |
| P1 | Production incident | PM + Tech Lead + John + Client | Phone | 15 minutes | Per incident severity |

---

## 7. Documentation Standards

<!-- GUIDANCE: Consistent naming and storage prevents the "where is that document?" problem.
These standards apply to all project artifacts. -->

### 7.1 File Naming Convention

```
[PROJECT]-[DOCUMENT_TYPE]-[DATE]-[VERSION].[ext]
Example: ACME-sprint-report-2026-02-14-v1.0.pdf
Example: ACME-meeting-notes-2026-02-14.md
```

### 7.2 Document Storage Locations

| Document Type | Location |
|--------------|----------|
| Project charter, brief, RACI | `~/projects/{{PROJECT}}/docs/governance/` |
| Requirements, user stories, BRD | `~/projects/{{PROJECT}}/docs/requirements/` |
| Design files, mockups | `~/projects/{{PROJECT}}/docs/design/` |
| Meeting notes | `~/projects/{{PROJECT}}/comms/meetings/` |
| Standups | `~/projects/{{PROJECT}}/comms/standups/` |
| Decision records | `~/projects/{{PROJECT}}/comms/decisions/` |
| Sprint reports | `~/projects/{{PROJECT}}/comms/reports/` |
| Client-facing documents | `~/projects/{{PROJECT}}/comms/client/` |

### 7.3 Version Control

- All documents use semantic versioning: MAJOR.MINOR (e.g., 1.0, 1.1, 2.0)
- MAJOR version = significant structural change or approval milestone
- MINOR version = content updates, corrections, additions
- Every version tracked in the Document History table at the top of each file

---

## 8. External Communication Protocols

<!-- GUIDANCE: Communications to parties outside the project team (client contacts, press,
partners, regulators) require additional care. Define who is authorized and how. -->

| Communication Type | Authorized Speakers | Approval Required | Notes |
|-------------------|--------------------|--------------------|-------|
| Client progress updates | PM, John | None (within scope) | Must be factual, professional |
| Client escalations / issues | PM → John | John approval | Never promise resolution timelines without TL input |
| Press / public statements | Alem | Alem only | No project details without explicit approval |
| Partner communication | John | John | Document all commitments |
| Legal / contract matters | Alem + John | Alem | No binding commitments without Alem sign-off |
| Social media | Alem | Alem | Check brand guidelines first |
| Third-party vendor comms | Tech Lead / DevOps | PM awareness | Cc PM on all vendor emails |

---

## 9. Crisis Communication Plan

<!-- GUIDANCE: Define how communication changes when things go seriously wrong.
A crisis is any situation that threatens project delivery, client relationship, or ALAI reputation. -->

### 9.1 Crisis Triggers

- Production data breach or security incident
- > 2-week unplanned project delay
- Client relationship breakdown
- Team member critical unavailability (e.g., extended illness)
- Budget overrun > 25%
- Legal dispute

### 9.2 Crisis Communication Protocol

1. **Identify** — Team member identifies crisis; notifies PM immediately
2. **Contain** — PM + Tech Lead assess scope and containment options (max 1 hour)
3. **Escalate** — PM notifies John within 1 hour; John notifies Alem if L4+
4. **Communicate** — PM prepares crisis communication draft; John approves before sending
5. **Update** — Stakeholders receive updates every 4 hours until resolved
6. **Resolve** — Crisis declared over by John; post-mortem conducted within 48 hours
7. **Learn** — `/learning-opportunity` — crisis becomes system fix

### 9.3 Crisis Communication Template

```
SUBJECT: [URGENT] {{PROJECT_NAME}} — {{CRISIS_SUMMARY}}

Dear {{STAKEHOLDER}},

We are writing to inform you of an issue affecting {{PROJECT_NAME}}.

SITUATION: {{WHAT_HAPPENED}}
IMPACT: {{WHAT_IS_AFFECTED}}
IMMEDIATE ACTIONS TAKEN: {{WHAT_WE_HAVE_DONE}}
NEXT STEPS: {{WHAT_WE_WILL_DO}}
EXPECTED RESOLUTION: {{TIMELINE}}

We will provide updates every {{FREQUENCY}} until this is resolved.

Contact: {{PM_NAME}} — {{PM_EMAIL}} — {{PM_PHONE}}

{{NAME}}
{{TITLE}}
```

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Project Manager | | | |
| AI Director (John) | | | |
| Client Sponsor | | | |