Core concepts
Test targets
Fix the target version, parameters, and behavioral boundary, then determine whether its interface is suitable for the no-code Evaluation Trigger.
Define the exact model or application you want to test, then keep its version and material parameters fixed during the evaluation. Targets with a simple HTTP request-and-response interface can usually connect through the no-code Evaluation Trigger.
Types of test target
| Target type | What is tested | Trigger fit |
|---|---|---|
| Hosted model | A fixed model version and serving configuration | Good fit when it has a callable inference endpoint |
| Chatbot | The chatbot backend, instructions, retrieval, and filters | Good fit when its API reflects the user-facing behavior |
| AI application | The final response produced by the application | Good fit when one request returns one evaluable response |
Fix the target version and parameters
Record the settings that can change the target response and keep them unchanged for the full run.
| Fix | Record |
|---|---|
| Model version | Provider, model ID, checkpoint, fine-tune, or application release |
| System configuration | System prompt, retrieval or knowledge version, guardrails, and filters |
| Generation parameters | Temperature, top_p, maximum output length, seed, or equivalent settings |
| Connection contract | Target URL, request shape, response path, and session behavior |
Check Evaluation Trigger compatibility
Evaluation Trigger sends each AIDX prompt to the target and extracts the answer without a custom integration script.
| Trigger works when | Requirement |
|---|---|
| The target is reachable | AIDX can call its HTTP endpoint with the supported headers |
| The request is mappable | The prompt can be inserted into a stable request body |
| The response is mappable | One request returns answer text at a stable JSON path |