Frequently Asked Questions

The ASG Directory is a public business discovery system that organizes published business records, services, products, locations, public agent capabilities and machine-readable profile information. It is designed for people, developers, search systems and compatible AI agents.

Visitors can search the public Directory, business owners can claim or correct appropriate records, developers can use supported public read APIs, and compatible AI systems can consume public machine-readable profile data.

Yes. Public search, public profile viewing and supported public read endpoints can be used without purchasing a business plan.

A business can begin with the public submission or claim workflow without a paid plan. Optional services, agentic capabilities or commercial products can remain separate from the free public Directory record.

A record can be discovered from public information, submitted by a business, or connected through supported WebsDocs or ASG systems. The listing origin is separate from registry verification, owner control and Directory Score.

A discovered listing is a public business record created from information the Directory identified from public sources. Discovery does not mean the business owner has claimed the profile, and it does not automatically mean the business is registry verified.

A published listing is a record available through the public Directory. Publication controls public visibility. It is independent from owner claim status, business registry verification and optional paid services.

A claimed listing is a profile for which an owner or authorized representative has entered the ownership-control workflow. Claiming is about profile control. It is not the same thing as verifying that the legal business exists in an external registry.

Yes. The Directory can publish a discovered business record before an owner registers or claims it. This allows public business discovery to grow independently from owner onboarding.

They answer different questions. Discovery asks whether a public business record can be identified. Business Registry Verification asks whether supported registry evidence matches the business. Claim and owner verification ask whether a person or account controls the Directory profile.

The Directory Score is a public-data quality and readiness indicator. It can reflect completeness, evidence strength, freshness and supported public discovery signals. It is separate from Business Registry Verification.

No. A high Directory Score can indicate a strong public profile even when registry verification is still pending. Registry verification has its own status, level and evidence fields.

Registry evidence can contribute to the overall strength of a public record where the scoring model uses it, but the two concepts remain separate. The Directory should be able to explain both the record quality and the registry-verification state independently.

Recently added refers to businesses that were newly published or introduced into the public Directory within a recent period. It is a publication and discovery signal, not a registry-verification badge.

Appropriate users can submit correction or removal requests. The Directory can also refresh records when newer public evidence becomes available. Registry verification does not prevent a legitimate correction, review or removal workflow.

The ASG Directory Discovery Engine is the crawlable country-and-category publishing layer of the Directory. It organizes eligible public profiles into canonical discovery collections that people, search engines, crawlers and compatible AI systems can browse. It complements the live Directory explorer rather than replacing it.

Directory search is an interactive way to find a specific business, service, product, location or AI-ready profile. The Discovery Engine publishes stable country and category collection pages so users and machines can browse the public business graph through crawlable links.

The Directory can identify businesses from publicly accessible business, website and structured information. Discovered records remain distinct from owner-claimed and registry-verified business profiles.

Use the Directory claim workflow from the relevant business profile or owner action. Owner or profile-control verification is separate from the public business registry verification shown on Directory profiles.

Business owners, authorized representatives and other appropriate users can submit a correction request when public listing information is inaccurate or outdated.

The Directory provides a removal request workflow for appropriate cases. Requests can be reviewed before a public record is changed or removed.

Global placement is used when a company cannot yet be tied confidently to a Directory country placement, when location information is insufficient, or when the business is intentionally represented without a single geographic placement.

Country placement is based on the public location information associated with the Directory listing. Records without sufficient country information can remain in Global mode.

Yes. Businesses may operate internationally. The Directory can still use a primary country placement for discovery while public profile information describes wider operating coverage where available.

Directory information can be refreshed as new public data, business updates and supported activity become available. Different records may therefore have different update times.

Business owners and authorized representatives can use supported claim and correction workflows to request control or changes to their public Directory information.

Public records can be refreshed from newer information, and users can submit correction requests when a listing contains inaccurate or outdated business information.

Use the relevant claim, correction, removal or support workflow associated with the listing. Providing the business URL, listing reference and clear details about the request helps the Directory review the issue.

The score can reflect factors such as the completeness, quality, discoverability and freshness of public business information and other supported public readiness signals.

No. The Directory Score is a public-data quality and readiness indicator. It is not a recommendation, guarantee or general endorsement of a business, product or service.

The globe visualizes public Directory country coverage, mapped public companies, Global companies and supported recent public activity across the Directory network.

Globe markers distinguish Directory geography and business placement such as country placement and Global companies. The legend beside the globe shows the meaning of the active visual layers.

Recent movements visualize supported recent public Directory activity between available locations or business points. They are a discovery visualization rather than private tracking data.

Active agent profiles are published businesses with a live AIG seller gateway. They may support reasoning, agent messaging, commerce or other declared capabilities. A static AI-readable listing is not automatically active.

Yes. Every published listing can expose static machine-readable profile, company JSON, llms.txt, Agent Card and schema links for discovery. Live interactions are available only when the business has an active AIG gateway.

Supported agents can use information intentionally exposed through the public Directory, such as public business profiles, services, products, capabilities and supported public endpoints.

AI-readable means compatible agents can discover the public business facts. Agent active is a separate status for businesses with supported live AIG capabilities.

Supported businesses can expose public capabilities that help compatible agents understand what the business offers and how supported interactions can be performed.

No. A published listing can expose static machine-readable business facts for discovery without operating a live agent. Active agent status is shown separately and applies only when a business has a supported live AIG gateway or another explicitly declared active capability. Static discovery alone does not imply live reasoning, messaging, A2A, MCP, UCP, checkout or autonomous action.

No. Each active profile should declare its own public capabilities and supported routes. One business may support approved answers or agent messaging, while another may also support commerce, workflow actions or human escalation. Visitors and compatible agents should rely on the published capability fields rather than assuming every active agent can perform every action.

Public analytics can summarize signals such as listing growth, country coverage, discovered businesses, published listings, active agents, successful crawls and Directory quality trends.

Website Audit checks publicly accessible website and machine-discovery information and presents readiness findings without exposing private crawler records.

Website Audit is designed around publicly accessible website information. It does not require private administrative access to perform the public readiness checks shown in the Directory.

Website Audit can report supported public machine-discovery and technical files exposed by a website, together with other publicly accessible readiness signals used by the audit.

Yes. The Developer Center can expose supported public read endpoints for developers who want to work with published Directory data programmatically.

Available endpoints can expose supported public Directory information such as published listings, discovery data, public analytics and other machine-readable resources presented by the Developer Center.

No. Public Directory views and analytics are intended to expose useful public summaries and discovery information rather than private raw crawler records.

The public Directory is designed around information appropriate for public business discovery. Private credentials, private administrative data and other non-public information are not intended to be presented as public listing content.

ASG Business Registry Verification is a separate trust layer that checks whether a public Directory business can be matched to supported registry or authority evidence. It is designed to establish business-level confidence without requiring the owner to claim the profile first.

A business can legally exist before anyone claims its Directory profile. Keeping the layers separate lets ASG verify the business record from registry evidence while independently verifying profile control when an owner later claims or activates access.

It answers: does supported external business-registry or authority evidence match this public business record strongly enough to assign a registry verification level? It does not answer who currently controls the Directory account.

Owner verification answers whether a person, account, email, domain or supported control method is authorized to control the Directory profile. That process remains independent from business-registry verification.

Yes. That is one of the main reasons the verifier exists. A public business can be Gold or Green registry verified while its owner status remains unclaimed.

Yes. Claiming a profile proves or establishes control through the owner workflow. It does not automatically create registry evidence. The profile can therefore be claimed while registry verification remains pending, unavailable or evidence-only.

Yes. A mature profile can have qualifying business-registry verification and separate owner or profile-control verification. The Directory keeps both facts instead of collapsing them into one ambiguous badge.

The verifier can use supported national or regional business registries, authority-specific adapters, global legal-entity references, structured registry evidence and other configured authoritative business sources. The exact source depends on jurisdiction and available authority coverage.

No. Jurisdictions differ. The verification layer is designed to route a business to the most appropriate configured authority or adapter, then use supported fallback evidence when a direct authority integration is not available.

Authority routing is the process of selecting the most appropriate registry or verification adapter for a business based on jurisdiction, country, available identifiers and configured authority coverage.

A registry adapter is the verification component that knows how to query or interpret a specific supported authority or registry interface. Different countries and authorities can require different request formats, identifiers and evidence handling.

The verifier can keep the business pending, use supported fallback evidence where configured, or assign an evidence-only state when the available information is useful but not strong enough to count as verified.

No. Verification should be based on evidence returned by supported authorities, registries or configured evidence sources. Missing evidence should remain missing, pending or non-qualifying rather than being fabricated.

Registry data can provide a registered legal name or corroborating identity evidence, but the Directory can keep display-name and legal-name concepts separate. Public corrections and normalization rules still apply.

When available, the verifier can retain the legal name returned by the supporting registry or authority. This can be exposed separately from the public display name so users and machines can distinguish brand presentation from legal identity.

A registry ID is an identifier supplied by or associated with a supported business authority. The Directory can expose it when appropriate so the verification basis is more transparent.

An authority code identifies the registry, authority or configured verification source used for the business check. It helps systems understand where the registry evidence came from.

Jurisdiction identifies the legal or registry context in which the business was checked. It can correspond to a country or another configured registry jurisdiction.

Registry status is the status returned or derived from the supported authority evidence, such as whether the business appears active, registered or otherwise recognized by that registry. The exact vocabulary can vary by source.

The match score represents how strongly the authority result and Directory business record correspond under the verifier's matching logic. It can consider names, identifiers, jurisdiction and other supported evidence. It is not a consumer rating.

No. Match score concerns the quality of a registry match. Directory Score concerns the strength and readiness of the public Directory record. They serve different purposes.

Checked at records when the verifier last evaluated the business against its configured registry or authority path.

Verified at records when a business reached a qualifying registry-verification state. It can differ from the most recent check time if the verifier later rechecks the record.

Next check at indicates when the verification system plans or is eligible to evaluate the business again. Rechecks help the Directory avoid treating old evidence as permanently current.

Yes. A business can move between pending, evidence-only, verified or non-qualifying states when registry information, authority responses, identifiers or matching evidence change.

A temporary authority failure should not be treated as proof that the business does not exist. The verifier can keep or schedule the record for a later check and distinguish temporary upstream failure from a genuine negative result.

Authority-specific adapters can use configured server-side credentials or API keys. These credentials are not public Directory data and should never be exposed in public profile responses.

No. Public verification responses can expose public-safe evidence such as authority name, registry ID, level or check time, but private API credentials, secrets and internal authentication data remain server-side.

Yes. Business Registry Verification belongs to the public business record, not to the owner account lifecycle. This lets the Directory build business trust at discovery scale.

Yes. Owner activation does not freeze registry evidence. The verifier can continue to refresh the business-level verification state independently.

The registry-verification state is a Directory trust and evidence function, not a paid-profile entitlement. Commercial services can remain separate from whether the public business record qualifies for registry verification.

The verification level should reflect supported evidence and policy, not payment. A paid relationship should not by itself convert a business into Gold or Green.

No. Registry verification indicates that supported registry evidence matched the business record under the Directory's verification policy. It does not guarantee product quality, solvency, safety, licensing for every activity or future conduct.

No. It is not a credit score, financial rating or creditworthiness assessment.

No. The Directory presents public registry and verification signals for discovery. Users should rely on appropriate professional or official sources for legal decisions.

No. Registry verification supports business identity confidence. Other profile fields such as marketing descriptions, products, services, locations or website content can change independently and may need separate evidence or correction.

Yes. A website can use a trading name, brand or old address while a registry uses a legal name or registered address. The verifier and Directory can keep these signals separate instead of forcing every field to become identical.

When evidence is inconsistent, the verifier can reduce confidence, keep the record pending, preserve evidence for later review or avoid assigning a qualifying level until the conflict is resolved.

Yes. Some businesses can have multiple identifiers across authorities, jurisdictions or legal-entity systems. The Directory can retain the primary supported identifier and related evidence without pretending the identifiers are interchangeable.

No. Domain evidence can help connect a public web presence to a business, but Business Registry Verification is designed around registry and authority evidence rather than domain control alone.

Not by itself. Domain control is useful for owner or profile-control workflows and as supporting evidence, but a legal-business verification level should rely on the configured registry-verification policy.

No. The Business Verification layer verifies the business record and registry evidence. Personal identity or owner-control verification belongs to separate workflows.

Not by default. A business registry may expose information relevant to ownership, but the ASG business-verification level should not be interpreted as a beneficial-owner verification unless a specific supported process says so.

Not automatically. Business existence in a registry does not prove every sector-specific license or permit. Specialized licensing evidence would need its own supported authority and policy.

Where the relevant jurisdiction and configured authority provide sufficient business evidence, smaller entities can be evaluated under the same evidence-first principles. Availability depends on what the authority exposes.

Yes when the verifier has supported authority coverage or reliable configured evidence for the relevant jurisdiction. Coverage can differ by country and registry.

Pending authority means the business has entered the verification workflow but the system still needs an authority response, a follow-up check or sufficient qualifying evidence.

Not applicable means the business-registry verification badge is intentionally not used for that entity under current policy. Government entities are the clearest example because they belong to a different classification and trust model.

Verification history helps the system understand when checks occurred, what evidence path was used and how a record reached its current state. Public responses can remain concise while internal auditability is preserved.

A qualifying state can be removed or downgraded if later evidence shows that the previous match is no longer valid, the registry status changes or the record no longer meets verification policy.

A business owner or appropriate representative can use supported correction or review channels when the public record or verification evidence appears wrong. A challenge should not be resolved by simply forcing a badge.

Duplicate or conflicting records should be normalized, reviewed or merged according to Directory policy. Registry identifiers can help detect those situations, but the system should avoid silently attaching one legal identity to unrelated public profiles.

The public verification model uses Gold, Green, Blue and None. Gold and Green count as registry verified. Blue means registry evidence exists but is not strong enough to count as verified. None means no qualifying registry verification is currently assigned.

Gold means Full Registry Verified. The business has reached the strongest supported registry-verification state under the current policy and counts as a verified business.

Green means Registry Verified. The business has qualifying registry evidence and counts as verified, while the evidence path or authority context can differ from Gold.

Blue means Registry Evidence. Useful registry or authority evidence exists, but the record does not count as fully registry verified under the current policy.

No. Blue is deliberately excluded from the verified total. This prevents the Directory from inflating verification numbers when the evidence is useful but incomplete.

No. None only means the record does not currently have a qualifying registry-verification level. The business can still be real, newly discovered, awaiting an authority check or located in a jurisdiction with limited verification coverage.

They allow the Directory to distinguish the strongest full-registry confirmation from another qualifying verified state without collapsing different evidence strengths into one generic badge.

Yes. Verification can be re-evaluated. If the available evidence changes or a later check supports a different qualifying level, the public level can change while remaining verified.

Yes when stronger qualifying evidence becomes available and the record meets the Gold policy.

Yes. Blue is an evidence state, not a dead end. A later authority confirmation or stronger match can promote the business into a qualifying verified level.

Yes if later checks no longer support the previous qualifying level but still leave useful registry evidence.

Yes. If the evidence is no longer valid, the authority match fails, the record is corrected to a different entity, or policy no longer treats the evidence as qualifying, the level can return to None.

The machine-readable countsAsVerified field is true only when the business is in a qualifying verified state under policy. In the current model, Gold and Green can count as verified; Blue and None do not.

Machine clients should not have to guess policy from a color label. The explicit boolean makes the public meaning unambiguous and allows policy to evolve without forcing every client to hard-code color logic.

Gold is presented as Full Registry Verified.

Green is presented as Registry Verified.

Blue is presented as Registry Evidence.

The Directory can omit a verification badge or describe the business as not registry verified, depending on the surface. It should not display a negative fraud implication.

Absence of qualifying registry verification is not proof of wrongdoing. A neutral state avoids turning incomplete coverage, pending checks or newly discovered records into an accusation.

No. They describe registry-verification evidence, not customer satisfaction, product quality or reputation.

No. The verification colors should reflect evidence policy, not subscription level.

Not necessarily. Featured ranking can consider registry verification together with Directory Score, freshness, public visibility and other supported ranking signals.

Yes. The Directory can provide a Registry verified filter that returns businesses whose verification state qualifies under the Gold or Green policy.

Blue should not be included in a filter that promises registry verified businesses. Blue can be exposed through its own evidence label or future evidence-specific filters.

Verified business totals count qualifying Gold and Green records. Gold, Green and Blue are also reported separately so the public can see the composition rather than only one headline number.

No. Registry verification concerns the business entity. Claiming concerns who can control the Directory profile.

Yes. Registry verification does not create an owner account. An authorized owner can still claim or activate access to manage the profile.

Yes, subject to the normal claim workflow. Blue only describes registry evidence and does not replace owner-control checks.

Yes. Owner claiming and Business Registry Verification are independent paths.

The owner or profile-control layer can use states such as unverified, email verified, domain verified or gateway verified. These states should not be presented as the business-registry badge.

It already represents useful profile-control semantics. Reusing it for legal-business verification would mix two different trust questions and make filters, analytics and owner flows ambiguous.

No. A business can be registry verified with no owner account at all. Owner access requires the separate activation or claim process.

No. Authentication proves access to an account, not that the business has passed the registry-verification policy.

The owner experience can display the public business-verification state as a separate profile signal. It should remain distinct from account security and owner-control verification.

A correction can change the public business data used for future matching. If the corrected identity changes the registry match, the verifier can re-evaluate the business.

No. The public registry level should follow supported evidence and verification policy, not a manual preference setting.

The record can immediately expose the qualifying public verification state. Separately, the acquisition and owner-access systems may use qualifying verification as a signal for appropriate outreach or onboarding.

Qualifying verified businesses can be eligible for a proactive invitation workflow when ASG has an appropriate public business contact path. That invitation does not pretend the recipient has already proven ownership.

No. Registry Evidence is intentionally non-qualifying for automatic verified-business invitation policy. Stronger qualifying verification is required.

They can be used as qualifying signals because they count as verified under current policy. Other safety, contact and suppression rules can still apply before any outreach is sent.

No. A proactive owner invitation must remain separate from the claim-bound invitation path. The system should not fabricate a claim merely to reuse claim workflow tables.

They can converge only after legitimate activation at the shared Owner account and access layer. Before activation, the two invitation paths remain separate so their meaning stays honest.

No. The invitation is an opportunity to activate access for a registry-verified business. It must not state that the recipient has already completed legal-owner identity verification.

Before applying business policy, the Directory can classify a record as business, government, nonprofit, education, healthcare, association or unknown. This prevents business-only verification rules from being applied blindly to every organization.

No. Government departments, agencies and public authorities use a separate entity-classification model. Business Registry Verification is not applicable to them.

Because a government body is not simply a business that failed verification. It belongs to a different entity category and should not receive a misleading business-registry badge.

Yes. Government or public-authority websites can be authoritative evidence sources used to verify businesses, even though the government entity itself is not treated as a business.

The Directory can expose entityType as government and return business verification as not applicable. This preserves clarity for human and machine clients.

A commercial company owned or controlled by a state can still be classified as a business when it operates as a commercial enterprise. It should not automatically be classified as a government department.

Entity classification describes what the organization is and how it operates, not only who owns it. A state-owned commercial enterprise can remain a business while a ministry or regulator remains government.

The classifier can keep the entity unknown or flag it for review rather than forcing a government label from weak evidence.

Yes. As stronger evidence arrives, a record can be reclassified. Verification policy should then follow the new entity type.

The preferred architecture keeps entity classification upstream in the Directory indexing layer. The verifier consumes that classification instead of inventing a competing entity model.

The Indexer already has the structured evidence needed to normalize the business record. Classifying there avoids extra database reads and prevents multiple workers from assigning conflicting entity types.

These entity types can require authority-specific policy. The Directory can expose their classification now while verification coverage evolves. The system should avoid pretending every non-government organization follows the exact same commercial registry path.

Unknown means the Directory does not yet have enough confidence to assign a stronger entity category. It is a deliberate uncertainty state, not an error or negative judgment.

The matching process can compare normalized business names, legal names, jurisdiction, registry identifiers and other supported evidence. The exact matching rules can vary by authority adapter.

Public websites and registries can format the same legal name differently. Normalization helps compare equivalent forms while still preserving the original public and legal names for display.

Yes. The Directory can keep a public brand or trading name while separately exposing a registry legal name when supported evidence provides it.

No. Evidence strength matters. An authoritative registry record is not equivalent to an unrelated webpage containing the same name.

The verification system can store public-safe summary fields on the Directory listing and maintain internal check records or state needed for retries, auditing and scheduled rechecks.

The public Directory needs fast access to the current verification state for cards, filters, quick view and analytics. Storing the current snapshot on the listing avoids rebuilding the entire verification history for every page view.

No. Public responses should expose only the fields appropriate for public business discovery. Raw credentials, internal diagnostics and non-public authority response details do not belong in public profile JSON.

Refresh timing can depend on authority limits, previous result, next-check scheduling and system policy. A record can carry checkedAt and nextCheckAt so the refresh lifecycle remains explicit.

A later authority check can discover the changed legal name. The Directory can update the legal-name evidence while preserving public display-name policy and change history where appropriate.

A supported registry status change can cause the verification state to be re-evaluated. A business should not keep an outdated qualifying badge forever when the underlying authority evidence has materially changed.

Not necessarily. Registry status and Directory publication are separate concepts. The Directory can retain a public historical or informational record while adjusting verification, freshness or visibility policy as appropriate.

Yes. Temporary network, rate-limit or authority failures can be retried according to configured scheduling and backoff policy rather than being treated as final business evidence.

The verifier can use queues, cursors, incremental snapshots and next-check timestamps so large public datasets are processed in controlled batches instead of re-querying the entire population continuously.

Not necessarily. The crawler can supply discovery evidence, but registry verification can use the canonical Directory listing and configured authority integrations directly.

Website evidence can support identity correlation, but it should not silently replace the authority layer when policy requires registry confirmation.

Historical names can be useful evidence but should be interpreted according to the authority's semantics. A historical trading name should not automatically be treated as the current legal business name.

The verifier can require jurisdiction consistency, strong name or identifier matching, appropriate authority evidence and policy thresholds before assigning a qualifying level.

A missing direct match can remain pending, evidence-only or unverified rather than becoming a fraud label. Coverage gaps and authority limitations are expected in a global directory.

The verifier should use jurisdiction, registry identifiers and other supported evidence to distinguish them. Name equality alone should not be enough for a high-confidence legal-entity match.

Yes when the Directory has enough business identity information and the relevant authority supports a reliable match. A website is useful for discovery but is not the legal registry itself.

Yes. Public discovery can include a website-based business record even while registry verification is pending or unavailable. The verification state should explain the evidence gap rather than hiding the business.

The public business-verification layer is designed around business identity and supported authority evidence. It should not require private customer conversations or unrelated personal data to assign a public registry level.

The business profile JSON can expose a businessVerification object containing the public-safe verification status, level, label, authority, registry ID, match score and related timestamps when available.

Status describes the current verification workflow result, such as verified, pending or another supported state. Clients should also read level and countsAsVerified rather than guessing verification meaning from status alone.

Level is the normalized public verification tier such as gold, green, blue or none.

Label is the human-readable presentation such as Full Registry Verified, Registry Verified, Registry Evidence or Not Registry Verified.

Authority identifies the public-safe registry or verification authority associated with the current evidence when that information is available.

registryId exposes the public-safe business identifier associated with the current registry evidence when available.

matchScore is the numeric strength of the registry match under the verification logic. It should not be treated as a customer-review score.

It is the explicit machine-readable policy result. Clients can use it to determine whether the business belongs in the Registry verified set without hard-coding display labels.

The object can return applicable false, status not_applicable and countsAsVerified false, making it clear that the business-verification model is intentionally not being applied.

Yes. The public Directory search can support a business_verified=true style filter that returns businesses whose Gold or Green state qualifies under the current verified-business policy.

No. The Registry verified filter uses the business-verification fields, not the legacy owner or claim verification_status field.

The Directory can expose registry-verification-aware sorting that places qualifying Gold and Green states ahead of Blue and None while still using supported quality and name tie-breakers.

The Directory can retain the legacy verificationStatus for ownership or profile-control semantics where needed, but public business registry presentation should use businessVerification.

Renaming an established ownership field would risk breaking claim, owner and existing API behavior. Adding a separate businessVerification object preserves compatibility and keeps semantics honest.

Yes. Separate machine-readable fields let agents distinguish legal-business registry evidence from profile-control verification, Directory Score, Website Audit and agentic readiness.

Yes. The machine-readable discovery document can explain supported business-verification levels and clearly state that Business Registry Verification is separate from ownership verification.

A concise public explanation can help AI systems interpret the Directory correctly, especially the difference between Gold or Green registry verification and owner claim status.

Public structured data can reference registry identity or supporting identifiers where appropriate, but it should avoid inventing schema semantics that imply endorsements or legal certifications not actually provided by the authority.

No. Public API responses must never expose API keys, authority credentials, internal secrets or private service-binding information.

Yes. checkedAt, verifiedAt and nextCheckAt can be useful public-safe freshness indicators when present.

The public verified-business total is the number of qualifying Gold and Green records whose machine policy says they count as verified.

No. Blue is reported separately as Registry Evidence.

The denominator represents public records to which the current business-registry verification policy applies. Government entities are excluded because their verification state is not applicable.

It is the qualifying Gold plus Green business count divided by the eligible public-business population for the current analytics snapshot.

A single verified percentage can hide the strength and maturity of the evidence base. Showing the level mix lets visitors see full verification, qualifying verification and evidence-only coverage separately.

Registry verification is now a first-class trust dimension of the Directory, so the Metrics drawer can show the live verified-business total and eligible rate alongside public listings, countries and other network measures.

The Analytics drawer summarizes public business-graph health. Registry verification belongs there because it measures trust coverage rather than merely UI activity.

The detailed analytics section can show Gold, Green, Blue and not-verified populations so users can inspect the composition behind the headline verified rate.

No. The Directory analytics response can expose the current registryVerification aggregate from Directory listing data, allowing multiple frontend surfaces to reuse one analytics snapshot.

No. The intended design is to reuse the same analytics.registryVerification object across the Metrics drawer, Analytics drawer, trust strip, ticker and detailed analytics card.

It keeps public numbers consistent and avoids multiplying database reads simply because the same metric is displayed in several places.

They should use the same qualifying policy. If they disagree, the system should treat it as an implementation or caching issue and fix the exposure path rather than inventing a second definition of verified.

It should include only records that meet the current qualifying Business Registry Verification policy and are part of the relevant public Directory population.

No. Claim status is a separate metric. A claimed business only belongs in the registry-verified count if its businessVerification state independently qualifies.

Yes, as long as the component is clearly labeled and uses the business-registry verified rate rather than the old hidden ownership-verification rate.

The old metric represented owner or profile-control verification and could be mistaken for legal-business verification. Public surfaces should prefer the new explicit registry-verification meaning where they discuss business trust.

No. Business Registry Verification can operate before an owner account exists and should expose public business evidence, not private owner-account data.

Not as part of the public verification badge. Public contact information follows the Directory's separate public-contact policy.

No. Business Registry Verification concerns business identity evidence. Visitor analytics and public activity are separate systems.

No. ASG is presenting a verification signal derived from supported evidence. Users remain responsible for their own due diligence and transaction decisions.

Yes. Registry identity confidence does not freeze every public field. Website, service, product, location and contact information can still change.

Yes. Website Audit evaluates the current public website and machine-readiness signals. Registry Verification evaluates business identity evidence. They are intentionally independent.

Yes. Agentic readiness and live AIG capability are separate from legal-business registry verification.

Potentially, because agent capability and registry verification are different dimensions. Public interfaces should show both states rather than implying one proves the other.

Payment or subscription status should not automatically qualify a business for registry verification.

Yes when publication, suppression, removal or policy rules require it. Verification does not override the Directory's visibility and safety controls.

It uses explicit states such as pending, Blue Registry Evidence, None or unknown entity classification rather than converting every uncertain case into a binary verified or fake judgment.

Countries publish different data, authorities have different APIs, businesses use different legal forms and coverage is uneven. A trustworthy system must represent those gaps rather than hide them.

The system is designed for automated authority-backed verification at scale, with review paths for ambiguous or exceptional cases. Automation should still follow the same evidence policy.

Administrative repair or review tools may exist, but public verification should remain auditable and evidence-based. Manual actions should not silently erase the distinction between evidence and policy.

The verification badge affects trust. Explaining what it means, what it does not mean and how it differs from owner claiming helps people and machines interpret it correctly.

Use the supported correction or review process and provide the most useful public identifying information available. The Directory can re-evaluate the registry match rather than keeping an incorrect badge.

Submit a correction through the Directory workflow. A future verification pass can compare the corrected business identity with the supporting authority evidence.

Request a correction or review. Registry identifiers are important evidence and should not be changed casually without support.

The record may be awaiting authority processing, missing a strong match, located in a jurisdiction with limited coverage or using identifiers the current adapter cannot confirm. Not Registry Verified is not a fraud label.

Blue means the system found meaningful registry evidence but has not reached a qualifying Gold or Green state. A later authority check can improve the result if stronger evidence becomes available.

The current authority path may support a qualifying match without the stronger evidence required for Gold. A recheck can update the level when stronger evidence becomes available.

That is primarily an entity-classification problem. The Directory should correct the entity type so business verification becomes not applicable rather than merely changing the badge color.

The classification should be reviewed. A commercial state-owned enterprise can remain a business if its operating form and evidence support that classification.

A later registry check or public-data refresh can update the registry status and verification state. Directory visibility can then follow publication and review policy.

The relevant adapter can be updated while preserving the public verification model. Businesses should not be assigned new meaning merely because an upstream API changed its response format.

The first checks should compare the Registry verified search filter with the public analytics registryVerification object. If the filter returns businesses but analytics show zero, the issue is likely in aggregation exposure, response assembly or caching rather than the verifier data itself.

Compare the public Directory query using the registry-verified filter with the analytics registryVerification.verifiedBusinesses total. Both should reflect the same qualifying Gold and Green policy.

Yes. Public API caching can briefly delay aggregate visibility even when individual listing filters already see the updated verification fields. Cache policy should keep that delay bounded and predictable.

No. That would produce false totals because search results are paginated. Verification totals belong in the server-side analytics response or another authoritative aggregate endpoint.

No. The Directory should reuse existing analytics work and cached aggregates where appropriate. Displaying the same number in multiple UI surfaces is not a reason to repeat the same database scan.

A healthy system shows qualifying businesses through the Registry verified filter, exposes businessVerification on individual business JSON, and reports matching Gold and Green totals through public analytics.

Discovery identifies the public business record. Entity classification determines whether business-registry verification is applicable. Business Registry Verification evaluates supported authority evidence and assigns Gold, Green, Blue or None. Gold and Green count as registry verified; Blue is evidence only. Owner claim and profile-control verification remain separate. Directory Score measures record strength, Website Audit measures current website readiness, and agentic status describes machine capability. Public analytics reuse the same registry-verification policy so search, filters, business cards, quick view, metrics and analytics all describe the same truth.

Use the business selector before making changes. Each business has its own profile, publication status and plan.

Check your website address, confirm you control it in Verification center, then review your business information. Your Directory profile and your own website are different pages.

You do not need your own website or domain. Open Hosted storefront to continue your saved draft, add your business information and submit it for review.

Published means the public page is live. Review describes approval. Verification describes checks on ownership or business evidence. A paid plan is separate from all three.

Network requests cover the wider WebsDocs ecosystem. Directory visits and Gateway visits are request counts. Unique visitors and identified AI overlap those counts; do not add every tile together. Your business visits is the separate count for this business.

Network requests count recorded requests during the displayed period. Directory and Gateway requests make up this total. Unique visitors and identified AI are overlapping measures, so do not add them to the total. Your business visits is reported separately.

Free includes 24 hours and 7 days. Paid reporting adds 30 and 90 days where records exist. A rolling 24-hour count can fall as older visits leave the period, even while new visits arrive.

Your business activity contains only events linked to the selected business. Profile opens are recorded openings of its profile; contact or booking clicks show interest, not completed sales. A dash means information is unavailable, not zero.

Listings, countries, services and products describe what the Directory contains. They are not visitor counts and can update at a different time.

Use the suggested actions to complete missing details, review verification or improve your profile. Check the save or completion message after each action.

Open a saved audit to see improvements for your website. Reading the report does not start another scan.

For a website listing, follow the displayed instructions to add a DNS TXT record, a verification file or a homepage tag. Your website administrator can help. Run the check after making the change.

A hosted profile has no website domain to prove. Use your active Owner account to manage it. Account access, publication review and official business verification remain separate checks.

Choose your country, enter your number and request a verification code once. Read the delivery message to see whether the code went by SMS or to your masked email address.

Wait for the delivery message. If email delivery is confirmed, check your inbox and spam folder. Some numbers cannot receive SMS. Request another code only when needed.

Enter the six digits from the indicated message before they expire. Never share the code. Email confirmation proves access to that email, not ownership of the phone or website.

Read the verification and editing status after the check. Business registry verification is handled in Business verification; buying a plan does not replace either check.

Enter your registered business name, country and any requested registration details as they appear in official records. Trading names may differ from legal names.

Use the check action and wait for its result. If another check is not yet available, follow the time or message shown. Sending a request does not itself verify the business.

Read the authority, evidence and result. Correct mismatched details or contact support. Your own description and a paid plan do not grant an official verification badge.

Review the business name, description, address, category, image and contact information. Use the public profile link to check the published result.

Use the available correction form and wait for confirmation. Some changes require ownership checks or review. Free access includes supported corrections; paid editors provide additional control where enabled.

Where your plan and editing access allow, use the editors for categories, public contacts and service areas. Saved Owner content is kept separately from information found on your website.

Use Hosted storefront to manage your hosted page and its Free or paid content allowance. Check publication status after saving or submitting.

Read each listing action carefully before confirming. Saving information, publishing a page and requesting removal are different actions.

Profile quality, verification and confidence measure different things. A Directory score is not your website audit score or a promise of search ranking.

Save useful corrections first, then request a rescore. Free and paid owners can use rescore, with different waiting periods and history access shown on the page. Payment does not add points or verification.

A website audit checks website health. A recrawl asks for fresh website information and may wait in a queue. Reindexing updates the Directory from saved information. Rescoring calculates the score from available saved evidence. Check progress before requesting the next step.

Improve your hosted business details and supporting evidence, then rescore when available. A hosted profile without a website does not need a website scan.

Read the breakdown to identify missing or weak information. Use history where your plan allows it. Wait for a completed result; starting a job does not mean the score has changed.

Both Free and paid website owners can request a scan. Check availability, remaining capacity and any waiting period shown before starting. Scan the website linked to this business.

There is no separate website to scan. Improve your hosted page in Hosted storefront and use Directory scoring to review its saved business information.

Start with the overall result and category scores. Review the most important issues first and share technical findings with the person who maintains your website.

Expand the saved report on this page for details. Reports describe the website at scan time; fixing a page does not automatically change an old report.

After changes, run another scan when available and compare saved results. If a scan fails, read its message and capacity status before retrying.

Describe each service, where it is available and any public price or booking link.

The separate content editor needs a paid plan and editing access. Free owners can review published content and use supported correction routes. Saving an Owner-managed collection prevents later website crawls from replacing that collection.

Use Hosted storefront for the services and products included in your hosted plan. Free and paid plans have different limits; a locked separate editor does not mean your Free storefront allowance is unavailable.

Wait for the save confirmation and review the resulting public information. Catalogue imports need review and saving; a connection alone does not publish your items.

Check product names, descriptions, prices, currency, availability, brand and item codes. Remove outdated offers.

The separate content editor needs a paid plan and editing access. Free owners can review published content and use supported correction routes. Saving an Owner-managed collection prevents later website crawls from replacing that collection.

Use Hosted storefront for the services and products included in your hosted plan. Free and paid plans have different limits; a locked separate editor does not mean your Free storefront allowance is unavailable.

Wait for the save confirmation and review the resulting public information. Catalogue imports need review and saving; a connection alone does not publish your items.

List only actions your business actually supports. If a paid capability editor is available, ask your website specialist to confirm technical addresses and settings before saving.

Being readable by AI does not guarantee that an AI service will visit, recommend your business or complete a transaction.

Use Discovery & links for official website, documentation and AI information links. Leave technical fields alone if you do not know their purpose.

Choose a type such as website, booking or support, then enter the complete official address. Technical types such as sitemap or Agent Card can be supplied by your website administrator.

Saved links are public business information. Remove broken or outdated addresses and avoid private account links.

Where offered, mark the preferred link as primary so there is a clear main address for that type.

Your hosted page can include links within the plan limits. Use Hosted storefront for those links; no website domain is required.

The dashboard lists WordPress, Shopify, Wix, Squarespace, Webflow and Google Tag Manager. Setup available means you can begin; Configuration pending means setup is not ready. Neither means your business is already connected.

Choose Connect / authorize, follow the setup link and select the correct store, website or container. These connections belong to the selected Directory business. Do not substitute an unrelated dashboard site identifier.

Use the installation link supplied by the WordPress connection and follow its instructions. Ask your website administrator to install or configure the offered plugin if needed. Downloading a ZIP alone does not confirm a connection.

Some setup steps can add code or publish a website or Tag Manager change. Review the selected destination before confirming. Then use Refresh status and Check connection to verify the result.

Read the message above the cards. Missing business setup, a pending platform configuration or an incomplete connection can disable actions. Refresh after setup; contact support if the message persists.

Enter the permanent store.myshopify.com address in catalogue sync and authorize it. Both Free and paid owners can connect and review products; adding selected items to the separate products editor requires paid editing access.

Start sync and fetch the next batch when requested. Review the latest snapshot, select suitable items and add them to the products editor when allowed. Check and save there. Sync alone does not publish all products or grant a verification badge.

If you have no external store or website, maintain your content in Hosted storefront. You do not need to create a platform account just to publish your hosted profile.

Free includes 24 hours and 7 days. Paid reporting includes 30 and 90 days where records exist. Expanded detail depends on your available reporting access.

Network Pulse describes the wider ecosystem. Your business visits and the business activity section refer only to the selected business. Do not treat the whole network as your audience.

A rolling window moves forward. Yesterday’s visits leave the last 24 hours as time passes. That can lower the number without deleting your history. Other periods and network tiles may refresh separately.

Visits count recorded requests linked to this business. Profile opens count recorded profile openings. Unique visitors use available visitor identifiers, not confirmed people. A dash means unavailable information.

Known AI is matched to a recognised footprint. Declared AI identifies itself. Unknown automation is not fully identified, and browser or unidentified traffic is not proof of a human visitor.

The comparison uses the previous matching period. Check whether the figures describe the whole network or your selected business, and read the dates beside each comparison.

Questions, contact clicks, bookings and checkout actions describe recorded interest. They do not confirm a purchase. Product and service details appear only when the event included them and your access allows them.

Read the question allowance shown here. Presence does not automatically increase it or add AI credits. Free includes recent previews and summary interest counts; paid reporting can show more recorded detail.

Open available question previews, responses and visitor records to understand when and how people or automated tools reached your business. A preview limit is not the total activity count.

Review the listed sources and their dates. Prefer your official website and current public business records.

Correct your business details through the available Owner controls and update your website where necessary. Saved Owner content is kept separately from website observations. A new crawl does not grant verification.

Use accurate business details and official supporting links even without a website. Official business verification remains a separate check.

The owner can invite 3 teammates on Free or 10 on Paid, in addition to the owner. A Viewer reads business information; an Editor can update business content within its existing permissions. Pending invitations reserve seats for 7 days. Billing, verification, ownership and team management remain with the owner. Cancel invitations or remove access here. After a downgrade, later accepted seats pause until the owner frees a seat.

Check your sign-in and security status. Security controls remain available without a Presence subscription.

Follow the authenticator instructions and keep recovery codes somewhere safe outside this browser. Do not share passwords, verification codes or recovery codes.

Check active sessions and revoke any you do not recognise. Use the password controls if your password may be exposed.

Describe what you tried, what you expected and what happened. Include the business name and a screenshot or error message if useful. Never include passwords or sign-in codes.

Check your existing ticket and replies before opening another ticket for the same issue. Support does not automatically approve publication or complete a payment.

Yes. Create a free Agency workspace with your agency name and email, verify your email and sign in. No business listing is required. If you already have an Owner account, use the same credentials at Agency sign in and enable your Agency workspace.

Yes. An agency can submit accurate, publicly available business information without first obtaining permission from each business owner. Use Add a business in the Agency workspace. Submitting or publishing a listing does not establish ownership, verify the business or grant editing access. Do not submit confidential information, impersonate an owner or upload material you do not have the right to use.

For a new public listing, check Skip admin review to publish automatically after the submission passes the required validation. Leave it unchecked to send the listing for admin review. The option does not overwrite an existing listing, restore a removed listing, award a verification badge or grant editing rights. A request that cannot be completed shows its status in Client requests.

Yes. You can submit multiple businesses and manage businesses whose owners have granted you access. Basic Directory listings remain permanently free, including a link to an existing business website. Optional paid products are separate. The current submission/request allowance is 20 new requests per hour per agency; client-contact requests also have a limit of five per recipient per day. These are submission controls, not ownership permissions.

Publication and editing access are separate. For a business with a website, its owner verifies the business-domain email and invites the agency account as an Editor from the business team controls. The agency accepts the invitation. A public email found by the prefill tool, a listing submission or a client-confirmation email alone does not grant editing access. A business without a domain follows the applicable ownership-verification route before delegated access is granted.

Yes. A paid Agency subscription is not required to accept Editor invitations from different owners. Each business’s team allowance and role permissions still apply. The free business plan allows up to three invited team members, excluding the owner. Owners retain control and can revoke access; an Agency account does not bypass those limits.

For a new business with a website, choose Business with a website and enter its URL. If the business is already listed, use its existing record for an ownership or management request instead of creating a duplicate. A business without its own website can be submitted through the hosted-profile route. Hosted business pages are a separate presentation option and can be used with or without an existing website; publication of a Directory listing does not automatically publish a hosted storefront.

Yes. Enter a public website URL and choose Find business details. The tool suggests available information such as the name, description, country, contact details and logo, while keeping your existing entries. It may not find every field or may identify a detail incorrectly, so review and correct the suggestions. Manual entry remains available. A detected email or logo does not verify ownership or grant permission to edit the business.

No. Public submissions are recorded against your Agency account and do not require a client-confirmation email. Ownership claims and requests to manage an existing listing are separate: enter the client’s appropriate contact for those requests. The client’s confirmation does not itself give the agency editing access; business ownership verification and an Editor invitation are still required.

Use Overview for counts and status, Companies for businesses linked to your account, Client requests for submissions and access requests, Add a business for new submissions, Agency profile for your agency details and images, Messages for WebsDocs communications, and Agency guide for instructions. Submitted or published listings can appear in your requests without becoming companies you are allowed to edit.

Your Agency profile is available to your agency and WebsDocs Admin; saving it does not create a public Directory listing for the agency. Add contact details, a description, links, a logo and a banner. Supported image uploads are PNG, JPEG and WebP, up to 2 MB per image and 15 MB total per agency. Only upload images you have permission to use. Changing the profile contact email does not change your sign-in email.

WebsDocs Admin can publish announcements to Agency workspaces and send private messages to one agency. Your replies go privately to WebsDocs Admin, not to client businesses or other agencies. These messages are shown inside the workspace; they are not automatic email broadcasts or push notifications. For help, you can also email hello@websdocs.com.

WebsDocs operates globally and accepts eligible business submissions worldwide. Listing eligibility, verification methods and optional services remain subject to applicable law and service availability; not every registry, payment method or feature is available in every country. WebsDocs is operated by Javed Sarwar, a sole proprietor trading as WebsDocs. Contact hello@websdocs.com for service questions.

Open your saved Hosted storefront. Check whether it is a draft, awaiting review or published. Do not submit a second setup request just to edit an existing business.

Add your business name, description, public contacts, services, products, photos, frequently asked questions, offers and official links using the fields available. Include only information you want customers to see.

Both Free and paid hosted plans support content. Plans & benefits lists the different item and storage limits. If publication is blocked by a limit, reduce the content or choose a suitable plan.

Save draft keeps your changes privately. Wait for the saved message before switching business or leaving the page. Typing alone does not save your work.

Submit for review when ready. Submission does not mean approval or immediate publication. Check the resulting status and open the public page after it is published before sharing its address.

A WebsDocs-hosted business profile is a public business presence for a business that does not use its own website. It can publish business-managed contacts, services, products, offers, opening hours, social links and other approved public information on business.websdocs.com.

No. The hosted profile is specifically designed to give a business a public WebsDocs presence without requiring a separate website or domain.

Published hosted profiles use the WebsDocs business host, with a public address based on the business profile slug at business.websdocs.com.

Yes. The supplied Directory and Profile Studio material describes review as a separate step. Submitting a profile requests review; it does not mean the page is immediately approved or published.

Depending on the plan limits, the profile can include business identity, public contacts, location and service areas, opening hours, brand images, services, products, offers, frequently asked questions, official links and social information.

Yes. Hosted and Directory profiles can expose structured public business information and machine-readable discovery routes without requiring the profile itself to run a live AI model.

No. The Profile Studio guidance says prices and offers describe the business; they do not by themselves enable customer checkout.

After setup, use the Directory Owner Workspace and its Hosted storefront controls to save changes, manage the published content, request review and handle plan or billing actions.

Use your own account email for Owner access. It is separate from your public business contact. Submit only if you own the business or are authorized to represent it.

Use the real business name, category and a clear description of what you do. Check the Directory for an existing listing before creating another one. A preview is not a published or verified profile.

Add the contact methods customers should use, such as phone, email, WhatsApp or a booking link. Check each address and link. Do not put private account information in public fields.

Enter accurate location, service areas and opening hours. Describe where you actually serve customers. Avoid publishing a private address unless it is intended to be public.

Use images you own or have permission to publish. Free publishing includes 3 gallery photos; Hosted Presence includes 30. Logo and cover are separate from gallery photos but count toward media storage. Initial Studio uploads allow 25 MB total; paid Owner storage allows 100 MB.

Free publishing allows 5 services, 5 products and 1 current or scheduled offer. Hosted Presence allows 50 services, 100 products and 20 current or scheduled offers. Expired offers do not use an active offer slot. Prices and offers describe your business; they do not enable customer checkout.

Answer common customer questions and add useful official links. Free publishing allows 5 FAQs and 3 custom links; Hosted Presence allows 40 FAQs and 30 custom links. Keep promises, availability and descriptions accurate.

Free profiles use standard colours. Hosted Presence costs USD 9/month per business and adds custom colours, larger publishing limits and 90-day reporting where activity exists. Upgrade in Owner workspace after setup. Website owners have a separate USD 5/month Website Presence offer. Taxes may apply at checkout. Neither Presence plan includes live AI or AI credits.

Read the declaration and check every public detail before submitting. Submission requests review; it does not publish automatically. Larger drafts can be prepared, but publication must fit your plan. Unsent form changes are not saved across refreshes. After setup, use Owner workspace to save changes, request review and manage billing.

Free includes account access, supported business corrections, domain verification, security, 24-hour and 7-day reporting, recent question previews and website scans within the available scan limits.

Website Presence is currently shown as US$5 per month per business. It adds 30-day and 90-day reporting and more visitor, question and interest detail where recorded. Paid content editors need editing access too. Check the plan comparison and checkout for current terms.

Free supports a hosted business page within its publication limits: 5 services, 5 products, 3 gallery photos, 5 FAQs, 1 offer, 3 custom links, standard colours and 25 MB of owned media. Reporting includes 24 hours and 7 days. Review is still required.

Hosted Presence is currently shown as US$9 per month per business. Its comparison lists 50 services, 100 products, 30 photos, 40 FAQs, 20 offers, 30 links, custom colours and 100 MB of owned media, with reporting up to 90 days. Confirm current limits and price in Plans & benefits.

Use Hosted storefront for the content allowed by your hosted plan, including Free. Separate paid content editors elsewhere may still be locked. Initial Studio uploads have a separate 25 MB setup-session limit. Saved drafts remain; unsaved browser changes do not.

You can upgrade before proving domain control. Payment does not verify your business, approve publication or unlock changes that still need ownership proof.

Presence does not automatically add Live AI credits or increase question allowances. It cannot restore missing history or guarantee visitors, AI recommendations, enquiries or sales. Existing paid AIG reporting is respected where available.

Checkout opens only when you choose it. Review the monthly price and any taxes before paying. Use Manage billing to review payment issues or cancel future renewals; read the displayed end date. If the plan cannot load, refresh or contact support.

RTD is a website conversation and business-operation product that brings Voice, Chat, approved company information, visitor intent, lead creation, Human Inbox continuation, transcripts, recordings, website deployment, and operating controls into one connected workspace. The website Agent responds from an approved business profile and remains connected to the Voice Dashboard, where the business can review activity, outcomes, usage, domains, publication status, and account controls.

RTD Studio is where the business profile is prepared, reviewed, approved, and published. It defines what the Agent is permitted to communicate about the company, its services, processes, policies, routes, and business information.

The Voice Dashboard is the operating workspace used after setup. It shows live and previous conversations, leads, Human Inbox cases, transcripts, recordings, Domain Agents, Website Audit results, usage, credits, Support Messages, team access, and settings.

The business-facing experience is built around the approved RTD profile and the information authorized for that Domain Agent. The purpose is to keep responses aligned with the company’s approved services, terminology, policies, processes, and visitor routes.

Changes to important business information should be reviewed and published through RTD Studio so the live Agent continues to reflect the approved company position.

Yes. A Domain Agent can provide Voice, Chat, or both, depending on the selected plan, published configuration, website experience, and enabled channels.

Both channels remain connected to the same approved business profile and operating workspace, allowing the team to review visitor intent, conversation context, actions, outcomes, and usage without separating the business record.

The interaction can continue through Human Inbox when the request is sensitive, uncertain, qualified, account-specific, or requires an authorized company officer. The officer receives the available conversation context, including visitor intent, previous messages, the Agent’s summary, routing destination, and relevant contact details.

The case can then be accepted, assigned, replied to, noted internally, resolved, closed, or returned to the Agent.

When a visitor expresses qualified intent and provides appropriate contact details or permission, RTD can create a visible lead record connected to the original conversation. The lead can contain contact information, project or service interest, qualification answers, conversation context, source channel, Domain Agent, assignment, status, notes, and follow-up history.

This allows the business to move from conversation to accountable sales work.

A Domain Agent is the approved RTD operation assigned to a specific website or domain. It connects that website to its published profile, enabled channels, language coverage, deployment method, connection status, usage, and recent activity.

Businesses operating multiple approved websites can manage those Agents separately while keeping them inside the same protected workspace and shared account structure.

RTD can be deployed as a Premium iframe, Floating Agent, Button Agent, JavaScript SDK integration, or protected Hosted Agent page. These methods give the website team control over how and where the visitor experience appears.

A business can also use Dashboard Platform Settings for supported managed connections. The selected route remains tied to the approved Domain Agent and its publication controls.

Deploying means placing the Agent through a supplied website format such as an iframe, floating launcher, existing button, SDK, or hosted destination. Connecting means authorizing a supported website platform through Dashboard Platform Settings.

That route can handle platform authorization, configuration, verification, connection status, and managed installation from the protected workspace.

The product experience presented here supports managed connection routes for WordPress, Shopify, Wix, Squarespace, Webflow, and Google Tag Manager. The available authorization and installation steps can differ by platform.

Connection status, domain verification, selected Domain Agent, deployment format, and publication readiness remain visible through Dashboard Platform Settings.

Eligible Voice, Chat, and Human Inbox activity uses credits from the workspace’s shared prepaid wallet. The Dashboard shows the available balance, usage by channel, monthly credit delivery, top-ups, transaction history, and estimated remaining activity.

Actual consumption depends on the active product channel and the applicable plan rate. The pricing and usage areas should be used for the current allowance, included features, and credit terms.

Conversation transcripts remain connected to the relevant conversation record when available under the product operation. Audio recordings are separate and appear only when recording is enabled for the plan, Domain Agent, and applicable conversation.

The business should configure recording and retention according to its operational requirements, customer communications, applicable permissions, and account controls.

Website Audit provides a structured view of website readiness, visible business risks, category scores, findings, supporting evidence, affected pages, recommendations, and audit history. It helps the business understand whether the website clearly supports visitor pathways, company positioning, trust, support, conversion, and the wider RTD operation.

It does not automatically replace business review or implementation decisions.

The workspace is designed to keep Agent status, profile version, domain state, connection, installation, and publication controls visible after launch. An authorized user can review the relevant configuration, update approved business information through RTD Studio, verify the website route, and publish the appropriate version.

Availability can also be controlled when the business does not want the Agent accepting new conversations.

The current RTD Dashboard guide describes one universal rtd-agent.js loader. The server-side Site ID, verified origin, plan entitlement, selected model, published profile, wallet, recording policy, and feature state determine how that loader behaves.

What this step does: Confirms that this setup belongs to you and connects it to the correct website. What to enter The activation code from your WebsDocs email.

The same email address used for the purchase or approval. Your main website address, for example https://company.com .

Helpful notes Use the real public website whenever possible. For local testing, enter the exact localhost address and port you will use.

The first approved website becomes the primary Agent domain. Next: WebsDocs sends a short verification code to the registered email.

What this step does: Confirms that the person completing setup can access the registered email account. What to do Select Send verification code .

Open the email from WebsDocs. Enter the 6-digit code in Studio.

Helpful notes The code is temporary and expires after a short time. Check the spam or junk folder when the message does not arrive.

Never share the activation code or verification code with another person. Next: Create the password used to sign in to the Voice Dashboard.

What this step does: Creates the owner login for the Voice Dashboard. Password guidance Use at least 10 characters.

Include at least one letter and one number. Use a password that is not used on another website.

Do not use your activation code or email verification code as the password. The password is protected before storage.

WebsDocs does not return the original password after setup. Next: Add the public business information visitors should see and hear.

What this step does: Tells the Agent which company it represents. What to enter Company name: the public name customers recognize.

Agent name: the name visitors will see and hear. Industry and business type: a simple description of your work.

Tagline: one short sentence about your value. Business summary: what you do, who you help, and what makes your service useful.

Write for a customer, not for an internal technical team. Use only information approved for public use.

What this step does: Gives visitors accurate ways to contact the company and understand when help is available. Recommended information Public email and phone number.

Business hours and timezone. Service areas or locations.

Contact, support, and booking pages. A realistic response-time message.

Only enter contact details that customers are allowed to use.

What this step does: Controls the opening greeting, voice, tone, and length of spoken answers. Simple setup advice Use a short greeting that says who the Agent represents.

Choose a warm, clear, and professional style. Keep spoken answers brief so visitors can respond naturally.

Use the fallback message when the Agent does not have approved information. The Agent should explain approved information, not make legal, financial, or custom commercial promises.

What this step does: Makes the hosted page and website widget match your company. Images Company logo: used beside the company name and inside supported Agent views.

Banner: shown as a clear, wide image on the hosted Agent page. Agent avatar: optional image for the assistant.

The RTD default avatar is used when empty. Colors and position Choose readable colors with good contrast.

Select bottom-left or bottom-right for the website launcher. Use the preview to check the greeting, avatar, and panel appearance.

Images are uploaded securely when the final workspace is created. For a sharp full-width banner, use a wide, high-resolution image.

What this step does: Gives the Agent a clear list of services it is allowed to explain. For each service Use the public service name.

Add a short, customer-friendly description. Explain who the service is for and the usual next step.

Do not add private internal services, unapproved claims, or details that change frequently unless your team will keep them updated.

What this step does: Lets the Agent explain approved products, packages, or offers. Safe commercial wording Enter only prices that are already public and approved.

Say “starting from” when the final price depends on customer needs. Explain that custom quotes require a team member when appropriate.

Do not allow the Agent to promise discounts, refunds, or special terms.

What this step does: Defines the approved information the Agent may rely on. What to include Important public website pages.

Short notes about services, policies, and customer questions. Priority topics the Agent should explain first.

What to exclude Admin pages, private portals, draft pages, and internal documents. Outdated information or claims the company has not approved.

When information is missing, the Agent should say so and offer a human contact option.

What this step does: Helps the Agent answer frequent customer questions consistently. Good FAQ examples What services do you provide?

Which locations do you serve? How can I request a quote or booking?

When will a team member reply? Keep each answer short, accurate, and easy to understand.

Avoid copying long website pages into one answer.

What this step does: Helps the Agent identify visitors who may want a quote, booking, consultation, or follow-up. Useful questions Which service are you interested in?

What date or timeframe are you considering? Which location or route is involved?

How should the team contact you? Ask only necessary questions.

Do not pressure visitors or collect sensitive information that the business does not need.

What this step does: Tells the Agent when and where to send a visitor who needs a person. Send to a person when The visitor asks for a custom quote, exception, refund, or legal commitment.

The question is urgent, sensitive, or outside approved information. The visitor specifically asks to speak with the team.

Choose the route Contact page for general enquiries. Support page for existing-customer help.

Booking page for appointments or consultations. Human Inbox when the plan and settings allow it.

What this step does: Selects the languages the Agent may use with visitors. Select only languages your business is comfortable supporting.

Use automatic detection when visitors may start in different languages. Use a fixed primary language when consistent communication is more important.

The number of languages available depends on the active plan.

What this step does: Sets clear boundaries for safe customer conversations. Recommended rules Tell visitors that they are speaking with an AI Voice Agent.

Explain recording or transcription only when the feature is enabled. List topics that always require a person.

Prevent promises about legal outcomes, refunds, discounts, or special terms. Add the company’s public privacy direction.

Clear boundaries make the Agent more reliable and protect both the visitor and the business.

What this step does: Controls whether conversation text and audio may be kept for the Dashboard and follow-up. Transcripts: written conversation records.

Audio recordings: actual voice recordings, available only when the plan and policy allow them. Choose settings that match your privacy notice, customer expectations, and internal retention policy.

What this step does: Shows the exact information that will be submitted for the primary website. Check before continuing Company name, summary, and public contact details are correct.

Greeting and voice style sound natural. Services, offers, and FAQs are approved.

Human handoff and safety rules are complete. Branding previews are correct.

Edit anything that is unclear or incorrect before requesting publication verification.

What this step does: Creates optional Agent versions for other approved websites under the same workspace. Each domain receives its own Domain ID, profile, hosted page, and installation code.

All domains share the same plan allowance and wallet. You may skip this step and add more domains later in the Dashboard.

Add another domain only when it genuinely needs its own website identity or tailored customer information.

What this step does: Sends a second email code to confirm the exact reviewed setup before creation. Review the primary and any additional domain Agents.

Select Send publication code . Enter the code from the registered email.

Changing the reviewed information after verification requires a new publication code. This protects the owner from accidental or unauthorized changes.

What this step does: Sends the verified setup to WebsDocs for final creation. Before selecting Create Confirm that all information is approved for customer-facing use.

Confirm the website and domain Agents are correct. Confirm the branding images and colors are correct.

Confirm the handoff, privacy, and safety rules are complete. After successful creation, WebsDocs stores the profiles, creates the domain records and hosted pages, uploads branding, prepares installation packages, and links the workspace to its plan.

What this step means: WebsDocs successfully created the Voice workspace and its approved domain Agents. What you receive Dashboard access.

A hosted Agent page for each created domain. Floating, button, iframe, and platform installation options.

Site ID and Domain ID values for each website. A protected publication handover and agreement link.

The Agent is created, but the website installation and final controlled test still need to be completed.

What this step does: Connects the created Agent to the correct website. Choose an installation type Floating Agent: adds the standard launcher to the bottom corner of the website.

Button Agent: connects the Agent to your own “Talk to us” button. Hosted Agent: opens the complete branded Agent page on its own URL.

Premium iframe: places the full hosted Agent page inside a page on your website. Platform instructions: gives placement guidance for WordPress, Shopify, Wix, Squarespace, Webflow, Google Tag Manager, or plain HTML.

Important installation rule Use the installation code created for the selected domain. Every script must contain the matching Site ID and Domain ID .

Do not copy one domain’s code to a different website. Where to place the floating script Place it once on every page where the launcher should appear.

For normal HTML, place it before the closing tag. For a website builder, use the site-wide footer or body-end custom-code area.

Premium iframe Paste the complete iframe code into the page where the hosted Agent should appear. Keep allow="microphone" so voice can work.

The hosted page sends its height to the parent page so the iframe can resize automatically. The website must be one of the approved origins for that Domain ID.

Final test checklist Open the website in a private browser window. Confirm the correct company logo, banner, colors, and Agent name appear.

Open Chat and ask a question from the approved profile. Open Speak and allow microphone access.

Test the Human Inbox or handoff route. Check the Dashboard for the conversation and wallet usage.

Need help? Copy the exact error message or take a screenshot of the browser Console and Network tabs, then send it through Setup Support.

Use the Setup Support route with the activation/setup context, the exact step, visible error, and a screenshot that excludes passwords and OTPs. Do not create another workspace simply because one protected step is delayed.

Start with the wallet, selected model, live-session count, Human Inbox and retention policy. The overview uses runtime and D1 records; it does not invent a green status when data is missing.

Complete branding, a verified domain, approved services, FAQs, a prepaid wallet and the agreement record. The readiness score links operating work rather than acting as a cosmetic score.

The plan-limit meters show current resource counts against the active plan. Limits are enforced by the Dashboard worker, not by disabled browser buttons alone.

The company logo becomes the agent avatar. The brand name and primary label appear across the customer workspace and public voice experience.

PNG, JPEG and WebP assets are uploaded through the authenticated Dashboard worker into the branding R2 bucket. Sensitive uploads require fresh verification.

The browser provides intent. D1 entitlement, verified origins, wallet balance and the Realtime worker remain authoritative for every session.

Use concise, verifiable company facts. These are intended for the runtime instruction context, not unreviewed marketing claims.

Publish approved company facts to the Dashboard Worker. The Worker writes D1 first and synchronizes the runtime KV package so Chat and Speak use the updated profile.

Services, offers, FAQs and important links each have their own D1 table and plan limit. Use the tabs to keep the approved knowledge structured.

The left list shows the current approved records and the exact used-versus-limit meter. Remove stale records rather than adding contradictory versions.

Complete the fields in the right composer. The Dashboard worker rejects additions when the plan limit has been reached.

Enter the full HTTPS website URL. Setup begins without a bound client URL, so domain ownership is handled only after verified dashboard access.

A domain is not trusted merely because it was typed into the dashboard. Use the verification action and wait for a verified state before publishing the SDK.

Pro supports 1 domain, Business 3 and Enterprise 6. The server checks the entitlement before inserting another domain.

Normal and Advanced use the same subscription and universal SDK. The selected model changes the active-minute rate and applies to the next session.

The 7-day Pro trial is locked to Normal. The Dashboard worker rejects an Advanced selection even when browser controls are modified.

Add only the languages the business can actually support. The plan allows 2, 5 or 10 languages depending on entitlement.

Search by session ID, transcript content or visible metadata. Status filtering keeps active, completed and failed sessions separate.

A selected session combines transcript messages, runtime events, usage, recording and Human Inbox references when those records exist.

Transcript retention follows the plan. Audio and transcript policy are separate; a plan can retain text without recording audio.

Pro does not record audio. Business retains audio for 30 days and Enterprise for 90 days.

The recording policy badge reflects D1 entitlement.

The browser requests audio through the authenticated Dashboard worker. Direct R2 object keys and bucket credentials are never exposed.

Human Inbox keeps the verified visitor thread connected to the originating Chat or Speak session. Each case carries its status, priority, assignment and conversation lineage.

Accept the case before the visitor is told a person joined. Reply inside the protected widget thread, add internal notes, and keep the operational timeline complete.

Use Return to Agent when AI can continue the same conversation. Use Resolved after the requested work is complete, and Closed when no further response is expected.

Support Messages connects to the WebsDocs mail application through a Worker service binding. SMTP credentials are never sent to this page.

Select a message to display the protected thread and reply context. Inbox and Sent remain separate views.

The composer sends through the Dashboard worker using the active dashboard session and CSRF protection.

The selected 7-, 30-, or 90-day range is calculated by the Dashboard Worker from session, usage, handoff, and wallet records.

The outcome meter separates completed sessions, sessions with a human handoff, and unresolved sessions. It is an operational view, not a sales attribution claim.

The gauge estimates how much active runtime the current prepaid balance can support. Realtime performs the final admission and stop decisions.

Resource meters reveal where the workspace is approaching a configuration limit before a save is rejected.

Billing includes the complete time while a voice session is active: visitor speech, AI speech, pauses, model thinking and Worker operations.

Normal is $0.32 per active minute and Advanced is $0.75. There is no separate AI, routing, Worker or platform fee.

The usage table exposes session, model, quantity and charged credits so the dashboard can be reconciled with the wallet ledger.

The orbit shows available credits and health against the low-balance threshold. A zero usable balance prevents a new LLM session.

The same credit balance supports different active minutes because Advanced consumes weighted credits at the $0.75 rate.

The ledger lists grants, purchases, usage debits and adjustments. Setup owns the first grant and Realtime owns usage settlement.

Start with the plan, provider status, service state, renewal or end date, and any cancellation-at-period-end flag. These fields should tell the client whether service is active and what happens next.

Check the current period start and end, billing cadence, provider reference, renewal state, and plan name. Billing remains the authority for commercial status.

The action area should explain what the client can do now: open the billing portal, resume renewal, request cancellation, or request a plan change.

Plan changes, cancellation, reactivation, and billing-portal access require the authenticated dashboard session and may require fresh email verification.

Only invite people who should see transcripts, recordings, Human Inbox, support messages and billing information.

Pro supports 3 team members, Business 8 and Enterprise 20. Invitations and active members are reviewed together.

Inviting or removing a member requires fresh verification. The invitation link verifies the invited email, reuses an existing account password, or creates a password for a new account.

Dashboard access requires the registered email, one selected company workspace, the user password, and a fresh email verification code. A session is created only after both password and OTP succeed.

The password belongs to the email user identity. When that email can access several companies, each workspace appears once and the same password is used before the workspace-bound OTP check.

Forgot password verifies the registered email, issues a short-lived one-use reset authorization, replaces the user password, and revokes active dashboard sessions. The new password applies to every permitted company for that email.

TOTP provides an additional account security factor. The secret is encrypted in D1 and is shown only during setup.

Review active dashboard sessions and revoke any browser you no longer trust. Password changes and password recovery revoke other sessions automatically.

Password verification, OTP delivery, OTP verification, recovery, session revocation and sensitive changes remain visible in the account security timeline.

Every plan loads the same rtd-agent.js. Site ID, D1 entitlement, verified domain, selected model, published profile, and wallet determine the real behavior.

The customer website receives only the RTD SDK URL and Site ID. Plan, model, profile, wallet, recording, and feature policy remain server controlled.

The Hosted Agent URL is read from the published voice_hosted_pages record. It provides an immediate public Agent while the website connection is completed.

The loader injects Agent and button styles automatically. Copy the one-line button or use data-rtd-open-agent on an existing website button or link.

After publishing the loader, confirm the verified domain, wallet, Agent identity, Hosted Agent, and universal SDK checks in the installation panel.

Audit the client website or another public HTTP or HTTPS website. Local, private-network, and internal addresses are rejected before the Website Audit service is called.

Start with the overall score, audit state, scan time, tested URL, and the counts of critical issues, warnings, and passed checks. This is the client-facing answer before the technical detail.

Review SEO, performance, accessibility, security, mobile readiness, and other available category scores to identify the weakest business-impact area.

Critical issues and high-impact warnings should appear first with what is wrong, why it matters, the affected URL or asset, and the recommended fix.

Website suggestions should turn technical findings into practical next actions, including quick wins that can improve trust, discoverability, speed, accessibility, or conversion.

Use the technical section for headers, assets, connection checks, metadata, response details, and the evidence needed by a developer. It should support the summary rather than replace it.

Open a prior report to compare changes over time. Email delivery is optional and uses the verified account address.

Each workspace may start no more than 10 Website Audit scans in one hour. The remaining allowance is shown beside the form.

Start with whether an agreement is required, sent, viewed, signed, expired, or waiting for action. The status should make the client's next step obvious.

Review the agreement version, recipient or signatory, sent date, signed date, provider reference, and latest verified update from the Contracts service.

Use the agreement link to review or download the current contract when a verified URL is available. Never construct a contract URL from browser data.

Agreement status is important account information, but it does not silently suspend a paid agent. Any restriction remains an explicit server-side administrative action.

Start with total leads, new records, follow-ups due, qualified opportunities, and unresolved customer work. These metrics summarize operational demand rather than replacing the underlying records.

Use the pipeline to see how records move from new inquiry through qualification, follow-up, conversion, or closure. Investigate stages with unusually high volume or long dwell time.

The CRM trend chart shows whether lead and follow-up activity is rising or falling across the selected period. Use it with the lead table, not as a standalone conclusion.

The action panel should surface overdue follow-ups, unassigned records, high-intent leads, and other items that need a person now.

Use stage, intent, assignment, source, and follow-up filters to narrow the records that need attention. Keep the filter state visible so the result is understandable.

The lead metrics summarize total records, new leads, qualified leads, due follow-ups, and conversion signals for the current workspace.

Each row should expose identity, source, intent, stage, owner, latest activity, and next follow-up. Sensitive contact data remains protected by the authenticated dashboard.

The activity timeline combines security events with important dashboard and runtime activity while keeping secrets and full private contacts out of the response.

Use Refresh when reviewing a login, domain, model, team or subscription change so the latest D1 records are visible.

No. AI visibility tools mainly monitor whether AI systems mention a business.

ASG gives AI buyers an official hosted place to read approved public facts, ask live questions, follow business routes, start A2A sessions, and submit handoff, quote, or checkout intent.

Start by verifying your email in Studio. Choose or create a setup, select a package, prepare your private profile, and save and approve the review. Then complete checkout, wait for billing confirmation, activate the workspace and approve publication with the final email code.

Signup and draft preparation require no card and start no charge or trial. Completion time depends on email verification, your review and payment confirmation. Existing purchased or admin-issued codes remain supported through the separate code entry.

No. AI-facing routes are designed around approved public facts only.

They do not expose setup codes, OTPs, private dashboard records, payment data, internal notes, confidential client information, billing administration, or protected system controls.

No. ASG is hosted as a separate AI-readable gateway.

Your website can remain focused on human visitors while ASG carries the approved public profile, discovery files, live Ask, A2A routes, and buyer-intent paths.

Yes, when the client enables that intent door. ASG can accept safe checkout, quote, or handoff intent.

The business still controls the final payment, contract, identity check, approval, and human review process.

The ASG Client Visibility Dashboard can show profile status, AI activity, visitor proof, known and unknown agents, live usage, credits, buyer requests, intent events, install resources, safety settings, subscription status, and support routes.

No. Static discovery routes remain open, but live LLM reasoning uses prepaid ASG AI Credits.

The wallet keeps usage controlled and allows the dashboard to warn, limit, pause, or route requests to fallback when the available balance becomes low.

Approved static routes can include the ASG Live Profile, Pulse, llms.txt, agent card, schema, sitemap, robots signals, public services, public pricing notes, policy, contact routes, FAQs, and approved profile facts.

Credits are used when ASG performs live LLM reasoning, answers a public Ask request, produces an A2A reply, retrieves deeper approved context, explains services or pricing, applies policy rules, or evaluates buyer-intent routing.

Normal websites are designed mainly for people and may contain outdated, repeated, promotional, or sensitive information. ASG gives AI systems a cleaner route with approved public facts, defined boundaries, structured endpoints, and monitored activity.

The business controls the approved public facts entered during setup, including services, offers, FAQs, public pricing notes, contact paths, policies, blocked topics, tone direction, and handoff rules. ASG is designed to answer from that approved layer.

ASG should refuse, limit, or safely redirect private, unsafe, unsupported, or sensitive requests. It should not expose private records, admin data, OTPs, setup codes, payment details, confidential files, or protected system logic.

Handoff intent moves the request toward human review. Quote intent signals that the buyer wants pricing or a proposal.

Checkout intent signals readiness to move toward a purchase route when the business has enabled that door.

Yes. The client can disable checkout intent, keep it review-only, route it to a quote path, or connect it to an approved checkout route.

ASG does not force payment execution.

ASG can record public-safe visitor signals such as declared agent name, route activity, known or unknown classification, Ask events, A2A sessions, and intent events. Some traffic may remain unknown and can be reviewed in the dashboard.

The profile can include business identity, approved description, services, offers, FAQs, public pricing notes, contact routes, market and language direction, policy boundaries, handoff rules, Pulse, discovery files, public Ask, A2A routes, and intent doors.

Start with an email you control and your public business name. Prepare approved services, offers, FAQs, pricing notes, public contact routes and boundaries for AI answers. Website is optional; it is not the subscription identity.

The optional Help me fill this profile section offers category templates and website-import suggestions. Review and select only accurate details. Suggestions do not automatically save, publish, start billing or change your subscription domain.

Yes. Standard profile structure guidance is included with active memberships.

Agency, bulk, compliance-heavy, white-label, or unusually complex implementations may require a Custom Quote.

Yes. ASG can host public business profiles for different markets.

Results improve when the profile contains clear services, public routes, regional notes, supported languages, market boundaries, and safe handoff instructions.

Multilingual behavior depends on the model, profile content, and setup rules. ASG can include language and market direction so visiting AI systems understand which languages and regions the business intends to support.

Both. Business Membership supports one serious public AI profile.

Enterprise supports deeper coverage, more domains, higher usage, more users, and stronger controls. Agency and Custom plans support multi-profile and white-label needs.

Not for the hosted ASG profile itself. A developer may help when you want root discovery files, custom website signals, advanced routes, special integrations, or a deeper connection between ASG and your own systems.

Yes. Services, offers, pricing notes, FAQs, contact routes, policy wording, handoff rules, markets, and language direction can be reviewed and updated as the business changes.

ASG can record declared identity, known and unknown traffic signals, and suspicious behavior for review. Identity claims alone are not treated as proof, so safe boundaries, rate controls, and activity evidence remain important.

Buyer AI needs structured public facts, official service routes, safe questions, machine-readable pricing and policy direction, action paths, and proof. ASG gives those agents one controlled place to read, ask, compare, and submit intent.

Open ASG Studio and sign up or sign in with your email. Verify the secure email link, then choose an existing setup or create another. One email can manage multiple separate subscriptions. A website is optional.

Choose your package in Studio and prepare and review your profile before checkout. An eligible trial starts according to the checkout you confirm, not at signup. Review its duration, payment-method requirement, first paid charge and renewal price before confirming.

For a converting trial, cancel through the ASG Dashboard billing controls or provider portal before its recorded end to avoid the first paid charge. Keep the cancellation confirmation and effective date. Contact Support if the controls are unavailable.

Signup does not start a trial. Closing Studio, leaving a profile unpublished or changing its domain does not cancel an accepted trial or subscription. Access after cancellation follows the recorded entitlement; check your account status.

Eligible paid clients can buy approved top-up packs through ASG Dashboard. Paid top-ups are unavailable during the ASG trial. Select the correct subscription before confirming the price and credit amount.

Credits are granted after verified payment confirmation. Returning from checkout alone is not proof of a grant. ASG credits remain separate from the RTD and BizDesk wallet.

Static reads do not use credits. Failed provider calls, rejected abuse attempts, invalid requests, and blocked private-data requests should not consume successful-answer credits.

Live usage should be recorded only when billable LLM processing occurs.

The setup flow is designed to verify ownership and require approval of the public facts before publication. Clients remain responsible for the accuracy and authorization of the business information they submit.

A visiting agent can request an A2A session and receive approved scopes, allowed routes, denied private capabilities, session limits, and safe message endpoints. The handshake does not grant access to admin, payment, private-client, or database systems.

Custom pricing may apply to white-label portals, bulk profile creation, dedicated infrastructure, unusual compliance requirements, advanced identity checks, custom A2A routes, complex data migration, or direct integration with external business systems.

Review Watch is the ASG safety and quality report card. It summarizes suspicious behavior, blocked requests, repeated unknown patterns, claim-heavy questions, private-data attempts, admin-route attempts, and unusual activity around payment/action routes so the client can review meaningful pressure without treating every unknown visitor as dangerous.

No. Unknown means ASG does not yet have enough identity evidence to classify the source confidently.

Repeated suspicious behavior matters more than the label alone; use Review Watch and traffic patterns before escalating.

For the email signup flow, verify your secure email link and select the correct saved setup or create a new one. You can prepare a private draft before payment; a setup code is not required for this entry.

If you already have a purchased or admin-issued code, choose the existing-code entry and load its protected setup record. Check the authorized company, email, package and status before proceeding. Do not create another purchase just to use existing access.

Keep login links and setup codes private. Each setup has a permanent identity; its website is optional and does not identify the subscription.

New email signup and sign-in use a secure, one-use email link to open your private Studio account. This verification starts no charge or trial and does not publish a profile.

Existing setup-code access retains its own email OTP verification when requested. Follow the verification step shown for that entry. The final publication email code is a separate approval of the reviewed profile.

Never share login links, setup codes or OTPs. Email verification confirms access to the account; it is not proof of domain control or legal business identity.

In the email signup flow, choose a package and monthly or annual billing in Studio, then prepare your profile within that package’s limits. Saving the plan choice does not start billing or grant paid access.

Save and approve your profile review before checkout. Checkout shows the amount due, currency, taxes, offers, trial terms where eligible, and later renewal price. Workspace activation requires verified checkout confirmation or an applicable existing-code entitlement.

Server records determine access and limits. Do not create duplicate checkouts while confirmation is pending. Custom packages follow their recorded offer.

In the email signup flow, prepare and approve your profile first, then complete checkout. After confirmed entitlement, follow Studio’s password and workspace activation steps. Existing-code users follow the requirements attached to their authorized setup.

Activation creates or connects the private client workspace and its stable identity. It does not automatically publish your profile. Complete final review and email-code approval to publish.

Use the existing Dashboard credential when requested for an email that already owns a workspace. Keep passwords private. Each subscription remains separate even when several are managed through one email. Billing or trial time follows the confirmed checkout, even if publication is delayed.

Prepare your public business identity and summary in the private draft before checkout. Include only approved information suitable for publication. Website is optional; confirm the business name, industry, languages and descriptions.

You can use category starters and website-import suggestions, but review each selection before applying it. Applying suggestions only edits the current form; save and approve the draft through Studio. Do not treat suggested services, prices or policies as established business facts.

After workspace activation, the owner changes the subscription domain through Dashboard with security verification and within the plan’s limits. Domain changes preserve the same subscription. Never enter credentials, private contracts or confidential customer records in public profile fields.

Give AI systems and buyers safe, public routes to reach the business without exposing private contacts. This tab defines public email, phone, address, service area, location, timezone, and other approved contact details used for routing and trust.

Approved business email, phone, location, service area, and public contact details may appear in the profile and discovery routes. Personal mobile numbers, private home addresses, internal extensions, recovery contacts, and staff-only details remain private.

Add structured, approved services with clear outcomes, audiences, limits, and official action routes. Service entries help AI search and buyer agents answer what the business does without inventing capabilities from vague marketing text.

Approved service names, descriptions, categories, outcomes, and public URLs may be exposed through ASG routes. Internal delivery instructions, private rates, customer-specific terms, staff assignments, and confidential methods stay private.

Structure commerce-ready public offers without turning estimates or internal packages into binding promises. Offer entries give buyer agents clear names, descriptions, availability, official product links, and safe purchase or inquiry routes.

Offer titles, descriptions, availability, approved price wording, and action URLs can become public. Supplier costs, margins, unpublished discounts, private quotes, internal inventory notes, and customer-specific pricing remain private.

Tell ASG exactly when it may state a price, show a range, or route the buyer for a quote. Pricing rules reduce wrong AI promises by separating fixed public prices from estimates, variable work, regulated advice, taxes, and custom quotations.

Approved fixed prices, ranges, starting prices, pricing conditions, and quote instructions may become public. Internal cost calculations, margins, negotiated rates, customer invoices, discount authority, and billing records remain private.

Give ASG safe destinations for contact, booking, quotes, products, support, and checkout actions. Routes convert public discovery into official business actions while preventing AI from inventing forms, payment links, or support destinations.

Approved action URLs can appear in the profile, agent card, A2A replies, sample answers, and install pack. Admin panels, signed internal links, private payment sessions, staff tools, and authenticated customer portals remain private.

Add real customer questions and approved answers so routine requests can be answered consistently and at low cost. FAQ entries are the safest first answer source for common questions.

They help static ASG responses and reduce unnecessary live AI use. FAQ questions, answers, and topics may be published through the ASG profile and FAQ route.

Private cases, customer records, internal troubleshooting, legal strategy, account data, and confidential exceptions stay private.

Define what ASG may explain and what must remain private, restricted, uncertain, or human-reviewed. Boundaries protect the client and WebsDocs from data leakage, wrong promises, unsafe advice, and automated answers outside the approved public scope.

The public policy and high-level boundaries may be exposed so AI systems understand what ASG can and cannot answer. Internal enforcement logic, security controls, abuse evidence, private blocklists, credentials, and investigation details remain private.

Route high-risk, uncertain, private, regulated, or purchase-ready requests to an approved human channel. Handoff rules stop ASG from continuing when a person should review pricing, eligibility, complaints, private accounts, sensitive advice, or serious buyer intent.

Approved handoff instructions and public contact routes may be shown to buyers and AI agents. Internal escalation trees, staff schedules, private contacts, case notes, and investigation procedures remain private.

Prepare the public discovery links that show AI systems where the approved hosted business layer lives. The badge, Pulse link, profile JSON, llms.txt, agent card, sitemap, and related snippets connect the client website to WebsDocs-hosted ASG discovery.

The ASG badge and generated discovery URLs are designed to be public and machine-readable. Setup codes, dashboard credentials, internal API secrets, signed admin routes, and private files are never part of the install pack.

Review all public fields for accuracy, privacy, duplicates and plan limits. Save the draft and approve the review before starting checkout. The draft remains private; saving or approving it starts no charge or trial.

Complete checkout and wait for confirmed entitlement, then activate the workspace. Before requesting the final publication code, ensure the current draft is saved and its review is approved. Editing the draft requires a new review.

The final email code approves the reviewed version, not unsaved browser edits. Do not publish placeholders or unsupported claims. A checkout return screen alone does not confirm payment or publication.

After confirmed entitlement and workspace activation, save and approve the latest profile review. Request the final email code and use it to approve publication of that exact reviewed version.

The final code is separate from the email sign-in link or legacy setup verification. Changes to the draft require another review; use the latest valid publication code. Avoid repeated Publish clicks while the request is processing.

Only successfully published public fields become available through the profile and discovery routes. Passwords, session tokens, OTPs and billing records stay private. Delaying publication does not pause an accepted subscription or trial.

Verify the live ASG profile, Pulse, dashboard, discovery routes, badge, and install pack after publication. This final tab proves that the setup completed and gives the client and WebsDocs the permanent links needed for dashboard access, public discovery, support, and future maintenance.

The hosted profile, Pulse, public Ask, company JSON, FAQ, agent card, llms.txt, sitemap, badge, and approved action routes are public. Dashboard sessions, passwords, OTPs, setup records, billing, private files, support records, and admin operations remain private.

No. The setup guide treats Review as the quality gate and says to save the authoritative D1 draft before requesting final OTP.

The final OTP approves the exact saved draft, not unsaved browser changes.

Live Billing Core records for requests, plan changes, cancellations, renewals, and payments.

Review the agreement generated for this ASG workspace and follow its live completion status. The dashboard is checking the Contracts Worker for this company.

Reads, questions, visitors, requests, and ranked AI identities live together here.

Public Ask and A2A routes use only the approved ASG profile. Private dashboard, payment, OTP, and admin data remain blocked.

These buttons open the free static GET preview. Live POST answers remain credit-aware.

Gateway review, blocked claims, unknown traffic, and client-safe action status appear here.

Use these assets on the client website. Hosted ASG works before root install; root install strengthens ownership and discovery.

Use Copy to avoid broken snippets.

Business includes 1 owner, 2 administrators, and 5 regular users. Enterprise includes 1 owner, 5 administrators, and 20 regular users.

Pending invitations reserve a seat.

Owners may invite administrators, editors, or viewers. Administrators may invite editors and viewers.

Changing dashboard branding does not verify a domain, recompile the public profile, change the client slug, or touch billing. One fresh OTP/TOTP step-up covers both logo and banner changes for 15 minutes.

Website is optional during ASG signup and profile preparation. After workspace activation, the owner can replace the domain through Dashboard with email OTP or authenticator verification and within the plan’s domain limits. The client identity and subscription stay the same.

Normal business-domain verification is separate from hosted ASG access. A custom ASG hostname requires verification before routing. Importing profile suggestions from a website does not replace the subscription domain or prove domain ownership.

The client ID, client slug, billing site ID, Stripe customer, and subscription remain unchanged. Only the website, primary-domain reference, compiled profile URL, and Billing allowed origin are updated.

Scan any safe public website. ASG domain verification is not required.

Each ASG account receives 10 shared scans in a rolling two-hour window.

Live A2A, UCP, MCP, and seller-checkout status issued by the ASG gateway. No gateway secret is exposed in this browser.

Open or copy the canonical routes published by your gateway. Open this section to load protocol routes.

Choose any country. SMS is used where available; otherwise the code is sent to the verified ASG email.

Scan QR with Google Authenticator, Microsoft Authenticator, 1Password, or any TOTP app. Manual key and setup link are shown together.

The ASG Client Dashboard is the control room for a business AI Sales Gateway. It shows how AI agents, search systems, visitors, and buyer-style traffic interact with the client’s public AI-readable business profile.

It is not only a visitor counter. It helps the business understand which services are attracting attention, which questions are being asked, whether live AI answers are using credits, and whether anything needs review.

Read the dashboard in this order: first check the time window, then look at analytics, then registry, then LLM usage and credits, then review watch, and finally install/profile status. This gives a clean story: who came, what they wanted, what ASG answered, what it cost in credits, and what needs attention.

This section shows what is happening around the client’s AI Sales Gateway during the selected time window. It can include hosted gateway visits, Pulse opens, profile reads, live questions, A2A messages, lead signals, product/service interest, and the AI-readable pages that are getting the most attention.

Client action: if one service gets repeated interest, improve that service description, FAQ, pricing note, and call-to-action.

The registry groups visitors and AI traffic into useful identity buckets. Some systems are known providers, some are returning unknown visitors, and some are normal browser or crawler traffic.

Unknown does not automatically mean dangerous. It usually means ASG does not yet have enough repeat signals to classify the source confidently.

Client action: do not panic on unknowns. Watch repeat patterns.

If unknown traffic becomes heavy or strange, check Review Watch.

This section explains live answer usage. Static public discovery pages can be read without using live answer credits.

Credits are used when ASG has to generate a live answer, handle an A2A message, or process a deeper question using the client’s approved public business knowledge. Client action: if credits are being used quickly, check whether questions are useful buyer questions or noisy repeated traffic.

Review Watch is the safety and quality report card. It summarizes traffic that may need attention: suspicious behavior, blocked requests, repeated unknown patterns, claim-heavy questions, private-data attempts, admin-route attempts, or unusual activity around payment/action routes.

Client action: review the details, improve blocked-topic rules if needed, and escalate only when traffic is repeated or clearly abusive.

Credits control live ASG answer capacity. Public discovery pages such as Pulse, llms.txt, agent card, schema, and public profile routes remain open for AI discovery.

Credits are mainly for live answers, deeper Q&A, A2A messages, and buyer-style questions that need ASG to respond. Client action: use top-up when traffic is good and the business wants more answer capacity without upgrading the plan.

The profile is the approved public knowledge base for the business. ASG should only answer from this safe profile, approved FAQ, service descriptions, public contact rules, pricing notes, and allowed handoff routes.

Client action: update weak service descriptions before blaming traffic. AI can only sell clearly what the profile explains clearly.

ASG is designed around approved public knowledge. The client dashboard may show logs and records, but public AI routes must not expose private dashboard data, payment records, passwords, admin routes, database content, or confidential customer information.

Client action: keep public profile content useful, but never place secrets or private business records in public ASG fields.

Lead signals are not always a submitted form. In ASG, a lead signal can be repeated pricing interest, service comparison questions, booking-route checks, quote-route checks, action requests, or AI agents asking decision-style questions on behalf of a buyer.

Client action: when lead signals repeat, improve the matching service page and give a clear quote/contact path.

The selected time window changes the story. A small 24-hour window is good for testing.

A 7-day window is good for weekly review. A 30-day window is better for client reporting.

A 3-month window shows whether AI discovery is growing or fading. Client action: do not judge ASG only from one quiet day.

Use 7-day or 30-day view for better business reading.

Some dashboard and setup actions are protected by email OTP or profile-lock rules. This protects the client from accidental public profile changes and stops unauthorized updates to business identity, contact details, and publish status.

Client action: verify recovery mobile, enable authenticator if available, and keep the owner email correct.

Some panels depend on connected services. If billing, email or setup status is missing, check the reported connection status or contact Support before changing your account or purchasing again.

ASG Setup supports email verification and private drafts before checkout, followed by confirmed entitlement, workspace activation and final publication approval. Existing setup-code access remains supported. Checkout and billing services confirm commercial status; the browser cannot grant paid access.

The optional Studio website-import helper uses the audit service’s lightweight business-details endpoint. If unavailable, category templates and manual entry remain usable.

Static discovery assets such as the public profile, Pulse, llms.txt, agent card, schema, and other approved routes can be read as public information. Live Ask, A2A, and deeper generated responses use the live answer path and can consume ASG credits.

No. Recovery methods, OTPs, authenticator secrets, dashboard sessions, and security evidence remain private.

Public ASG routes use approved business information only.

Approved business knowledge is information the business is willing and authorized to use in customer-facing operation: company identity, services, offers, public pricing guidance, FAQs, policies, hours, locations, official links, support routes, and other verified facts. Draft internal notes, unsupported claims, passwords, private customer records, and confidential commercial data do not belong in the public knowledge layer.

Multiple conflicting versions make the Agent less reliable. RTD guide clients to keep structured knowledge clear, remove stale entries, and save one approved record.

ASG setup likewise warns against duplicate services, offers, and FAQ entries.

No. RTD deliberately separates profile saving/publication from knowledge indexing.

After an approved profile change, use Knowledge Search to check the live index and start Feed Agent only when a real knowledge update needs to be indexed.

Confirm that the latest profile was published, then confirm that the subsequent indexing job completed successfully. Profile publication and vector/search indexing are separate operations, so one can be current while the other is still waiting.

No. The RTD guide warns against repeatedly re-indexing unchanged content because it consumes resources without improving the Agent.

Search first, confirm whether the approved knowledge is actually stale, and only then start an update.

No. Public profile fields are for approved business information.

Private customer records, invoices, credentials, private files, internal procedures, staff-only notes, and account-specific information should remain behind authenticated routes.

It should not turn uncertainty into a confident invention. The safe behavior is to explain the limitation, ask a useful clarifying question, point to an approved public route, or offer the relevant human handoff/support path.

Not unless the business has explicitly approved a public rule that authorizes that exact commitment. RTD Studio guidance specifically warns against allowing the Agent to promise discounts, refunds, legal commitments, or special terms.

Account-specific exceptions should go to a human.

Structured FAQs provide a safe first-answer layer for common questions. They reduce ambiguity, keep wording consistent, and—in ASG—can reduce unnecessary live AI usage by letting routine public questions be answered from approved static content.

Include real recurring questions about services, locations, eligibility, booking, quotes, support boundaries, public pricing guidance, response expectations, cancellations, and the correct next action. Keep answers specific enough to help but not so broad that they create unsupported guarantees.

Typing a domain into a dashboard does not make it trusted. Verification connects the approved website origin to the correct customer/site identity and helps prevent a public Agent loader from being copied to an unrelated website.

Use the product's requested form. RTD domain controls normally work with the scheme and hostname rather than an individual page path.

RTD Studio may ask for the full main website during activation and then creates domain-specific installation identity.

The production origin may not have been added, verified, published, or matched to the correct Site/Domain identity. Check the dashboard Domains area before changing the Agent model or rewriting the loader.

Use the website's shared template or site-wide custom-code area so the universal loader is included once per page where the Agent should be available. Do not duplicate the same loader several times on one page.

Only public installation values belong in browser code: the approved public loader/SDK URL, Site ID or Domain ID where required, and supported public trigger values. Worker secrets, admin tokens, private service URLs, passwords, and signed internal links must stay off the website.

No. RTD Studio explicitly instructs clients to use the installation code created for the selected domain.

The matching Site ID and Domain ID belong to that website's approved origin.

It is the WebsDocs-hosted public Agent route created for the approved domain. It provides an immediate way to test or use the complete Agent while the business completes website installation.

It is a WebsDocs-hosted public route connected to the published RTD Site. It can be used for direct testing and access while the website loader is being installed or diagnosed.

The floating Agent injects a standard launcher, the button Agent connects RTD to an existing website button or link, and the iframe embeds the complete hosted Agent inside a page. All must use the correct domain-specific installation identity.

Voice requires browser microphone access. RTD Studio's installation guide keeps microphone permission in the iframe configuration so the embedded hosted Agent can request voice input when the user chooses Speak.

No. ASG is hosted as a separate AI-readable gateway.

The business website can remain focused on human visitors while the install pack points AI/search systems toward the approved hosted profile, Pulse, llms.txt, agent card, schema, and related discovery routes.

It is the public discovery package containing approved assets such as Pulse, llms.txt, agent card, schema, public profile routes, and recommended snippets. It should contain only public business knowledge, never dashboard data, payment records, credentials, or admin information.

Human Handoff is the controlled transition from an AI conversation to an authorized person when the request requires human authority, sensitive review, a custom decision, or the visitor explicitly asks for a person. The goal is continuation with context rather than forcing the visitor to start over.