Verify native runtime execution
Verifying native runtime execution means keeping intent, scope, acceptance criteria and expected evidence stable while checking the environment's actual context, tools, permissions, execution and resulting change. A configuration file or familiar interface does not by itself prove the required capability.
This is the verification side of runtime adaptation in AI Architect Mastery's AI Driven Development Methodology. It is deeper reference material about realizing the model, not a vendor-specific tutorial or a separate methodology.
What needs verification?
- Context: the current approved artifacts and relevant instructions are actually available.
- Tools: the mechanisms needed for the assignment exist and are usable.
- Permissions: execution is possible inside the authorized boundary.
- Behavior: the requested action produces the intended change, not only a success message.
- Evidence: results apply to the environment and implementation state under review.
Why runtime differences must stay visible
A mapping can preserve role names while failing to preserve permissions or context. Record the runtime and relevant configuration when reporting a verified capability. If support is partial or unavailable, make the limitation explicit instead of weakening the requirement to fit the tool.
Constructed example: tests were proposed, not run
An agent supplies a test command and predicts its output, but the environment did not execute it. That is a proposed verification step, not test evidence. A human can authorize execution in a suitable environment and inspect the actual result before accepting the change.
Bounded claims only
Success for one task in one environment does not establish vendor feature parity or universal adapter support. This page describes what to verify; it is not a tool tutorial, installation guide or claim that a packaged AAM adapter exists.