Restructure, don't replace
Organisations already run a lifecycle: idea intake, refinement, design review, development, testing, release, operations and decommissioning. ScaledAIOps keeps those stages. It changes what happens inside them so AI can contribute, and adds the controls that keep each contribution owned, checked and recorded.
- Conceivebusiness case
- Planbacklog
- Specifyspecs, ADRs
- Generatecode, IaC
- Verifyreview, evals
- Releasetiered gates
- Operaterun, respond
- Learnadjust
- Retiredecommission
Each stage has one rule in common: AI may propose, draft and analyse, while a named person decides. How far AI may go beyond proposing is set by the work's risk tier.
The nine stages
1. Conceive
- AI contributes
- Market and domain research summaries, option framing, a first-cut business case
- Human decides
- The sponsor accepts the problem, the value hypothesis and the initial risk tier
- Outputs
- Business case, a value hypothesis that can be tested later, initial risk tier
- Restructures
- Idea intake and portfolio triage
2. Plan
- AI contributes
- Backlog drafts, dependency maps, estimate proposals
- Human decides
- The product owner prioritises; the tier is confirmed per epic
- Outputs
- A prioritised backlog in which every item carries a tier
- Restructures
- Roadmapping and refinement
3. Specify
- AI contributes
- User stories, acceptance criteria, API contracts, test cases, architecture options
- Human decides
- The owner approves acceptance criteria and architecture decisions
- Outputs
- Approved specifications; ADRs that record AI involvement and the human decision
- Restructures
- Requirements engineering and design review
4. Generate
- AI contributes
- Code, tests, infrastructure-as-code, configuration, migrations, documentation
- Human decides
- The engineer owns the change: its intent, its correctness and what is submitted
- Outputs
- Changes marked with a vendor-neutral provenance trailer
- Restructures
- Development
5. Verify
- AI contributes
- Pre-review of mechanics, test generation, static-analysis triage, eval runs
- Human decides
- Reviewers as the tier requires, with a specialist at high and critical tiers
- Outputs
- Review record and an evidence bundle linked to the change
- Restructures
- Code review, QA and security testing
6. Release
- AI contributes
- Release notes, change-risk summaries, rollout plans
- Human decides
- Approval by tier: automatic, reviewed, or human-only
- Outputs
- Release record linked to every change and its provenance
- Restructures
- CI/CD and change advisory
7. Operate
- AI contributes
- Alert triage, runbook suggestions, incident summaries
- Human decides
- The incident commander; no autonomous production action above the low tier
- Outputs
- Incident timelines that include every AI action
- Restructures
- Monitoring and incident management
8. Learn
- AI contributes
- Retrospective and post-incident synthesis, metric analysis
- Human decides
- The team agrees changes to delegation, guardrails and context; the value hypothesis from Conceive is tested
- Outputs
- Updated tiers, guardrails and context assets
- Restructures
- Retrospectives and problem management
9. Retire
- AI contributes
- Dependency and usage discovery, decommissioning plans
- Human decides
- The owner approves retirement; access is revoked
- Outputs
- Retirement record; provenance archived
- Restructures
- Decommissioning and access recertification
The element register
An element is anything created, changed, run or retired during delivery. Cradle-to-grave governance means every element, including the ones AI adoption adds, has the same four attributes:
- Owner — a named person accountable for it
- Risk tier — low, medium, high or critical
- Provenance — human, AI-assisted or AI-generated; the context used; who approved it
- State — proposed → approved → active → deprecated → retired
| Element | Examples | Retired when |
|---|
| Business case | Value hypothesis, sponsor decision | Hypothesis tested at Learn; outcome recorded |
| Specification | Stories, acceptance criteria, API contracts, ADRs | Superseded by a newer decision |
| Code and tests | Application code, test suites, migrations | Feature removed; code deleted with its tests |
| Infrastructure | IaC modules, configuration, pipelines | Service decommissioned; resources destroyed |
| Dataset | Test fixtures, reference and evaluation data, data used in context | No consumer left; copies deleted under the retention rule |
| Documentation | Runbooks, user guides, architecture notes | Its subject retires; archived with the provenance record |
| Release | Release records, feature flags, rollout plans | Superseded by a later release; flags removed once fully rolled out |
| Context asset | Prompts, skills, context packs, coding standards for AI | No consumer left, or replaced by a new version |
| Agent or automation | Scheduled agents, bots, AI-driven workflows | Purpose ended; owner leaves without a successor |
| Tool integration | MCP servers, plugins, API connectors | Tool removed from the approved catalogue |
| Non-human identity | Service accounts, tokens and keys used by agents | Its agent or integration retires; failed recertification |
| AI service dependency | A hosted assistant or model API the organisation relies on | Contract ends; exit plan executed |
Start with the elements you already track, such as code, releases and access, and add the AI-specific rows. The register does not need a new system: most of it lives in version control, the service catalogue and identity management.
The AI-aware pipeline
CI/CD gains controls, not stages. Teams keep their pipeline and add these checks:
- Pre-commit — secret scanning; context hygiene, so no secrets or personal data enter prompts or context.
- Build — unchanged.
- Verify — tests and static analysis as today, plus licence and IP checks on generated code, a provenance check that every AI-assisted change is marked, and evals for prompts, agents and AI features.
- Policy gate — policy-as-code maps the change's risk tier to the approvals it needs.
- Release — progressive delivery as today, with the release record linking to provenance.
- Operate and learn — change failure, rework and review burden of AI-assisted changes feed back into tiers and guardrails.
What changes in existing practice
| Practice | Change |
|---|
| Refinement | AI drafts stories and acceptance criteria; the product owner owns acceptance |
| Architecture | AI proposes options; ADRs record AI involvement and the human decision |
| Code review | Risk-tiered; AI pre-reviews mechanics, people review intent and risk |
| Commits | A vendor-neutral trailer marks AI involvement |
| CI/CD | Provenance, licence and eval gates; approvals driven by tier |
| Change management | Low and medium-tier AI-assisted changes become standard changes; high and critical keep full review |
| Identity and access | Agents are non-human identities with least privilege, short-lived credentials and recertification |
| Incident management | AI assists triage; a person commands; AI actions appear in the timeline |
| Decommissioning | Prompts, agents, integrations and credentials are retired like any other asset |