Interface Validator

All Known Subinterfaces:
ReachabilityValidator
All Known Implementing Classes:
ActionNameCollisionValidator, CapabilityClasspathValidator, ContractExpressionValidator, LLMCapabilityValidator, LLMHealthcheckValidator, LlmPresenceValidator, MCPServerReachabilityValidator, MemoryStoreReachabilityValidator, ResilienceConfigValidator, RolesPresentValidator, TenantScopeValidator, ToolApprovalValidator

public interface Validator
Pluggable pre-flight check run during AgentBuilder.build() (issue #85).

Validators receive a frozen view of the agent configuration via ValidationContext and return zero-or-more ValidationIssues. They must be pure functions of the input — no I/O, no side effects, no thread-local mutation. Network reachability checks (MCP servers, memory stores) belong to a separate "deep validation" phase that is opt-in; the default build() only runs static / metadata-driven validators.

Validators are registered programmatically in AgentBuilder's default pipeline (the small fixed set shipped with the framework). A ServiceLoader-based extension point can be added in a follow-up PR if external consumers need to inject custom rules.

Naming conventions

  • Validator class: <Concern>Validator — e.g. LlmPresenceValidator
  • Issue code: AGENT-V<NNN> — three-digit, stable across releases
Since:
0.5.0 (issue #85)
  • Method Summary

    Modifier and Type
    Method
    Description
    id()
    Short, stable id for logging and test assertions (e.g.
    Inspect the agent configuration and return any issues detected.
  • Method Details

    • id

      String id()
      Short, stable id for logging and test assertions (e.g. "llm-presence").
    • validate

      Inspect the agent configuration and return any issues detected. Returning an empty list means "no problems found by this validator".
      Parameters:
      ctx - frozen view of the agent under construction
      Returns:
      zero-or-more issues; never null