Skip to content

Commit bcbc1d1

Browse files
nsalvacaonexomodeling-blip
nsalvacao
and
nexomodeling-blip
committed
feat(waterfall-lifecycle): add supplementary references (artefact-catalog, handover-reference, phase-assumptions-catalog, role-accountability-model)
Generated by Nuno Salvação Co-Authored-By: Nexo <nexo.modeling@gmail.com>
1 parent 33eb3e3 commit bcbc1d1

1 file changed

Lines changed: 154 additions & 0 deletions

File tree

‎plugins/waterfall-lifecycle/references/role-accountability-model.md‎

Lines changed: 154 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
# Role Accountability Model — Waterfall Lifecycle
2+
3+
## Important: Guidance, Not Enforcement
4+
5+
This document provides a **recommended** accountability model for the predictive lifecycle. It is guidance, not a fixed constraint.
6+
7+
Actual authority, role names, and sign-off obligations depend on your organisation's structure, governance model, and contractual context. The gate-reviewer agent in this lifecycle asks "who is the sign-off authority?" at gate time without enforcing a specific role. This reference document helps teams answer that question consistently.
8+
9+
Adapt freely. The goal is that someone owns each activity, someone approves each gate, and nobody is surprised by accountability at handover time.
10+
11+
---
12+
13+
## 1. Role Definitions
14+
15+
Standard roles referenced in this model. Teams may use different titles; map to these by function.
16+
17+
| Role | Function | Typical Accountability |
18+
|------|----------|----------------------|
19+
| **Product Owner** | Represents business and user interests; owns the product vision and priorities | Problem statement, requirements sign-off, acceptance criteria, UAT |
20+
| **Technical Lead** | Leads engineering delivery; owns technical quality and implementation decisions | Build completeness, code quality, integration readiness |
21+
| **Architect** | Owns solution design; accountable for architectural decisions and their traceability | HLD, LLD, ADR set, control matrix, design approval |
22+
| **QA Lead** | Owns verification and validation strategy and execution | Test design, test execution evidence, defect triage, validation reports |
23+
| **Data Engineer** | Owns data pipelines, dataset preparation, and data quality | Data requirements, dataset documentation, data closure |
24+
| **AI/ML Engineer** | Owns model development, training, evaluation, and integration | AI design package, experiment log, model card, AI evaluation |
25+
| **Security Lead** | Owns security architecture, security review, and control design | Security requirements, security design review, security validation |
26+
| **Operations Lead** | Owns operational readiness, runbooks, and service acceptance | Runbooks, operational readiness review, operations acceptance |
27+
| **Sponsor** | Holds executive accountability; approves funding, gates, and risk acceptance | Gate approval, waiver acceptance, retirement decision |
28+
| **Governance Forum** | Collective body for major decisions; composition depends on org context | Gate decisions for significant phases, significant change approval |
29+
30+
---
31+
32+
## 2. Responsibility Matrix
33+
34+
RACI-style guidance for key lifecycle activities. Use as a starting point; adjust for your team structure.
35+
36+
**Key:** R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted, I = Informed, `—` = not typically involved
37+
38+
### Phase 1 — Opportunity and Feasibility
39+
40+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
41+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
42+
| Define problem statement | R/A | I | C | — | C | I | C | I | PM may hold R if Product Owner is not yet engaged |
43+
| Conduct feasibility assessment | C | C | R/A | — | C | C | I | I | Architecture leads technical feasibility |
44+
| Assess data feasibility | C | C | C | — | C | — | I | — | Data Engineer typically does the work |
45+
| Screen for AI feasibility | C | C | R | — | C | — | I | — | AI/ML Engineer supports this activity |
46+
| Identify initial risks | C | C | C | — | R | C | A | C | Risk / Compliance owner may hold A |
47+
| Draft project charter | R | C | C | — | — | — | A | C | PM typically drafts |
48+
| Approve Gate A | C | C | C | — | — | — | A | C | Sponsor is minimum sign-off authority |
49+
50+
### Phase 2 — Requirements and Baseline
51+
52+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
53+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
54+
| Elicit business requirements | R/A | C | C | C | C | C | I | I | BA supports Product Owner |
55+
| Define AI acceptance criteria | R | C | C | R | — | — | I | — | QA Lead and AI/ML Engineer co-own |
56+
| Define NFRs | C | R | A | C | R | R | I | — | Operations and Security own their respective NFR sets |
57+
| Baseline requirements | A | C | C | C | C | C | C | I | PM or BA typically owns the baseline pack |
58+
| Define acceptance criteria | R | C | C | R/A | — | — | I | — | QA Lead owns testability review |
59+
| Approve Gate B | A | C | C | — | — | — | A | C | Sponsor or delegated authority minimum |
60+
61+
### Phase 3 — Architecture and Solution Design
62+
63+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
64+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
65+
| Define solution architecture | C | C | R/A | C | C | C | I | I | Enterprise Architect may hold A in large orgs |
66+
| Define control matrix | C | C | R | C | R/A | C | I | — | Security Lead holds accountability for security controls |
67+
| Define test design | C | C | C | R/A | — | C | — | — | QA Lead owns the test design package |
68+
| Conduct security design review | C | C | C | — | R/A | — | — | I | Privacy Lead co-owns where applicable |
69+
| Approve Gate C | C | C | A | C | C | — | A | C | Design Authority may substitute for Governance Forum |
70+
71+
### Phase 4 — Build and Integration
72+
73+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
74+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
75+
| Set up environments | I | C | C | C | C | R/A | I | — | DevOps / Platform Engineer typically does the work |
76+
| Build application components | I | R/A | C | C | C | C | — | — | Engineering team delivers |
77+
| Implement AI components | C | C | C | C | C | — | — | — | AI/ML Engineer is R; Technical Lead is A |
78+
| Manage defect log | C | A | — | R | — | — | — | — | QA Lead maintains the log |
79+
| Approve Gate D | C | A | C | C | — | — | — | C | Delivery Authority defined per project |
80+
81+
### Phase 5 — Verification and Validation
82+
83+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
84+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
85+
| Execute functional testing | C | C | — | R/A | — | — | — | — | QA team executes |
86+
| Execute security testing | — | C | — | C | R/A | — | — | — | Security Lead owns security validation |
87+
| Execute AI validation | C | C | C | R | — | — | — | — | AI/ML Engineer and QA Lead co-own |
88+
| Conduct UAT | R/A | I | — | C | — | C | I | — | Product Owner leads UAT acceptance |
89+
| Approve waivers | A | C | C | C | C | C | A | C | Sponsor must approve significant waivers |
90+
| Approve Gate E | A | C | C | A | C | C | A | C | Governance Forum for high-risk releases |
91+
92+
### Phase 6 — Release and Transition to Operations
93+
94+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
95+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
96+
| Plan release and cutover | C | C | — | C | C | R | A | I | Release Manager may hold A |
97+
| Execute deployment | I | R | — | C | C | R | I | — | Operations and Engineering co-own execution |
98+
| Accept service (handover) | I | C | — | — | — | R/A | I | — | Operations Lead must formally accept |
99+
| Run hypercare | C | R | — | C | — | R/A | I | — | Operations owns hypercare; Engineering supports |
100+
| Approve Gate F | C | C | — | — | — | C | A | C | Release Authority minimum |
101+
| Approve Gate G | C | C | — | — | — | A | C | I | Operations Lead is minimum sign-off |
102+
103+
### Phase 7 — Operate, Monitor and Improve
104+
105+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
106+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
107+
| Operate and monitor service | C | I | — | — | C | R/A | I | — | Operations owns BAU |
108+
| Monitor AI behaviour | R | C | — | C | — | R | I | — | AI/ML Engineer and Operations co-own |
109+
| Classify and approve changes | R | C | C | C | C | C | C | A | Governance Forum approves significant changes |
110+
| Update baselines | C | C | A | C | C | C | — | I | Architect owns design baseline updates |
111+
112+
### Phase 8 — Retire or Replace
113+
114+
| Activity | Product Owner | Technical Lead | Architect | QA Lead | Security Lead | Operations Lead | Sponsor | Governance Forum | Notes |
115+
|----------|--------------|----------------|-----------|---------|---------------|-----------------|---------|-----------------|-------|
116+
| Decide retirement | R | C | C | — | C | C | A | C | Sponsor holds final authority |
117+
| Assess impact | C | C | R | — | C | R | I | I | Architecture and Operations co-own |
118+
| Plan sunset | C | C | C | — | C | R/A | C | C | Operations owns execution planning |
119+
| Execute decommissioning | C | R | — | — | R | R/A | I | — | Coordinated by Operations |
120+
| Close data and access | — | C | — | — | R | R/A | I | — | Security and Operations co-own |
121+
| Approve Gate H | A | C | — | — | C | C | A | C | Sponsor is minimum sign-off |
122+
123+
---
124+
125+
## 3. Sign-off Authority per Gate
126+
127+
Minimum required sign-off authority at each gate. Additional signatories are encouraged for high-risk or regulated contexts.
128+
129+
| Gate | Name | Minimum Sign-off Authority | Optional Additional Signatories | Notes |
130+
|------|------|--------------------------|--------------------------------|-------|
131+
| A | Initiation Approval | Sponsor | Governance Forum | For very small projects, a delegated product authority may suffice |
132+
| B | Requirements Baseline Approval | Sponsor or delegated authority + Product Owner | Governance Forum, Security Lead | Architecture and QA should be consulted before sign-off |
133+
| C | Design Approval | Architect + Sponsor | Design Authority, Security Lead, Governance Forum | Security Lead sign-off required if significant security architecture decisions were made |
134+
| D | Build Complete / Integration Ready | Technical Lead (delivery authority) | Architect, QA Lead | Sponsor typically not required unless significant scope deviation occurred |
135+
| E | Validation Complete / Release Readiness | QA Lead + Product Owner | Sponsor, Governance Forum, Security Lead | Sponsor endorsement required for significant waivers; Governance Forum for high-risk releases |
136+
| F | Go-Live Approval | Sponsor (or delegated Release Authority) | Governance Forum, Operations Lead | Operations Lead must confirm readiness before Sponsor signs |
137+
| G | Hypercare Exit / Service Acceptance | Operations Lead | Sponsor, Governance Forum | Operations Lead is the primary accountable party for service acceptance |
138+
| H | Retirement Approval | Sponsor + Operations Lead | Governance Forum, Legal / Compliance | Legal / Compliance sign-off required where data retention or regulatory obligations are involved |
139+
140+
---
141+
142+
## 4. Hybrid Model Note
143+
144+
This accountability model is a guidance framework, not an enforcement mechanism. Organisations apply it differently:
145+
146+
**Smaller teams:** Roles collapse — the same person may be Product Owner, QA Lead, and PM. The model still applies: identify who holds each accountability, even if it is the same individual for multiple roles.
147+
148+
**Larger organisations:** Governance Forum may be mandatory for all gates. Design Authority may be separate from Sponsor. Security and Legal may be formal gate blockers.
149+
150+
**Regulated contexts:** Additional sign-off authorities may be required by regulation (e.g., Data Protection Officer for data-related gates, Responsible AI Officer for AI evaluation gates). Add these as mandatory additional signatories in your project context.
151+
152+
**Gate reviewer agent behaviour:** The gate-reviewer agent in this lifecycle does not enforce a specific sign-off authority. At each gate review, it asks: "Who is the sign-off authority for this gate?" and records the answer in the gate pack. The agent treats the response as the project's declared authority — it does not validate against this model. This is intentional: the model provides the reference; the project team owns the decision.
153+
154+
**When to deviate:** Deviations from this model are acceptable and expected. When deviating, record the rationale in the gate pack or project governance log. The key requirement is that accountability is explicit, not that it follows this specific model.

0 commit comments

Comments
 (0)