A role, a person, and an organization are different concepts
One person may cover several roles in a small, bounded scope, while several people may share one role in a larger scope. What matters is whether one named role makes the final decision, the performer has competency and capacity, and a backup or escalation route preserves continuity.
A supplier can perform work without taking over business decisions, data and access approval, production risk, incident priority, spend, legal terms, or exit. Internal-led, hybrid, and supplier-led models can each be suitable depending on the project.
Product mechanics reveal work surfaces, not staffing numbers
A standalone app contains source, environment, infrastructure, migrations, tests, and deployment artifacts. Modules can add user interface, APIs, entities, migrations, events, workers, and overrides. This supports roles for architecture, development, data, testing, platform, and operation, but does not prove a person count, seniority mix, schedule, or supplier form.
Production launch does not end responsibility
Production workers run as separate processes with an asynchronous Redis queue. Structured logs create a signal, but the team still chooses collection, retention, access, alerting, and incident use. Upgrades can contain downstream actions. A service operator, recovery owner, upgrade owner, and incident route must be named before production handover.
A ready map means information is complete for review
Ready for decision review requires an owner, performer, competency evidence, confirmed capacity, backup or escalation, and handover path for every critical domain. It does not mean the team, system, security posture, supplier, or launch is approved.
Five tests for every assignment
A title, supplier contract, or tool license does not pass these tests by itself.
Accountable outcome owner
One named human role can make the final decision and accept the consequence.
Responsible performer
The internal or supplier role that performs the work is explicit.
Demonstrated competency
Relevant artifacts and observed outcomes support the assignment, not a title alone.
Available capacity
The role has agreed time, service coverage, tools, and decision access for the expected demand.
Continuity and backup
A backup or usable escalation route can act when the primary performer is unavailable.
A role is not a person or organization. One person may cover several archetypes in a bounded scope, several people may share one role in a larger scope, and a supplier may perform work while one internal human role remains accountable.
Product mechanics that trigger ownership
A standalone app contains source, environment, infrastructure, migrations, tests, and deployment artifacts. Modules can add pages, APIs, dependency injection, entities, migrations, validation, events, workers, translations, and overrides. Ejected modules become app-local maintenance. Production workers run separately with an asynchronous Redis queue. Structured logs exist, but collection, retention, access, alerts, and incident use remain operating decisions. Upgrade notes can require downstream action.
Product fact identifies a responsibility trigger. Editorial mapping proposes an owner pattern. Your project decides the real assignment. Supplier statements remain attributed commercial claims.
Revision: 01911d00e28f44cf484d0b1d04860dcfef5370bf · Reviewed: 2026-07-14
Lifecycle responsibility map
| Stage | Decisions | Outputs | Accountable role type | Likely performers | Evidence | Handoff | Failure signal |
|---|---|---|---|---|---|---|---|
| Evaluation | Fit, business outcome, edition and sourcing decision | Decision brief and unresolved assumptions | Sponsor | Sponsor, process owner, technical advisor | Named outcome owner and evidence ledger | Approved scope hypothesis | No owner or supplier claim used as proof |
| Discovery | Processes, boundaries, data, users and acceptance | Scope, process map and acceptance outcomes | Product or process owner | Business analysts, users, data owner, supplier | Signed decisions with source owners | Architecture and delivery inputs | Unknown process or data authority |
| Architecture | Boundaries, modules, tenancy, integrations and operations | Decision records and responsibility boundaries | Solution architecture owner | Architect, engineers, security and platform roles | Reviewed decisions linked to product mechanics | Build plan and control requirements | Architecture exists only in supplier knowledge |
| Build | Configuration, local modules, overrides and integrations | Reviewed source, migrations and documentation | Product and technical owners | Application and integration engineers | Reviewable source and change evidence | Versioned release candidate | Unreviewed code or no internal access |
| Data and integration | Migration, interfaces, reconciliation and ownership | Mapped data, trials and failure handling | Data and integration owners | Data, application and source-system performers | Trial evidence and reconciliation results | Accepted dataset and operating runbook | Unowned mapping or silent failure path |
| Verification | Technical tests, controls and business acceptance | Traceable test and acceptance evidence | Quality and business acceptance owners | Engineers, testers, process users and security reviewers | Observed results against agreed outcomes | Release evidence pack | Generated tests treated as approval |
| Release | Deployment, migration, rollback and final decision | Approved runbook, rollback and ownership handoff | Release owner and accountable sponsor | Platform, application, data and service roles | Rehearsal and signed residual gaps | Operable production service | No day-two operator or rollback owner |
| Operation | Availability, support, incidents, recovery and monitoring | Service records, exercises and reviewed signals | Service owner | Support, platform, database and application roles | Incident and recovery exercise evidence | Known service health and action backlog | Supplier-only access or no incident route |
| Change | Upgrades, dependencies, features and technical debt | Impact record, regression and rollback evidence | Product, technical and release owners | Engineering, platform and acceptance roles | Exact-version rehearsal and review | Updated runbooks and baseline | No upgrade owner or test capacity |
| Exit | Source, data, credentials, knowledge and supplier transition | Reproducible build, exports, revoked access and walkthrough | Sponsor and knowledge or exit owner | Internal owners and outgoing or incoming supplier roles | Independent build and handover exercise | Accepted custody and transition backlog | No source, build, data or decision history |
Responsibility domain matrix
| Domain | Product or project trigger | Required outcome | Lifecycle stages | Accountable role type | Possible performers | Competency evidence | Capacity evidence | Backup | Escalation | Cadence | Handover artifact | Not applicable only when |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Executive sponsorship and outcomes | Any evaluation or funded scope | Business outcome, risk appetite and spend decisions have one owner | Evaluation, release, change, exit | Accountable sponsor | Internal sponsor office, shared advisors | Decision brief and accepted tradeoffs | Decision access and scheduled gate attendance | Named delegated decision role | Executive governance route | At every material gate | Decision ledger and residual risks | Never for an active project |
| Product and process ownership | Any business workflow in scope | Scope, priorities and acceptance outcomes remain coherent | Discovery through change | Product or process owner | Internal users, analysts, supplier facilitators | Process map and accepted outcome examples | Backlog and acceptance time reserved | Deputy process decision role | Sponsor | Each planning and acceptance cycle | Prioritized backlog and acceptance rules | Only with a recorded no-business-process reason |
| User and adoption ownership | People will use or be affected by the application | Access, communication, training and feedback are owned | Discovery, verification, release, operation | Adoption or process owner | Internal champions, support, training supplier | Usability evidence and support content | Coverage for launch and new starters | Secondary support route | Service or product owner | Before release and recurring review | Role-based guidance and issue themes | Only for a verified non-user-facing scope |
| Data governance and migration | Existing, imported, created or exported data | Meaning, quality, access, retention and reconciliation are decided | Discovery, data, verification, operation, exit | Data owner | Data engineers, source owners, supplier | Mapping, trial and reconciliation evidence | Time for cleansing, trials and exception review | Deputy data steward | Sponsor and privacy owner | Each migration and material data change | Data dictionary, mapping and export proof | Only if no project data exists, with owner and review trigger |
| Solution architecture | Any deployed application or integration boundary | System boundaries and technical decisions are reviewable | Evaluation through change | Solution architecture owner | Internal architect, senior engineers, supplier architect | Decision records and reviewed system context | Review coverage for material changes | Second reviewer with repository access | Technical governance and sponsor | At baseline and material change | Architecture records and dependency map | Never for a deployed application |
| Module and customization design | Configuration, custom fields, local modules, overrides or ejection | The smallest justified mechanism has owners and rollback | Architecture, build, verification, change | Product and technical owner | Application engineers, supplier developers | Design record, reviewed code and tests | Maintenance and regression time | Reviewer able to maintain the mechanism | Architecture owner | Each customization and upgrade | Source, tests, disable path and upgrade trigger | When no customization is selected, record decision and review trigger |
| Application development and review | Any app-local source or changed package usage | Changes are reviewable, reproducible and maintainable | Build, verification, change, exit | Technical owner | Application engineers and reviewers | Reviewed changes, build and defect evidence | Delivery, review and maintenance allocation | Independent code reviewer | Architecture and product owners | Every change set | Repository, build instructions and decision history | Only if no app-local change exists, with exact baseline |
| API and integration ownership | Any external interface, event, webhook, file or synchronization | Contracts, reconciliation and failure handling are owned | Architecture, data, verification, operation, change | Integration and process owners | Integration engineers and external-system teams | Contract tests and failure rehearsal | Coverage for incidents and upstream change | Second interface owner | Service and data owners | At change and recurring reconciliation review | Contract, credentials custody and runbook | When no interface exists, record owner and review trigger |
| Security, privacy, access and tenancy | Any users, roles, sensitive data, organizations or tenants | Access, data isolation, control acceptance and response are owned | Discovery through exit | Security, privacy and business data owners | Engineers, operators, reviewers, supplier | Threat and access review with test evidence | Review and incident coverage | Named security escalation role | Accountable risk owner | Before access, release and material change | Access model, decisions, findings and response route | Never when application data or users exist |
| Platform, environment, secrets and configuration | Any running environment | Deployment, configuration and secret custody remain controlled | Architecture, release, operation, change, exit | Platform or service owner | Internal operator, cloud team, hosting supplier | Deployment rehearsal and configuration evidence | Coverage for deploys and service events | Secondary operator with approved access | Service owner and security owner | Each release and configuration review | Infrastructure definition, inventory and access transfer | Never for a running environment |
| Database, migration, backup and recovery | Any persistent application data | Schema change, backup custody and recovery proof are owned | Build, release, operation, change, exit | Data recovery or platform owner | Database and platform operators | Migration rehearsal and recovery proof | Coverage for release and recovery events | Second operator with restore access | Service, data and sponsor roles | Each migration and scheduled recovery exercise | Schema history, backup inventory and restore runbook | Never when persistent data exists |
| Queues, Redis, workers and scheduled processing | Asynchronous queues, workers, events or schedules are enabled | Separate processes, retries, idempotency and failure handling are operated | Architecture, build, release, operation, change | Service or platform owner | Application and platform operators | Queue failure and retry exercise | Worker monitoring and incident coverage | Secondary operator | Application and service owners | Continuous signals and recurring review | Queue inventory, concurrency choices and runbook | When disabled, retain decision owner and enablement review trigger |
| Logging, monitoring and observability | Any operated environment | Signals, collection, retention, access, alerts and incident use are decided | Verification, release, operation, change | Service and security owners | Application and platform operators | Monitoring review and incident exercise | Alert and investigation coverage | Secondary responder | Incident route | Continuous signals and scheduled review | Signal catalog, access, alerts and runbook | Never for a production service |
| Test strategy and business acceptance | Any changed or accepted behavior | Technical and business evidence matches agreed outcomes | Discovery, build, verification, release, change | Quality and business acceptance owners | Engineers, testers, users, supplier | Traceable test evidence and observed acceptance | Regression and user review time | Deputy acceptance role | Product owner and sponsor | Every release and material change | Test inventory, results and accepted gaps | Never for changed behavior |
| Release, deployment, rollback and change control | Any environment promotion or production change | One controlled change can be deployed, observed and reversed | Verification, release, operation, change | Release owner | Application, platform, data and supplier roles | Deployment and rollback rehearsal | Release window and response coverage | Secondary release operator | Sponsor and service owner | Every release | Release record, artifacts and rollback decision | Never for production change |
| Service desk and incident response | Users or business processes depend on the service | Requests, incidents, priority and communication have routes | Release, operation, change, exit | Service owner | Internal support, supplier support, technical responders | Ticket and incident exercise evidence | Agreed service coverage and surge route | Secondary responder | Named incident command and business route | Continuous intake and recurring review | Service catalog, contacts, known errors and runbooks | Only for a verified non-operated experiment |
| Upgrade, dependency and technical-debt ownership | Versioned packages, dependencies or ejected code exist | Release review, impact, regression and backlog remain owned | Operation, change, exit | Technical and product owners | Application engineers, supplier, platform roles | Exact-version review and rehearsal | Recurring maintenance and regression allocation | Second maintainer | Sponsor for deferred risk | Each release window and scheduled debt review | Dependency baseline, upgrade log and debt register | Never while versioned dependencies are operated |
| Licensing, supplier, knowledge, handover and exit | Any external code, supplier, package, service or future transition | Rights, source, data, build, access and knowledge can transfer | Evaluation through exit | Procurement, technical and knowledge or exit owners | Internal custodians, legal reviewer, outgoing and incoming supplier | Document review, independent build and walkthrough | Time and access for recurring handover upkeep | Internal repository and credential custodian | Sponsor and qualified legal route | At procurement, acceptance and recurring transition review | Rights register, source, build, data export and access inventory | Never when an external dependency or transition exists |
Three neutral sourcing patterns
| Pattern | Strengths | Dependencies | Evidence to demand | Transition condition | Failure mode |
|---|---|---|---|---|---|
| Internal-led | Direct context and custody | Internal capacity and specialist gaps | Decision records, reviewed work and backup coverage | Use specialist support when evidence or capacity is missing | Titles hide missing competence or overloaded owners |
| Hybrid | Internal decisions with flexible specialist execution | Clear boundaries, shared tools and coordinated handoffs | One final owner per decision, shared evidence and review access | Rebalance when internal competence or supplier dependency changes | Shared responsibility has no final decision owner |
| Supplier-led with retained internal accountability | Broad external execution and specialist capacity | Contract scope, evidence access, continuity and exit | Internal decision owners, repository and credential custody, independent acceptance | Transfer knowledge and access before service or supplier change | Supplier-only credentials, knowledge, build or production decisions |
Supplier coverage is not ownership transfer
A supplier may perform most technical work. Named internal roles still decide scope, data meaning, access approval, business acceptance, production risk, incident priority, spend, legal terms, and exit. Supplier execution is evidence to inspect, not transferred accountability.
Competency evidence comes from observed work
Use architecture decisions, reviewed code, migration rehearsal, threat and access review, test results, deployment rehearsal, recovery proof, monitoring and incident exercises, exact-version upgrade rehearsal, documentation, and handover walkthroughs. Credentials may add context but do not certify coverage.
AI tools assist work, not accountability
AI assistants, coding agents, generated tests, and repository skills may support analysis, implementation, and documentation. They cannot be accountable owners, approve business acceptance, hold legal duties, accept security risk, command incidents, or replace competent human review and operation.
Evidence gates
| Gate | Required owner and evidence |
|---|---|
| Evaluation approval | Outcome owner, scope assumptions, evidence sources, missing competence and escalation |
| Implementation start | Process, data, architecture, delivery, security and acceptance owners with capacity |
| Production handover | Day-two operator, incident route, recovery proof, release evidence, backup and accepted gaps |
| Ongoing service | Service signals, support capacity, recurring reviews, upgrade owner and current handover artifacts |
| Material change | Impact owner, technical review, regression, security and data decisions, rollback and operating update |
| Supplier exit | Internal decision ownership, source and build, data export, revoked access, knowledge walkthrough and receiving capacity |
Stop or escalate when
- No business outcome owner
- Production credentials are held only by a supplier
- Data meaning, migration or retention decisions are unowned
- No security or access approver
- No test strategy or business acceptance owner
- No day-two application or platform operator
- No incident route or decision priority owner
- No owner for backup and recovery proof
- No upgrade and dependency owner
- No source, reproducible build or handover path
- A critical responsibility depends on one person
- Assigned roles lack confirmed capacity
- Responsibility is shared but no final decision owner exists
Sanitized examples
Smaller hybrid implementation
An internal sponsor and process owner keep scope and acceptance. A supplier performs application and integration work. An internal platform role controls environments and secrets. Gaps remain where recovery has not been rehearsed and the supplier engineer has no named backup. Decision: do not hand over to production until recovery evidence and continuity are recorded.
Supplier-led implementation approaching handover
A supplier performs delivery, tests, and operation setup. Internal data, security, service, spend, legal, and acceptance roles retain decisions. The repository is accessible internally, but the build walkthrough and production credential transfer are incomplete. Decision: keep the exit and production-handover gates open.
Evidence classification and cutoff
Reviewed on 2026-07-14 at the pinned product revision. Product facts come from repository and documentation files. Responsibility mappings are editorial. Actual assignments, capacity, accepted gaps, and service choices are project decisions. Supplier promises are time-sensitive claims requiring contract evidence.
No headcount recommendation, maturity score, certification, or aggregate readiness percentage is produced.
Browser-local planning tool
Responsibility and continuity register
The 18 starter rows mirror the domain matrix. The bounded state can say responsibility map ready for decision review only after every row has the required assignment, evidence, capacity, continuity, and handover fields. It cannot approve a team, system, security posture, or launch.
Privacy: Entries stay in this browser and local exports. Use role labels, not names. Do not enter personal, confidential, security-sensitive, production, or credential data.
Register state
NOT READY FOR DECISION REVIEWOpen information gates: 180
| Domain | Lifecycle | Product or project trigger | Required outcome | Accountable owner | Performer | Sourcing mode | Competency evidence | Capacity evidence | Backup | Escalation | Evidence link or note | Handover artifact | Cadence | Coverage state | Review date | Next action or not-applicable reason |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Executive sponsorship and outcomes | ||||||||||||||||
| Product and process ownership | ||||||||||||||||
| User and adoption ownership | ||||||||||||||||
| Data governance and migration | ||||||||||||||||
| Solution architecture | ||||||||||||||||
| Module and customization design | ||||||||||||||||
| Application development and review | ||||||||||||||||
| API and integration ownership | ||||||||||||||||
| Security, privacy, access and tenancy | ||||||||||||||||
| Platform, environment, secrets and configuration | ||||||||||||||||
| Database, migration, backup and recovery | ||||||||||||||||
| Queues, Redis, workers and scheduled processing | ||||||||||||||||
| Logging, monitoring and observability | ||||||||||||||||
| Test strategy and business acceptance | ||||||||||||||||
| Release, deployment, rollback and change control | ||||||||||||||||
| Service desk and incident response | ||||||||||||||||
| Upgrade, dependency and technical-debt ownership | ||||||||||||||||
| Licensing, supplier, knowledge, handover and exit |
Method, assumptions and limitations
Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.
This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.
Primary source collections: code repository, documentation, public releases.