Modernization¶
Modernizing safety-critical software, on one page. Select the image to open it at full size.
Reading the infographic against this site
- Its agent hierarchy — a Modernization Director over understanding and transformation agents — is the mature target, not a starting configuration. Start with one agent per work item and grow along the maturity path.
- Single writer per task/branch is the isolation rule. Ownership adds a second, independent one: single writer per domain.
- Its modernization control plane includes the reasoning agents. On this site, control plane means only the deterministic layer — see Vocabulary.
Software modernization is where everything on this site converges. Complex, long-lived, safety-critical software typically combines accumulated legacy complexity, insufficient or outdated tests, tightly coupled architecture, lost or implicit domain knowledge, vulnerabilities in code and dependencies, the need to move features between code bases — and strict regulatory requirements such as IEC 62304 and ISO 14971, with clinical behaviour and performance that must not change. The result is high cost, high risk and slow delivery.
A platform, not a product¶
A generic Software Modernization Agent probably shouldn't be the product. The product is better thought of as a Software Modernization Agent Platform: reusable modernization capabilities layered over a persistent software and domain knowledge model.
Test automation, modularization, domain recovery, vulnerability removal and cross-product feature migration then become different workflows over the same underlying machinery.
Capabilities, not agents¶
The capabilities I would develop fall into five groups:
| Understand | Verify | Transform | Migrate | Assure |
|---|---|---|---|---|
| repository discovery | test discovery | refactoring | feature identification | security analysis |
| architecture recovery | test generation | modularization | dependency extraction | static analysis |
| dependency analysis | characterization testing | API migration | behaviour specification | compliance evidence |
| domain concept extraction | coverage analysis | dependency upgrades | source/target gap analysis | traceability |
| requirement tracing | regression detection | language / framework migration | implementation | change-impact analysis |
| technical-debt analysis | differential testing | vulnerability remediation | equivalence verification |
Notice that these aren't individual agents. They are capabilities that agents compose — the same way the runtime composes tools into roles. A workflow is a DAG over them.
Small, verifiable steps — never free-running¶
Every modernization workflow has the same inner rhythm:
Never ask an agent to "modernize subsystem X." Ask it to perform small, verifiable transformations, each one a small change set with its own evidence.
What stays outside the generic agent¶
There is an important boundary. Don't attempt to encode:
GenericAgent.modernizeAnything()
Instead, make the machinery generic and plug the domain in:
| Generic — the platform | Domain-specific — plugged in |
|---|---|
| planning | domain ontology (e.g. ultrasound, product family) |
| tool invocation | capabilities and tooling (e.g. C++ toolchains) |
| task representation | modernization policies: allowed, requires approval, forbidden |
| knowledge retrieval | domain knowledge, product architecture, requirements database |
| sandboxing, permissions | regulatory rules (e.g. IEC 62304) |
| memory | |
| verification | verification strategies (e.g. pixel-level equivalence, SNR, latency; hardware simulators) |
| coordination, observability | regulatory evidence rules, specific to device and market |
| human approval |
For medical imaging, that composition looks like:
Change those plug-ins and the same platform could modernize automotive software.
Regulatory evidence as a by-product¶
Because every change set already carries its validation evidence and every claim its provenance, the platform can assemble regulatory evidence as it works rather than after the fact: code changes and their rationale, affected requirements, risks and architecture, test changes and results, dependency changes, security impact, and the traceability between them — aligned with IEC 62304 (software lifecycle), ISO 14971 (risk management) and FDA cybersecurity guidance.
The deepest opportunity
The deepest opportunity isn't code generation. It's an AI-maintained semantic model of the product that enables safe, continuous, evidence-backed evolution.
Pages in this section¶
- Workflows — characterization, feature migration, vulnerability remediation, architecture recovery
- Maturity Path — the order in which to build all of this