intellimetrics Learning
Cloud Modernization Patterns Module 5 · Modernize With AI

Owning What AI Builds

Last reviewed

Intermediate

What you'll learn

~20 min
  • Name the orphaned-app failure mode and price sustainment before building
  • Stand up an ownership registry with the four fields that keep a fleet honest
  • Treat retirement as a first-class disposition with dates, not an aspiration

The failure mode cheap building invented

Eighteen months after Meridian’s modernization “finishes,” a security scan flags a vulnerable dependency in outage-brief-generator — a tidy little internal app that formats storm reports. Nobody on the current team has heard of it. The engineer who prompted it into existence left in the spring. It has real users, a real database, and no owner, no pipeline, and no patch since creation.

This is the orphaned custom app, and it is the signature failure mode of the AI era: when building costs an afternoon, apps appear at the rate of afternoons. The 2025-era enthusiasm said “maintenance simplifies — just regenerate the app when it needs changing.” That claim did not survive contact: regeneration produces a new app that must be re-validated, re-integrated, and re-accredited (Module 4 does not care how the code was produced), while patching, dependency hygiene, and ownership transfer remained exactly as unsimplified as ever. Cheap to create became expensive to own, at fleet scale.

Price sustainment at birth

Lesson 1.3’s disposition framework already contains the antidote — it prices sustainment as an explicit attribute rather than assuming it away. The AI-era move is applying that discipline downward, to every internal tool, not just flagship systems. Before anything AI-built reaches real users, it answers four questions:

1. OWNER:    which team (not which person) answers for this in 18 months?
2. RUNWAY:   what keeps it patched - whose pipeline, whose dependency updates?
3. TRIGGER:  what usage/criticality threshold promotes it to full Module-4
             treatment (hardening checklist, test matrix, real reviews)?
4. RETIRE:   what condition or date turns it off - and who checks?

No acceptable answers, no deployment to shared users. That is not bureaucracy; it is the same fail-closed instinct as Module 3’s contract drift — the cost of the loud stop at birth is an hour, the cost of the quiet orphan is an incident with your name nowhere near it.

The ownership registry

The four answers live in a registry — a flat, boring, machine-readable file per app, aggregated into the fleet view:

fleet/outage-brief-generator.yaml
app: outage-brief-generator
owner: field-ops-tools          # a team channel, never a person
created: 2026-04-12
tier: convenience               # convenience | supported | critical
pipeline: shared-internal-ci    # what patches it
dependencies_policy: monthly-auto-pr
promotion_trigger: ">25 weekly users or any SLA-relevant use"
retire_when: "storm-report workflow absorbed into FieldDesk (target 2027-Q2)"
last_reviewed: 2026-08-22

The registry is what your AI CLI audits: “list every fleet entry with a departed owner-team, a missed review date, or dependencies older than the policy allows” is a one-prompt health check. The registry also feeds Lesson 5.1’s standing assessment — the fleet is part of the estate now, and it gets inventoried like one.

And take the tier field seriously in both directions. A convenience-tier app gets a lighter regime on purpose — monthly automated dependency PRs and an owner, not the full test matrix. The registry’s job is making the tier an explicit, reviewed decision instead of an accident of who built it on which afternoon.

Review capacity is the fleet’s real budget

Lesson 5.2 rationed human review within one port. Fleet-wide, the same arithmetic governs everything: when code is cheap, the scarce resource is qualified attention. Budget it like the finite thing it is:

  • The registry’s tier decides review depth — critical gets Module 4 rigor, convenience gets the harness and sampling
  • Auth, money, and data-write paths get human eyes at every tier (Lesson 5.2’s rule, fleet-wide)
  • A team that cannot staff reviews for a new app at its declared tier does not get the app yet — the constraint is honest, the alternative is fictional review

Retire is a date, not a vibe

The estate-after table in Lesson 4.3 celebrated what got built. The column programs skip is what got turned off — and a modernization that never decommissions pays double run cost, double patch surface, and double audit scope indefinitely. Two disciplines close the loop:

  • Every registry entry carries retire_when, and the standing assessment flags entries whose condition has arrived
  • The old system’s shutdown is a roadmap phase with an owner and a date (Lesson 1.4 treatment), not a someday — Meridian’s file-share feeds, the legacy FieldDesk, and the Access jungle each get one
KNOWLEDGE CHECK

A field supervisor asks for a small AI-built tool to track crew certifications. It would take an afternoon to build. Per this lesson, what has to exist before it ships to the crew?

Key takeaway

Cheap creation without ownership manufactures orphans at AI speed. Price sustainment at birth with four questions, keep the answers in a registry your AI can audit, budget human review as the scarce resource it is, and give every app — and every legacy system — a retire condition someone actually checks. FieldDesk’s own origin story (Lesson 1.1) was an unowned stopgap that became load-bearing; the registry is how Meridian avoids collecting ten more.

Search lessons