Element Targeting

Copilot and Autopilot both need a reliable way to point at a specific button, field, or row in your UI. ARCY does this by observing your app in production, not by requiring you to annotate your source code. There is no attribute to add and no generated diff to review before ARCY starts working.

How it works

Once ARCYProvider is mounted, the SDK passively watches for clicks, form submits, and page navigation from real end-user sessions. For each interaction, it builds a fingerprint from several signals at once: the element's id, class names, aria-label, visible text, and its position in the page structure.

{ "id": "save-btn", "className": "btn-primary", "ariaLabel": "Save changes", "text": "Save" }

Anything that looks like personal data (an email in a label, a value typed into a field) is masked in your visitor's browser before this event is ever sent. See What ARCY collects.

These events accumulate on ARCY's backend and roll up into a confidence score per element, per page. An AI curation service reads that aggregated, structural-only stream and proposes what a page's sections and elements are, so you get a working knowledge graph without doing anything beyond installing the SDK.

Why fingerprints instead of a single ID

A data-arcy-style single ID breaks the moment you rename a class or restructure a component. A fingerprint degrades gracefully instead: if one signal changes (a class rename after a redesign), the element still resolves through the remaining signals. Only if every signal changes at once does resolution fail, and when it does, ARCY reports that plainly rather than guessing at the wrong element.

Repeated elements are never guessed

A row of identical "Edit" buttons in a table cannot be told apart by signals alone. When ARCY sees multiple equally-good matches on a page and nothing disambiguates them, that element is never made eligible for Autopilot to act on unsupervised, no matter how often it has been seen. This is a hard rule, not a tunable setting: ARCY will fall back to asking (Copilot-style highlight, or a confirmation prompt) rather than risk clicking the wrong row.

Nothing is live just because AI proposed it

AI-curated content lands in a pending state first. It becomes usable by Copilot and Autopilot only once one of two things happens:

• A dashboard admin confirms it through the visual tagger, directly on your own live app, or
• It earns trust through repeated real usage. Every fingerprint has a continuous, decaying confidence score built from how consistently it's seen. Below the threshold, Autopilot falls back to asking for confirmation instead of acting on its own.

Trust is per-element, not all-or-nothing for your whole app: a frequently used "Save" button can become fully trusted quickly, while a rarely used "Cancel subscription" action stays gated behind confirmation for longer, which is deliberate given the cost of getting a rare, consequential action wrong.

What this means day one

A brand-new install has no autocapture history yet, so element-level coverage starts thin and builds as real users interact with your app. arcy analyze gives you working page navigation immediately (see CLI commands) by reading your framework's own route configuration, so a fresh install is never a completely empty knowledge graph, even before any element-level detail exists.

For genuinely low-traffic parts of your product (an advanced settings page, a rarely used flow), coverage stays thin for longer since it depends on usage. If you don't want to wait, hand-author or fix up any route's sections/elements in .arcy/routes/*.yaml yourself, or use the visual tagger to confirm elements directly. Both work exactly like AI-curated or accumulated-trust content once written, since resolution at runtime always happens by fingerprint.

If you have existing data-arcy attributes

Older integrations that still carry data-arcy attributes in the DOM continue to resolve through them; reading is unaffected by this mechanism, only automatic writing is gone. arcy analyze no longer adds new ones. arcy rm cleans up any leftover attributes from before this change.

Related

• AI Modes: how Copilot and Autopilot use resolved elements
• Chat Sources: give Chat extra context beyond the Knowledge Graph, since Chat doesn't use element targeting the way Copilot and Autopilot do
• What ARCY collects: what autocapture sends and how it's masked