Appendix F — Configuring MAGE Across the Product Lifecycle

F.4 Product Management & Maintenance

Engineering question. What change are we asking for, and why?

Many software organizations already possess a lightweight modeling substrate without calling it one: the ticketing system. A structured ticket can preserve desired behavior, rationale, acceptance criteria, affected concepts, constraints, related changes, and prior decisions. When it carries enough information to reason about one requested change, it functions as a purposeful change-scoped model. It need not duplicate longer-lived models; it should connect the episode to the product and system knowledge that governs it.

The change-scoped nature of the ticket matters. A ticket written in 2022 need not describe the product in 2026, but it can remain an accurate representation of the intent governing the 2022 change. Its persistence is then useful history rather than a synchronization burden. Maintenance uses the same pattern: an issue can preserve the discrepancy, intended correction, rationale, and acceptance evidence.

For many tickets, however, specifying the requested outcome is not the difficult part. The difficult part is diagnosis: determining why the observed behavior occurs, locating the responsible concepts and components, and identifying the system models and obligations that govern a correct change. This is especially apparent in defect repair, where root-cause analysis may dominate the work. MAGE's bidirectional traceability between models and implementation reduces that search problem. An observation in the realized system can be traced from code to the relevant architectural, behavioral, ownership, or other system models; reasoning over those models can in turn identify the implementation that realizes them. The ticket can therefore become a point of entry into the governed engineering environment rather than a standalone description from which an agent must reconstruct the system.

A ticket also reopens a particular region of the product to choice. Existing intent, architecture, contracts, and acceptance machinery may already settle most consequential questions, leaving an agent only implementation choices. Other changes expand the realization surface, expose a tacit obligation, or require new design judgment. Maintenance therefore does not simply consume a fixed stock of degrees of freedom; each change encounters and may alter the choice space defined by current obligations.

Figure F.4-1 brings these relationships together.

Change-scoped models, degrees of freedom, and inheritance A change model (ticket or issue) and longer-lived system knowledge both feed diagnosis and context localization, connected by bidirectional traceability between models and code. Diagnosis establishes the realization space — the choices the governing obligations leave open — within which the agent realizes the change. Realization produces acceptance evidence. A recurring-lesson judgment then routes the episode either to history or, through governance conversion, into durable structure that future work inherits. CHANGE MODEL ticket / issue observation · intent SYSTEM KNOWLEDGE architecture · behavior · ownership contracts · dependencies · … DIAGNOSIS & CONTEXT LOCALIZATION root cause · responsible concepts relevant models · obligations bidirectional traceability models ↔ code REALIZATION SPACE choices left open by governing obligations agent realizes realization acceptance evidence recurring lesson? no yes history DURABLE STRUCTURE model · test · constraint validator · architecture · design future work inherits it
Figure F.4-1. Change-scoped models, degrees of freedom, and inheritance. A ticket or issue provides an entry point into a change episode. Bidirectional traceability helps locate the responsible implementation and the models and obligations that govern it. Those inherited obligations bound the realization space while leaving some choices open. Acceptance evidence establishes whether the realized change satisfies its obligations; recurring or consequential lessons can then be converted into durable structure that future work inherits.

Maintenance is not inherently more automatable than new engineering; its advantage is inheritance. A mature product may already provide the models, obligations, evidence machinery, traceability, and prior decisions that settle questions a greenfield change must answer. When they cover the requested change, realization becomes cheaper. When the ticket exposes a missing capability, tacit obligation, architectural conflict, or new design question, judgment returns.

Ticketing is an accessible MAGE surface because many organizations already preserve change-scoped intent. The useful move is not to enrich every ticket, but to connect consequential change intent to the longer-lived knowledge and evidence needed to govern the change.

MAGE profile.

© James C. Davis, 2026–present