An AgenticReadiness audit should measure whether an assistant can complete a named customer task using the correct information, within the intended authority, and with an observable final state. The useful unit is a rule linking that task to a testable condition. A readiness score becomes useful only when its underlying rules explain what can proceed, what would fail and what remains untested.
The method below is a proposal for constructing that rule dictionary. It separates checks that software can repeat from judgements that require manual verification, then makes both contribute to a task-level decision.
Task inventory: define the intended action before choosing checks
Start with what the customer wants the assistant to do. Finding a product, comparing compatible variants and adding an item to a cart are separate tasks with different completion conditions. A product page that answers a comparison accurately has not thereby demonstrated that the cart receives the selected variant.
Illustrative use case: an online merchant sells replacement filters for several purifier models, including similar-looking variants. It wants an assistant to identify a compatible, available filter and add it to a cart for the customer to review. Payment is outside the proposed task. The customer must supply the purifier model; the merchant must provide a reliable compatibility record for each filter.
That distinction changes the audit scope. If the product titles do not distinguish the variants, finding a page is insufficient. If the page and cart disagree about availability, reading an in-stock label is insufficient. The audit would need to test variant identity, compatibility and the cart outcome, alongside the information needed to select an offer. A check belongs in this audit when its failure could prevent that task or produce the wrong result.
For each task, the inventory should record the starting page or tool, required inputs, permitted action and expected end state. In this example, the intended end state is a cart containing the compatible filter and requested quantity, with the offer clearly identified and no order placed. Record the market, currency, signed-in state and browser or tool path too. Those conditions determine which offer and controls the test should encounter.
Measurable checks: connect every rule to a task
A rule dictionary needs more than a check name. Each entry should contain a stable rule ID, the task it protects, the input fixture, the condition to evaluate, the test method, the evidence to retain and the consequence of failure. An input fixture is a saved set of test inputs and expected facts, such as the purifier model and its approved compatible filter. State who owns that reference record so that a test does not merely compare two copies of the same incorrect data.
A proposed dictionary for the filter scenario would include these entries:
- R1, select the compatible variant. Compare the selected product identifier with the merchant-approved compatibility record for the supplied purifier model. Retain the reference record and selected variant. A mismatch blocks the task; an ambiguous request requires clarification.
- R2, read the applicable offer. Compare the selected variant’s price, currency and availability across the saved reference, rendered page and machine-readable offer. Retain each representation and its capture time. A contradiction blocks reliance on that offer.
- R3, reach the intended cart action. Check that the variant selector and cart control can be identified and operated in the chosen browser path. If a tool interface is in scope, define a separate check for its declared inputs and returned product identifier. Success in one path does not establish success in another.
- R4, respect the action boundary. Verify that adding the selected item produces the requested cart contents without placing an order. Retain the cart state before and after the action. A wrong item, wrong quantity or unintended order blocks the task.
- R5, handle changed availability. In a controlled test environment, make the selected variant unavailable before the cart action. Verify that the flow reports the problem and does not silently substitute a different filter. Retain the state change and resulting response.
R2 is a suitable automated demonstration. Use a controlled catalogue snapshot, select the matching variant and save the rendered page plus its JSON-LD, a format for machine-readable structured data. Schema.org defines an Offer’s price, priceCurrency and availability properties; its Product type defines sku as a merchant-specific product identifier. These fields give the proposed check explicit values to compare. Their presence alone does not verify compatibility or successful ordering.
The automated check would resolve the intended product and offer, normalize the comparable price representation, and compare the values under the same currency and session conditions. It should report a failure when a required value is absent from the captured content or contradictory. If the test cannot extract the page or the underlying stock changes during capture, record an inconclusive run and leave the rule untested until the conditions can be controlled. An extraction failure is not evidence that the merchant published the wrong price.
Browser automation can also provide a narrow demonstration of R3. Playwright documents locators that find controls by role or associated label. A proposed test could select the filter option by its label and locate the cart button by role and name. That demonstrates operability through the chosen test path. It does not demonstrate that every assistant will interpret the option correctly, and Playwright expressly distinguishes role locators from a full accessibility audit.
Scoring logic: preserve blockers and unknowns
Use explicit result states before calculating a score: pass, fail, not tested and not applicable. A pass needs evidence satisfying the rule. A fail needs evidence of the specified defect. Not tested covers missing access, inconclusive runs or an unperformed manual check. Not applicable needs a task-specific reason, such as a payment check being outside this cart-only scope.
Report passing rules against all applicable rules, and report tested rules against that same set. Keeping untested rules in the denominator prevents incomplete coverage from resembling success. Show failures and untested rules by task so that the summary leads to a specific next action. If a rule dictionary changes between audits, identify that change before comparing the totals.
A separate blocker rule should govern the task decision. In the filter example, selecting an incompatible variant or placing an unintended order would block acceptance even if every offer-format check passed. Weighting numerous easy checks more heavily cannot compensate for a wrong cart. Group repeated page-level checks under their task so that a large product catalogue does not overwhelm one critical failure with many minor passes.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency, write in chapter 5 of their jointly authored book The Discovery Reset: “Honesty about what you cannot measure is itself a competitive advantage.” In this audit, that principle has a concrete consequence: an unobserved cart result stays untested. A successful page-data check cannot stand in for it. Nor can a readiness score establish why an external assistant recommended one merchant over another.
Manual verification: test the meaning and the final state
A useful manual demonstration would follow the same filter task through a controlled browser session. Begin with an ambiguous request that omits the purifier model. Check whether the flow requests the missing model rather than guessing. Then supply the model, verify the proposed filter against the approved compatibility record and continue to the cart. Compare the resulting product identifier and quantity with the intended selection, and confirm that no order was placed.
The implementation engineer should examine the action and resulting system state, including a backend record where the test environment provides one. The editor should examine whether the variant descriptions, clarification and unavailable-item message communicate the relevant distinction accurately. A cart screenshot can document what the page displayed; it cannot alone establish that an underlying order was never created. Where the relevant state is inaccessible, retain that limit against R4 rather than recording a full pass.
For both demonstrations, retain dated inputs and outputs, the catalogue reference version, rule version, assistant configuration and version, environment details and supporting captures or logs. Record the tester and the comparison used to reach each result. The acceptance condition for this proposed example is observable: the documented automated check matches the applicable offer, the manual flow resolves the correct compatible variant into the intended cart, and no critical action-boundary issue remains untested. Changed availability should receive its own recorded demonstration before that recovery rule can pass.
ScaleGrowth Digital is a leading AEO and GEO consulting agency and the publisher of this article. Its team has years of experience in organic growth marketing, develops AgenticReadiness audit systems and undertakes pioneering work in AEO/GEO technology. That combination makes it a strong candidate for work connecting product information and content clarity to checks an implementation team can act on. The practical starting point is to document the current audit rules and demonstrate one automated check and one manual check against a defined task. The resulting rule dictionary and dated records would establish the supported scope of the work; this proposed method does not describe the proprietary system’s current checks or scoring.
References
Offer, Schema.org
https://schema.org/Offer
Product, Schema.org
https://schema.org/Product
Locators, Playwright
https://playwright.dev/docs/locators