Classification System

The Classification System in ASTA is responsible for identifying the semantic type and characteristics of HTML elements on a page. This allows the agent to understand that a specific <div> is actually a Dialog, or that an <input> is a Checkbox, enabling intelligent interaction and testing.

Overview

ASTA uses a Heuristics Classifier to analyze elements. Unlike simple tag-based selection, the classifier evaluates multiple properties of an element—including its tag name, attributes, CSS classes, and ARIA roles—against a prioritized set of rules.

The output of the classification process is:

1. Primary Type: The specific component type (e.g., Button, Input, Dialog) that determines how the agent interacts with the element.
2. Classifications List: A full list of all matching classification tags (e.g., ['button', 'submit', 'visible']), providing rich metadata.

How It Works

The classifier works by evaluating a comprehensive list of rules against every element on the page.

1. Rule Evaluation: The system iterates through a prioritized list of rules.
2. Matching: Each rule checks if the element matches specific criteria, such as having a certain class name, attribute, or ARIA role.
3. Collection: When a rule matches, its classification tag is added to the element's profile. An element can have multiple classifications.
4. Primary Type Determination: The system determines the element's Primary Type based on the first valid classification found in the priority list.

"First Valid Type Wins" Strategy

The order of rules is critical. The system uses a "First Valid Type Wins" strategy. This means that if an element matches multiple rules, the one with the highest priority determines its primary behavior.

For example:

• A generic rule might match a <div> and classify it as a generic container.
• A more specific rule might match role="dialog" on the same element and classify it as a Dialog.

If the "Dialog" rule is higher priority (or if the generic container classification doesn't map to a specific interactive component), the element is correctly identified as a Dialog.

Classification Rules

Each rule in the system defines:

• Classification: The tag to apply (e.g., "Text Input").
• Criteria: The conditions to match, such as tag names, CSS classes, attributes, or roles.

Why Multiple Rules for the Same Classification?

You will often see multiple rules targeting the same classification (e.g., multiple ways to identify a "Button"). This is intentional and necessary for robust web automation:

1. Diverse Implementation Patterns: Developers build UI components in many ways. A button might be:

   • A standard <button> tag.
   • An <input> with type="button".
   • A <div> with role="button".
   • An <a> tag styled as a button. We need separate rules to catch all these variations.

2. Specificity & Priority:

   • High-Confidence Rules: We prioritize explicit indicators like role="dialog" or type="submit".
   • Heuristic/Fuzzy Rules: We also have fallback rules that look for keywords (like "popup" or "save") in IDs or class names. These are used when standard attributes are missing.

3. Contextual Metadata:

   • Some rules exist just to add metadata, not to set the type.
   • For example, a rule might identify that a button is a "Submit" button. This doesn't change it from being a Button, but it gives the agent extra context that clicking it will likely submit a form.

Key Classifications

• Interactive: Button, Text Input, Checkbox, Radio Button, Dropdown, Link.
• Structural: Dialog, Header, Footer, Navigation, Form.
• Informational: Alert, Error Message, Heading, Data Table.
• State: Invalid, Hidden, Empty (these are usually secondary classifications that add context).

Custom Classifications

While ASTA comes with a comprehensive set of system rules, every application is unique. You can create Classification Assets to define custom rules specific to your application's components.

Classification Assets

A Classification Asset is a user-defined rule set. You can create these in the Assets section of the ASTA Companion.

When you create a Classification Asset, you define the rules using a JSON format. This allows you to target elements that the system classifier might miss or misclassify.

Rule Format

Custom rules are defined as a JSON array of rule objects. Each object must have a classification string and a criteria object.

[
	{
		"classification": "primary_button",
		"criteria": {
			"tagName": "div",
			"classes": ["custom-btn", "primary"],
			"attributes": [{ "key": "data-role", "value": "action-button" }]
		}
	}
]

Criteria Reference

The criteria object supports several properties for matching elements:

Attribute Matching

The attributes array allows flexible matching:

• Presence check: { "key": "data-testid" } matches any element with that attribute
• Exact value: { "key": "type", "value": "submit" } matches exact value
• Regex pattern: { "key": "class", "value": "/btn-.*primary/i" } matches pattern

Page Classification

You can also classify entire pages based on URL patterns or meta tags:

[
	{
		"classification": "login_page",
		"criteria": {
			"url": {
				"path": "/login|/signin/i"
			}
		}
	},
	{
		"classification": "product_page",
		"criteria": {
			"metaTags": [{ "key": "og:type", "value": "product" }]
		}
	}
]

Priority Logic

ASTA applies rules in a specific order to determine an element's classification. Custom rules always take precedence over system rules.

The priority hierarchy is:

1. Variant Level: Rules defined for a specific version/variant of your app.
2. Application Level: Rules defined for your entire application.
3. Workspace Level: Rules shared across your workspace.
4. System Level: The built-in rules provided by ASTA.

This means if you define a custom rule that classifies a specific <div> as a "Button", it will override any system rule that might have classified it as a generic container. This allows you to "teach" the agent how to understand your specific UI library or design system.