Files
acdl/docs/raci.md
T
Jon Chery e891496163 docs(P2): PDLC-upstream scope + RACI matrix + 2 deck slides (REQ-215, REQ-216, REQ-228)
REQ-215: RACI matrix in PROJECT.md (§ RACI Matrix) + docs/raci.md
(citizen-dev-facing copy). 3 roles (Citizen Developer / Platform / Release
Management co-owned). 7 work categories × R/A/C/I. Compliance-standard
equivalence note: any upstream source (AI agent, SDLC, dev platform) is
subject to the same gate.

REQ-216: PDLC-upstream scope in PROJECT.md (§ Scope) + docs/scope.md.
Promotes Core Tenet #2 + Anti-Goal #1 from buried tenets to a dedicated,
unmissable scope statement.

REQ-228: 2 new deck slides (17 Scope + 18 RACI) → 20 slides. Arc preview
updated. Talking points synced. HTML + PPTX re-rendered (21 PPTX slides).

---ci---
project: acdl
phase: 2
milestone: v1.18
status: execute
requirements:
  covered: [REQ-215, REQ-216, REQ-228]
  partial: []
---/ci---
2026-08-06 15:07:10 +00:00

3.7 KiB

RACI — Who Owns What

Source of truth: .ciagent/PROJECT.md § RACI Matrix (v1.18, REQ-215, D-139). This page is the citizen-developer-facing copy.

Nova's delivery lifecycle has three roles. This page clarifies who owns what — so the citizen developer knows what they bring, what the platform provides, and what is co-owned.

The Three Roles

Citizen Developer (CD)

That's you — the consumer (technical developer L3A or non-technical L3B). You are Responsible for all Functional Requirements (FRs) and User Acceptance Testing (UAT). You produce the FRs + UAT via your AI coding agent, an upstream agentic SDLC platform, or any upstream development platform. The source does not matter — all are subject to the same compliance standards (the submission-readiness gate, the contract schema, the policy envelope, the immutable audit stream). Nova validates the submission, not the author.

Platform (Nova)

Nova is Responsible for all Non-Functional Requirements (NFRs), Infrastructure (cloud resource lifecycle, state, IAM), QA (the platform-side quality checks: policy enforcement, confidence scoring, schema validation), and Production deployments to cloud (the apply path, the pipeline, the release mechanics).

Release Management (RM) — co-owned

The release is co-owned. The platform performs the QA + SRE attestations agentically (it runs the confidence signal, the policy checks, the separation-of-duties). The citizen developer oversees and triggers the actual release — the human attestation at the stage gate is your authorization. The platform runs the checks; you authorize the promotion. This is the "autonomy in operations, human at stage gates" model.

The Matrix

Work Category Citizen Developer Platform Release Management
Functional Requirements (FRs) R/A C I
User Acceptance Testing (UAT) R/A C I
Non-Functional Requirements (NFRs) I R/A C
Infrastructure (cloud, state, IAM) I R/A C
QA (policy, confidence, schema checks) C R/A I
Production deployment to cloud I R/A C
Release attestation (QA + SRE sign-off) A R R

Key: R = Responsible (does the work) · A = Accountable (owns the outcome, sign-off) · C = Consulted · I = Informed.

What This Means in Practice

You (Citizen Developer) bring:

  • Your application code + a contract that declares intent.
  • Your FRs (what the application does).
  • Your UAT (you accept the deployment when it meets your FRs).

Nova (Platform) provides:

  • The NFRs (security, observability, compliance — baked into the pipeline, not your concern).
  • The infrastructure (cloud resources, state management, IAM scoping).
  • The QA (policy enforcement, confidence scoring, schema validation).
  • The production deployment (the apply path, the pipeline, the release).

You co-own the release:

  • Nova runs the attestations (QA confidence, SRE operational readiness).
  • You authorize the promotion at the stage gate. No promotion happens without your recorded attestation.

Compliance Standards Apply Equally

Your FRs + UAT may come from any source — an AI coding agent, an agentic SDLC platform, or a traditional IDE. Nova does not differentiate. All submissions pass through the same gate (schemas/submission-readiness.schema.json): tags, environment metadata, policy preconditions, profile markers. The compliance standards are the same regardless of how the code was authored. This is by design: the audit trail is the same, the policy envelope is the same, the evidence stream is the same. The source does not matter; the submission does.