Extreme Lifecycle

Extreme Lifecycle

When to Use

• Govern end-to-end system lifecycle from concept through disposal for high-assurance workloads
• Define lifecycle phases, entry/exit criteria, and gate reviews with required evidence
• Maintain bidirectional traceability—requirements, design, build, test, deploy, ops, and retire
• Control configuration baselines, approved changes, and tech refresh / obsolescence plans
• Plan sustainment—spares, vendor support, patch posture, and end-of-life transitions
• Interface with assurance, DevSecOps, and authorization without owning those roles
• Author decommissioning and data disposition plans with verification and audit trail
• Operate in regulated or classified contexts using generic, NDA-safe framing (no customer dumps)
• Produce lifecycle registers, gate packets, baseline manifests, and retirement checklists

When NOT to Use

• Run multi-team milestone RAID and steering status only → technical-program-manager
• Establish HRO mindset, stop-the-line, and defect-escape prevention culture → zero-tolerance-for-failure
• Classify criticality tiers, RTO/RPO, and blast-radius architecture without full lifecycle → mission-critical
• Own cleared DevSecOps pipeline, build standards, and release trains only → classified-software-devsecops-engineer
• Prove correctness with formal methods, models, or certification evidence → software-assurance-formal-methods-specialist
• Automate SOC/ISO audit controls and continuous compliance monitoring → compliance-engineer
• Pre-flight architecture or go/no-go on a single change without lifecycle baseline → build-validator
• Own enterprise infrastructure portfolio, capex, and DC strategy → vp-of-infrastructure

Related skills

Core Workflows

1. Scope and lifecycle charter

Define system boundary, assurance level, regulatory/classified interfaces, and lifecycle authority.

See `references/extreme_lifecycle_scope.md`.

2. Phases and gates

Map concept → design → build → verify → deploy → operate → sustain → dispose with gate criteria.

See `references/lifecycle_phases_and_gates.md`.

3. Traceability and evidence

Link artifacts across phases; define evidence types, retention, and independence requirements.

See `references/traceability_and_evidence.md`.

4. Operate, sustain, and obsolescence

Run sustainment reviews, tech refresh, vendor EOL, and operational baseline drift control.

See `references/operate_sustain_and_obsolescence.md`.

5. Change, baseline, and retirement

Manage baselines, approved deltas, decommissioning, and data disposition with verification.

See `references/change_baseline_and_retirement.md`.

6. Stakeholders and assurance interfaces

Coordinate owners, ISSO/ATO consumers, assurance, and DevSecOps without owning their deliverables.

See `references/stakeholders_and_assurance_interfaces.md`.

Outputs

• Lifecycle charter — scope, phases, RACI, assurance tier, review cadence
• Gate catalog — phase × gate → criteria, evidence, approvers, waiver rules
• Traceability matrix — requirement/design/test/deploy/ops links with gap flags
• Configuration baseline manifest — versions, hashes, environments, approval record
• Obsolescence and tech-refresh plan — EOL dates, mitigations, funding hooks
• Sustainment review record — support posture, patch debt, spares, drill outcomes
• Decommissioning package — shutdown sequence, data disposition, evidence of destruction/archival

Principles

• Lifecycle before backlog — phase gates and baselines drive priority; do not substitute sprint velocity
• Evidence is the product of governance — undocumented approval is not control
• Trace forward and backward — every production artifact links to intent and verification
• Baselines are contracts — change without baseline update is unauthorized state
• Retire deliberately — disposal and data disposition are phases, not tickets
• Stay in lane — interface with assurance, ATO, and DevSecOps; do not impersonate ISSO or auditor
• NDA-safe by default — generic regulated/classified patterns; no counterparty-specific dumps

Change, baseline, and retirement

Table of contents

1. Configuration baseline concepts 2. Baseline types 3. Change categories 4. Change authorization workflow 5. Promotion across environments 6. Decommissioning planning 7. Data disposition 8. Retirement verification and closeout

Configuration baseline concepts

A configuration baseline is an identified, approved set of configuration items at a point in time.

Authoritative source: manifest in CM repository—not tribal knowledge.

Baseline types

Align naming with org CM standards; consistency matters more than terminology.

Change categories

Map categories to criticality tier (mission-critical) when available.

Change authorization workflow

Minimum workflow:

1. Request — description, rationale, affected CIs, rollback 2. Impact — traceability, dependents, security/privacy 3. Approve — authority per category and tier 4. Implement — in controlled environments 5. Verify — tests and scans per policy 6. Promote — update manifest; archive prior baseline 7. Communicate — ops, dependents, assurance consumers

Reject changes that lack rollback or baseline update plan.

Promotion across environments

Promotion record links: source tag, target tag, gate ID, approver, timestamp.

Pair build-validator for pre-flight on major promotions—not as substitute for baseline CM.

Decommissioning planning

Start decommissioning plan when dispose phase triggers (see operate_sustain_and_obsolescence.md).

Plan sections:

Data disposition

Classify data generically; execute per organizational policy and legal hold:

Do not specify destruction of data under legal hold—escalate to counsel.

Include:

• Backup and replica retirement
• Key and secret revocation
• SaaS tenant closure
• Log pipeline shutdown

Retirement verification and closeout

Closeout checklist:

• [ ] Production traffic drained; DNS/routes removed
• [ ] Accounts and keys revoked
• [ ] Data disposition completed per plan
• [ ] Final retired baseline archived
• [ ] CMDB status = retired; dependents updated
• [ ] Assurance notified; control inheritance updated (interface)
• [ ] Financial assets and licenses retired (vp-of-infrastructure if shared)
• [ ] Lessons learned captured

Output: retirement certificate signed by system owner and lifecycle sponsor.

Extreme lifecycle scope

Table of contents

1. Purpose and boundaries 2. What “extreme lifecycle” means 3. System boundary and assurance level 4. In scope vs out of scope 5. Lifecycle charter elements 6. Regulated and classified contexts (generic) 7. Deliverables and review cadence

Purpose and boundaries

Extreme lifecycle governance is the discipline of managing a system from concept through retirement when failure, corruption, or unauthorized change has severe impact—mission-critical operations, high assurance, or zero-failure-tolerance environments.

This skill owns phase structure, gates, baselines, traceability, sustainment, and retirement—not:

What “extreme lifecycle” means

Extreme signals that lifecycle decisions are gated, evidenced, and traced—not that every project uses heavyweight waterfall.

Characteristics:

• Phase exit criteria are explicit; skipping phases requires documented waiver
• Configuration baselines are authoritative for what runs in each environment
• Sustainment includes obsolescence, vendor support, and tech refresh—not only uptime
• Retirement includes data disposition and verification of shutdown

Contrast with generic agile: backlogs and sprints implement work inside phases; they do not replace gates or baselines.

System boundary and assurance level

Document in the lifecycle charter:

Pair with mission-critical when tiering and RTO/RPO must align to lifecycle gates.

In scope vs out of scope

Lifecycle charter elements

Minimum charter sections:

1. Executive summary — mission, assurance drivers, lifecycle sponsor 2. Authority — who may approve phase transitions, baselines, and waivers 3. Phase model — see lifecycle_phases_and_gates.md 4. Evidence standards — types, retention, independence → traceability_and_evidence.md 5. Baseline policy — naming, promotion, emergency change → change_baseline_and_retirement.md 6. Sustainment cadence — reviews, EOL triggers → operate_sustain_and_obsolescence.md 7. Retirement triggers — when dispose phase starts 8. RACI — see stakeholders_and_assurance_interfaces.md

Regulated and classified contexts (generic)

Operate NDA-safe:

• Describe control families and authorization interfaces without customer-specific control text
• Use generic clearance / program labels only when the user confirms they may be referenced
• Do not paste export-controlled technical data, schematics, or operational identifiers
• Map lifecycle gates to common patterns (e.g., security assessment before production baseline) without inventing legal obligations

When cleared pipeline mechanics dominate, pair classified-software-devsecops-engineer and keep this skill on lifecycle evidence and baselines.

Deliverables and review cadence

Exit: charter approved by lifecycle sponsor and system owner; peer skills engaged where boundaries apply.

Lifecycle phases and gates

Table of contents

1. Phase model overview 2. Phase definitions 3. Gate structure 4. Gate criteria by phase 5. Waivers and emergency progression 6. Mapping to delivery methods 7. Gate packet checklist

Phase model overview

Standard eight-phase model for extreme lifecycle (adapt names to org glossary):

Concept → Design → Build → Verify → Deploy → Operate → Sustain → Dispose

Each transition crosses a gate with defined entry/exit criteria and evidence.

flowchart LR
  C[Concept] --> D[Design]
  D --> B[Build]
  B --> V[Verify]
  V --> P[Deploy]
  P --> O[Operate]
  O --> S[Sustain]
  S --> X[Dispose]

Phase definitions

Gate structure

Every gate documents:

Independence: for high assurance, builder ≠ sole verifier; separation documented in gate packet.

Gate criteria by phase

Concept → Design (Gate 1)

Exit criteria (examples):

• Approved concept brief and stakeholder sign-off
• Initial criticality/tier alignment (mission-critical if applicable)
• Lifecycle charter draft and sponsor assigned
• Top risks and regulatory/classified interfaces identified (generic)

Design → Build (Gate 2)

• Design baseline frozen under configuration management
• Verification and validation plan linked to requirements
• Security/privacy design review complete (interface to assurance)
• Traceability matrix populated for design elements

Build → Verify (Gate 3)

• Build matches approved design baseline (or approved deltas recorded)
• Component inventory / SBOM available where required
• Static analysis and required DevSecOps gates passed (devsecops interface)
• Known defects logged with disposition

Verify → Deploy (Gate 4)

• Test evidence against acceptance criteria
• Independent assessment or review complete (scope-appropriate)
• Residual risk accepted by authority
• Deployment and rollback procedures approved
• Operations readiness (monitoring, runbooks, on-call)

Deploy → Operate (Gate 5)

• Production baseline established and manifest archived
• Authorization/ATO interfaces satisfied per program (do not author ISSO package here)
• Handoff to operations complete

Operate → Sustain (Gate 6)

• Stable operations period or trigger into formal sustainment (org-defined)
• Sustainment plan active: support contracts, spares, patch cadence

Sustain → Dispose (Gate 7)

• EOL decision recorded; no unmitigated dependents
• Decommissioning plan approved → change_baseline_and_retirement.md

Waivers and emergency progression

Document waivers in the gate register; never informal chat approval for high assurance.

Mapping to delivery methods

Rule: agile cadence does not eliminate baseline promotion or verify before production.

Gate packet checklist

Before scheduling a gate review, confirm:

• [ ] Correct gate ID and phase transition
• [ ] All exit criteria mapped to evidence items
• [ ] Traceability gaps listed with owners
• [ ] Open risks with acceptance or mitigation
• [ ] Baseline version identifiers (config, software, infra-as-code)
• [ ] Approver roster and independence noted
• [ ] Conditions from prior gate closed or explicitly carried

Output: signed gate record stored with retention per traceability_and_evidence.md.

Operate, sustain, and obsolescence

Table of contents

1. Operate phase essentials 2. Operational baseline discipline 3. Sustainment program 4. Obsolescence management 5. Technology refresh 6. Vendor and support lifecycle 7. Sustainment review agenda 8. Triggers to dispose phase

Operate phase essentials

Operate runs the system within the approved production baseline until sustainment or retirement triggers apply.

Pair mission-critical for tier-specific escalation; this skill ensures baseline identity is known during incidents.

Operational baseline discipline

Operational baseline = production configuration as authorized (software, infra, network rules, feature flags, secrets references—not secret values).

Undocumented drift is a lifecycle defect, not only an ops nuisance.

Sustainment program

Sustain extends economic and technical usefulness after initial deploy.

Cadence: quarterly sustainment review minimum for high assurance; monthly for Tier 0 if policy requires.

Obsolescence management

Maintain an obsolescence register:

Categories:

• Software dependency — CVE exposure, unmaintained packages
• Platform — OS, hypervisor, cloud service deprecation
• Hardware — MTBF, spare exhaustion
• People/skills — tacit knowledge, vendor professional services exit

Technology refresh

Tech refresh is a controlled baseline migration—not ad hoc upgrades.

Coordinate with vp-of-infrastructure when refresh spans shared platforms or data center assets.

Vendor and support lifecycle

Do not auto-renew without sustainment review for high-assurance systems.

Sustainment review agenda

Standard agenda (60–90 minutes):

1. Baseline manifest vs drift report 2. Open incidents and repeat failures 3. Patch/CVE posture and exceptions 4. Obsolescence register deltas 5. Upcoming vendor EOL and refresh funding 6. Traceability gaps from last gate 7. Assurance/audit open items (interface only) 8. Decision: continue sustain / accelerate refresh / initiate dispose

Output: sustainment review minutes with actions, owners, dates.

Triggers to dispose phase

Initiate Dispose when any apply (document rationale):

• Vendor EOL with no viable refresh
• Security or compliance posture cannot be remediated within risk appetite
• Mission need ends; system superseded
• Cost of sustainment exceeds value (with executive acceptance)
• Unrecoverable technical debt blocking verification

Hand off to change_baseline_and_retirement.md for decommissioning plan.

Stakeholders and assurance interfaces

Table of contents

1. Stakeholder map 2. RACI for lifecycle governance 3. Assurance and security interfaces 4. DevSecOps interface 5. ISSO and ATO interface (generic) 6. Operations and reliability peers 7. Executive and program interfaces 8. Communication patterns

Stakeholder map

RACI for lifecycle governance

Legend: R = responsible, A = accountable, C = consulted, I = informed.

Adjust for org size; single-person teams must document independence compensations.

Assurance and security interfaces

Lifecycle provides; assurance consumes and assesses:

Do not close assurance findings in lifecycle records without assurance acknowledgment.

DevSecOps interface

Handoff: each production baseline promotion references pipeline run IDs and artifact digests.

Pair classified-software-devsecops-engineer when cleared pipeline rules apply; lifecycle still owns phase gates and baselines.

ISSO and ATO interface (generic)

NDA-safe framing only:

• Map lifecycle gates to authorization boundary milestones (e.g., assessment before production)
• Supply continuous monitoring hooks: baseline change notifications, inventory updates
• Do not author System Security Plans or control implementations as ISSO
• Track ATO conditions as inputs to gate criteria and sustainment reviews

When program is classified, use generic program labels; detailed accreditation → cleared cyber peers.

Operations and reliability peers

Lifecycle defines which baseline was live during incidents and drills.

Executive and program interfaces

Executive brief (quarterly for high assurance): phase status, gate waivers, obsolescence risks, retire candidates.

Communication patterns

Keep communications factual and artifact-linked—avoid status without baseline IDs.

Traceability and evidence

Table of contents

1. Purpose 2. Traceability dimensions 3. Traceability matrix structure 4. Evidence types 5. Independence and integrity 6. Retention and audit trail 7. Gap management 8. Interfaces to assurance and ATO

Purpose

Traceability proves that what runs in production implements approved intent and was verified before promotion.

Evidence is the durable record that gates were satisfied—usable by operations, assurance, and auditors without re-deriving history from chat logs.

Traceability dimensions

Maintain links across (minimum):

Bidirectional: support impact analysis when any downstream artifact changes.

Traceability matrix structure

Example columns (tool-agnostic):

Status values: Proposed, Implemented, Verified, Deployed, Retired, Waived (with waiver ID).

Freeze snapshots: at each gate, export matrix version aligned to baseline tag.

Evidence types

Pair compliance-engineer when evidence must feed automated control monitoring.

Independence and integrity

Do not rely on ticket comments alone as authoritative evidence.

Retention and audit trail

Define per assurance level:

Audit trail includes: who approved, when, which baseline, which environment, superseded versions.

Gap management

Track gaps in a living register; gate reviews summarize open count and trend.

Interfaces to assurance and ATO

This skill does not own ISSO/ATO packages. It supplies:

• Traceability matrix exports
• Gate decision records
• Baseline manifests
• Verification summaries mapped to control interfaces (generic)

Assurance consumers map artifacts to control frameworks; use stakeholders_and_assurance_interfaces.md for RACI.

DevSecOps supplies pipeline evidence (scans, approvals); lifecycle ties pipeline runs to baseline promotion events.