# Product model (/docs/concepts/product-model)



Invokeable follows one path from product setup to a verified decision:

1. A **product connection** points to an MCP or OpenAPI endpoint.
2. A **product surface** groups related actions, such as Commerce API or Support API.
3. An **action** describes one operation an agent can use.
4. An **agent environment** describes an agent that Invokeable can assess.
5. A **journey** describes a customer task and the result that must be verified.
6. A **test case** varies the conditions, inputs, or recovery path for that journey.
7. A **run** executes one assessment and records its progress.
8. **Evidence** records what the agent did and what the product state showed.
9. A **finding** records a repeatable reliability or safety problem.

## How the objects relate [#how-the-objects-relate]

| Object             | Main question                                                       |
| ------------------ | ------------------------------------------------------------------- |
| Product connection | Where can Invokeable discover and call product actions?             |
| Product surface    | Which product area owns these actions?                              |
| Action             | What can an agent do, and how can the result be checked?            |
| Agent environment  | Which agent is being tested, and what can it support?               |
| Journey            | What customer task should the agent complete?                       |
| Test case          | Which normal, edge, failure, or recovery condition is being tested? |
| Run                | What happened during this assessment attempt?                       |
| Evidence           | What supports the result?                                           |
| Finding            | What product problem should the team address?                       |

## Version history [#version-history]

Invokeable keeps customer-visible and decision-relevant state in the workspace. A run links to the exact journey, test plan, agent environment, and action definitions that were used. Later edits do not rewrite historical results.

This matters when a connection, action, or test plan changes. You can compare a later assessment with the earlier version without losing the context that produced either result.

## One result, several views [#one-result-several-views]

The same assessment can appear in more than one place:

* **Journeys** shows the task and offers the next run action.
* **Findings > Test results** shows the outcome and checks for each run.
* **Findings > Issues to fix** groups repeatable problems into findings.
* **Home** summarizes verified outcomes, blockers, and coverage across the workspace.

These pages show the same saved results from different parts of the workflow. The CLI uses those results too.

## What Invokeable does not treat as proof [#what-invokeable-does-not-treat-as-proof]

* The agent saying that a task succeeded
* A request returning without an error
* A run reaching its last step
* A score without the underlying evidence
* Missing or inaccessible evidence

Invokeable requires observable product state for a positive result. If the state cannot be checked, the result remains unresolved or invalid instead of being counted as a pass.

Continue with [Catalog and actions](/docs/concepts/catalog) or [Assessments and runs](/docs/concepts/assessments).