In plain English
This page explains why testing AI parts one by one is necessary but incomplete. Safe-looking parts can still produce unsafe behavior when combined.
- Why this matters: AI risk can come from the whole arrangement, not one obvious model.
- What to look for: data, memory, routes, adapters, tools, evaluators, updates, and rollback paths.
- Technical version below: the expert terminology remains available and is linked through the glossary.
Composition-Dependent Activation
The reports emphasize a core composition claim: behavior can be absent when each component is tested separately and present only when a specific group is loaded, merged, routed, or sequenced.
What activates the behavior
Activation may depend on base model family, adapter load order, merge coefficients, prompt package, router path, memory state, tool-permission profile, quantization settings, or evaluator versionThe exact version of the evaluator used for a test or release. Open glossary definition. Each variable changes the state space in which a component operates.
Why isolated review misses it
A component certificate answers “how did this artifact behave under this test harness?” A composition question asks “how did this runtime state behave under this route and history?” These are different claims. The first can be true while the second is false.
Required evidence
Composition-aware evidence should include an exact manifest, route coverage, negative controls, tested memory states, evaluatorA system that judges whether an AI output or candidate is acceptable. Open glossary definition version, and UTC timestamp. It should also list material untested combinations rather than implying complete coverage.