Freeze a common workload
Start with one CRUD fixture and one source revision. In both models, use the same data shape, integration boundary, named operator, reviewer, and recovery scenario. Do not compare a platform document on one side with a live production result on the other.
| Ownership question | Evidence required in both models |
|---|---|
| Artifact identity | What is operated, where is its identifier, and who can retrieve it? |
| Change authority | Who can change, review, and promote the fixture? |
| Data and credentials | Where do records, files, secrets, and integration calls travel? |
| Upgrade duty | Who sees, tests, and decides about component or runtime changes? |
| Recovery boundary | What returns an application definition, and what restores business data? |
| Exit evidence | What can a second operator retrieve, reproduce, or reimplement? |
An answer of not observed is valid and useful. It tells the team which evidence must exist before it can choose a model. It is not evidence that the other model is stronger.
Separate flexibility from operating responsibility
The two models can present different artifact and operating boundaries, but the method assumes neither is adequate until the fixture supplies the required evidence. A managed internal-app platform can document controls, but that does not establish how the chosen account is configured or which responsibilities remain with the customer. The matrix keeps those questions separate.
For a broader framing, see maintenance ownership across app models. An internal-app platform exit drill asks for proof that a second operator can act, and the promotion and rollback method keeps application rollback distinct from data recovery.
Stop condition
Do not call either model cheaper, more secure, more portable, easier to maintain, or more owned until every row is supported by equivalent observed evidence. If the common fixture, named role, or recovery test is unavailable, the proper comparison result is unknown pending evidence.
Does source code ownership settle the exit question?
No. An exit needs retrievable artifacts, documented dependencies, data and credential boundaries, recovery evidence, and a second-operator procedure.