Feature: Add domain hallucination guard for URL, domain, and GitHub repository verification

[Yang-1234-web]

Did you check the docs?

• I have read all the NeMo-Guardrails docs

Is your feature request related to a problem? Please describe.

Large language models often generate fabricated or misleading external references, including non-existent URLs, fake documentation pages, invalid domains, and non-existent GitHub repositories. These failures are difficult to catch with generic hallucination self-checking because a model may consistently repeat the same fabricated link.

This issue follows up on #1987 and #1993. Both issues described the need for a domain/link verification guard, but the current implementation has been reorganized around the NeMo Guardrails library layout and includes more complete extraction, verification, scoring, decision, and test coverage.

Describe the solution you'd like

The guard would analyze model outputs, extract external references, verify them with external evidence, and return a structured decision.
The current implementation includes:
URL, domain, and GitHub repository extraction
DNS verification
HTTP reachability checks
TLS verification
WHOIS/RDAP checks
GitHub repository existence checks
trusted / blacklisted domain and repository knowledge base
risk scoring and recalibration
final actions: pass, warn, refine, or block
optional expert review through a configured LLM
The main files are:
nemoguardrails/library/domain_hallucination/actions.py
nemoguardrails/library/domain_hallucination/extractors.py
nemoguardrails/library/domain_hallucination/verification.py
nemoguardrails/library/domain_hallucination/checkers.py
nemoguardrails/library/domain_hallucination/scoring.py
nemoguardrails/library/domain_hallucination/decision.py
nemoguardrails/library/domain_hallucination/expert_review.py
nemoguardrails/library/domain_hallucination/config.py
nemoguardrails/library/domain_hallucination/kb.py
nemoguardrails/library/domain_hallucination/flows.co
The guard supports configurable verification levels:
none: extraction and local checks only
dns: DNS resolution checks
http: DNS plus HTTP reachability checks
full: DNS, HTTP, TLS, WHOIS/RDAP, and GitHub repository checks

Describe alternatives you've considered

I considered relying only on the existing hallucination self-checking flow, but that approach is not ideal for fabricated URLs and repositories. A model can repeat the same fake link consistently, so semantic self-checking alone may not catch the issue.

I also considered implementing this as an external application-level utility instead of a NeMo Guardrails library module. However, this behavior fits naturally as an output rail because it can inspect generated answers before they are returned to the user.

Another alternative is to use only an LLM-based expert review. I kept that as optional because hard evidence from DNS, HTTP, TLS, WHOIS/RDAP, and GitHub API checks should not depend entirely on another model call.

Additional context

No response

[Yang-1234-web]

Additional context:

The current branch includes focused tests under:

tests/library/domain_hallucination/

The tests cover extraction, DNS/HTTP/TLS/WHOIS/GitHub verification behavior, issue aggregation, scoring, decisions, configuration, expert review, and action-level integration with mocked verification calls.

Suggested validation commands:

poetry run pytest tests/library/domain_hallucination -q
pre-commit run --all-files

I also ran offline experiments to understand the behavior before preparing a cleaned PR. The experiments suggest that this guard is useful for link/domain/repository hallucination cases, but I would keep the benchmark files separate from the runtime library unless maintainers want them included.

Open questions for maintainers:

• Is nemoguardrails/library/domain_hallucination/ the preferred location?
• Should full network verification stay opt-in because of latency and API limits?
• Is domain_hallucination the preferred name, or would link_verification / external_reference_verification be better?
• Should expert review remain advisory-only, or should it be allowed to affect enforcement under explicit configuration?