Product model
Understand the objects that connect a product action to a verified assessment result.
Invokeable follows one path from product setup to a verified decision:
- A product connection points to an MCP or OpenAPI endpoint.
- A product surface groups related actions, such as Commerce API or Support API.
- An action describes one operation an agent can use.
- An agent environment describes an agent that Invokeable can assess.
- A journey describes a customer task and the result that must be verified.
- A test case varies the conditions, inputs, or recovery path for that journey.
- A run executes one assessment and records its progress.
- Evidence records what the agent did and what the product state showed.
- A finding records a repeatable reliability or safety problem.
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
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
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
- 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 or Assessments and runs.