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.