Inspiration

Every QA team maintains hundreds of test cases with steps. Click this. Fill that. Press submit. But when the UI changes — and it always changes — someone has to update all of them. Nobody does. Tests become outdated, teams lose confidence, and regressions slip through.

The problem isn't discipline. The problem is the abstraction.

Step-based test cases turn testers into script-readers. They describe how to click, not what to verify. They duplicate the same "login" flow across fifty test cases. They're written by humans but not natural to humans — because users don't think in steps. They think in goals.

What it does

Telos replaces test cases with a knowledge graph where every node is a user goal — "buy a thing", "leave a review", "return an item" — connected by dependencies.

Each node contains a semantic description: what information is needed, what validation applies, what success looks like. Not UI steps. Business rules.

From this graph, Telos:

  • Generates test coverage automatically via graph traversal — every possible user flow, nothing missed
  • Synthesizes tests on demand via AI — exploratory brief for senior testers, step-by-step for juniors, same node, different format
  • Exports a full test suite as an Excel artifact for release notes and compliance
  • Enables targeted regression — change one node, find all affected flows instantly

The graph is the truth. Tests are ephemeral artifacts generated when needed.

How we built it

Backend: Python + FastAPI + networkx for graph storage and traversal, Anthropic Claude API for AI synthesis

Frontend: React + React Flow for the graph editor, dagre for automatic layout, TipTap for rich semantic node descriptions

AI layer: Each generate request passes the node's goal, semantic description, predecessor nodes, and successor nodes as context. The model synthesizes either an exploratory brief or a step-by-step test case depending on the selected mode.

Challenges we ran into

The hardest design decision was the right level of abstraction for a node. Too granular ("fill email field") and you rebuild the step-based problem. Too broad ("use the app") and the graph loses meaning. The answer was JTBD-thinking: a node is one complete thing a user wants to accomplish, described in terms of information and validation rules — not UI interactions.

Accomplishments we're proud of

The graph traversal generating real coverage paths felt like the moment the concept clicked. It's one thing to say

Built With

Share this project:

Updates