MOD / DOMAIN

Architecture research / 2026

Modernize
Domain Architecture

Where does the product live when stable modernization knowledge becomes portable, typed, and executable?

Hypothesis

Modernize combines portable application knowledge with an opinionated Azure-target path.

WORKING MODEL
  1. 01 Community knowledge
  2. 02 Provider knowledge
  3. 03 Organization policy
  4. 04 User intent
  5. 05 Modernization harness
  6. 06 LLM at ambiguity
  7. 07 Deterministic validation
Follow the evidence

01 / The investigation

The first surprise was not the model. It was the machinery around it.

Observed in notes

The supplied PhotoAlbum research records 28 typed AppCAT incidents. The raw report is not present here, so this remains a recorded observation rather than independently inspectable run evidence.

02 / Separate the layers

One system. Seven different kinds of authority.

Collapsing these layers into “the AI” hides ownership, policy, provenance, and product value.

01

Community

Java, .NET, Spring, Jakarta, compatibility

ecosystem
02

Provider

Azure, AWS, GCP mappings and constraints

provider
03

Organization

Architecture, security, compliance, exceptions

enterprise
04

User

Goal, preferences, explicit target, tradeoffs

operator
05

Harness

State, DAG, approval, execution, retry, provenance

product
06

LLM

Ambiguity, unsupported cases, explanation, synthesis

model
07

Validation

Builds, tests, policies, deployment checks

tools
“The agent is a client of the domain. It does not own the domain.”

03 / Where does Azure enter?

Deployment is late. Deployment intent is early.

04 / Portable domain packages

Compile stable expertise into a substrate any harness can call.

communityjava
communityspring
communitydotnet
microsoftazure
awsaws
googlegcp
organizationacme-policy

PACKAGE CONTRACT / PROPOSED

  • typed observations
  • rules + constraints
  • legal transitions
  • executable transforms
  • knowledge + edge cases
  • validators + tests

MCP may expose the port. It is not the knowledge model.

05 / Product value after separation

Portable knowledge does not make the product disappear.

May become portable

  • language facts
  • framework rules
  • compatibility constraints
  • known transformations
  • validators

May remain differentiated

  • provider expertise
  • integration quality
  • orchestration + approvals
  • validation + repair
  • enterprise UX + trust
  • operational learning

Hypothesis This allocation of product value is a research target, not a result.

06 / The experiment

Hold the application still. Change only the intent.

CONTROL same app

same commit
same tool versions
clean state

  1. ALanguage/framework upgrade only
  2. BModernize, no cloud target
  3. CCloud, provider unspecified
  4. DAzure
  5. EExplicitly provider-neutral
  6. FAWS
  7. GPreserve current hosting
promptassessmentplantasksskillsdiffvalidationrepair
Evidence status 0 / 7 runs captured

Null is a valid research result. The repository does not invent evidence.

07 / Current boundary

Shrink the surface that needs generative reasoning. Keep the uncertainty visible.

Encode what is stable, repeated, testable, and valuable enough to maintain.

Use models where intent is incomplete, context changes the answer, or no supported transform exists.

Attach provenance so another human or agent can ask: why do we believe this?

Read current state → Inspect architecture → Open claims JSON →