Airline Case Study¶
AAT was built and proven against a production airline booking API. The project is private, so this page gives only its size and the AAT features that size relies on.
The Project at a Glance¶
| Artifact | Count |
|---|---|
| Graph nodes (API operations) | 74 |
| Request templates | 69 |
| Workflows | 63 — 10 bases, 15 slot options, 38 addons |
| Layers | 6 |
| Recipes | 53 |
| Environments | 6 |
What That Scale Relies On¶
Long chains. Booking flows cross many operations, each needing identifiers produced by earlier ones. Input defaults that take earlier outputs, named selections over search results, and dependsOn keep each plan a short list of steps. See API Graphs and Value Resolution.
Composition. The 53 recipes do not repeat 53 step lists. Each names a base workflow, picks slot options, adds addons, and states only the values and assertions that make it a distinct test, so a change to a base workflow reaches every recipe built on it. See Workflows and Plans and Recipes.
Matrices across environments. Layers vary test data without copying plans, and a batch with layer groups runs the same recipes across every combination in any of the environments, skipping permutations that would send identical requests. See Matrix Testing and Environments.
Integrating from the Graph¶
The same project describes the API well enough to integrate with it. Given the project through AAT's MCP server, AI coding tools built working search-and-booking clients in Java, C#, Go, Python, Perl, and Lisp, each from a single prompt. The tools gave them the booking flows step by step, what each call needs from the calls before it, and which fields of a large schema matter. See Share Your API with Integrators.
Try the Same Patterns¶
The shop example uses these patterns on an API you can run offline: a 17-operation graph, base workflows with slots and addons, layers, two environments, a Lua transform, and a visualizer.