Package com.tnsai.agents.validation
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 TypeMethodDescriptionid()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
-