Knowledge Graph
The Knowledge Graph (KG) is Aucert's structured representation of your application. It captures the relationships between screens, user flows, API endpoints, and data models — giving the AI pipeline deep context about your app so it generates meaningful tests, not random interactions.
What the Knowledge Graph captures
| Source | What it extracts | Why it matters |
|---|---|---|
| Application code | Screen definitions, navigation paths, state management patterns | Tells the AI which screens exist and how users move between them |
| API schemas | Endpoints, request/response shapes, authentication flows | Enables testing API-dependent screens with realistic data expectations |
| UI layouts | Screen hierarchy, interactive elements, accessibility labels | Guides the AI on where to tap, swipe, and type during test execution |
| Historical data | Past test results, known bug patterns, regression areas | Prioritizes testing on code areas that have failed before |
| Product requirements | PRDs defining expected behavior and user stories | Ensures tests validate what the product should do, not just what the code does |
How it works
When you run aucert init or aucert run, the ingestion engine parses your app and builds the graph:
- Parsing — The engine reads your source files, extracting screen definitions (Activities, Fragments, Composables for Android), navigation graphs, and API calls
- Schema extraction — OpenAPI specs or Protobuf definitions are parsed to map endpoint relationships and data shapes
- Graph construction — Extracted entities become nodes; relationships become edges. The result is a connected graph of your entire app
- Enrichment — Historical test results and bug patterns are overlaid on the graph, marking high-risk areas and known failure points
Data model
The Knowledge Graph represents your app as nodes (entities) and edges (relationships):
Nodes
Each node represents a distinct entity in your app:
| Node type | Examples | Properties |
|---|---|---|
screen | LoginScreen, HomeScreen, SettingsScreen | route, layout_file, has_form |
component | LoginButton, UserAvatar, SearchBar | type, interactive, accessibility_label |
endpoint | POST /auth/login, GET /users/me | method, path, auth_required |
data_model | User, Product, Order | fields, validation_rules |
Edges
Edges capture how entities relate to each other:
| Relationship | Example | Meaning |
|---|---|---|
navigates_to | HomeScreen → SettingsScreen | User can navigate between these screens |
calls | LoginScreen → POST /auth/login | This screen makes this API call |
depends_on | OrderScreen → User (data model) | This screen requires this data to render |
contains | HomeScreen → SearchBar | This screen contains this component |
How it powers test generation
The graph structure enables the Generation layer to:
- Identify critical paths — Find the most important user flows by traversing high-connectivity nodes (screens with many edges)
- Detect edge cases — Discover unusual state combinations by examining node properties (what happens when
has_form=truebutauth_required=false?) - Prioritize testing — Weight test generation toward nodes marked as high-risk from historical bug data
- Avoid redundancy — Skip testing identical flows that differ only in irrelevant parameters
The Knowledge Graph is stored in PostgreSQL with JSONB columns rather than a dedicated graph database. This provides query flexibility with standard tooling and avoids the operational overhead of Neo4j for the current scale. See the internal docs for details.
What's next
- Architecture overview — Full pipeline architecture
- Device Twin — How Aucert handles emulator-to-device divergence