In the early days of AI tool-calling, we relied on a wing and a prayer. We gave an LLM a docstring and hoped it would guess the right types. If the Agent sent a string instead of a UUID, or a float instead of an integer, the system would crash, returning a generic 500 error that left the Agent stuck in an infinite retry loop. This is Parameter Hallucination , and it is the single biggest obstacle to building production-grade AI systems. At apcore , we solve this by making Strict Schema Enforcement a protocol-level requirement. In this twelfth article of our series, we dive into why data contracts are the only way to build a reliable Cognitive Interface. Why JSON Schema Draft 2020-12? When we designed apcore, we didn't want to invent a new schema language. We chose JSON Schema Draft 2020-12 . Why? Because it is the "Universal Vocabulary" of the modern web. It is language-agnostic, widely supported, and incredibly expressive. By standardizing on this draft, we ensure: Cross-Language Consistency : A schema defined in your Python backend is validated with the exact same logic in your Rust microservice. Rich Polymorphism : We can use oneOf and anyOf to define complex inputs that an LLM can actually reason about. Self-Contained Definitions : With $ref resolution, apcore ensures that the LLM always receives a single, dereferenced schema, removing the need for the model to "fetch" external definitions. Mandatory Perception In apcore, a module cannot exist without an input_schema . This isn't a suggestion; it’s an enforcement in the Registry . By forcing developers to define the input contract upfront, we create a Safe Zone for the AI Agent. The Agent no longer has to "guess" if a field is required or what its regex pattern is. It "perceives" the contract directly from the module metadata. The "Strict" Mode apcore encourages the use of additionalProperties: false . This tells the LLM: "Do not hallucinate extra parameters. Only send exactly what is defined here." This small architectural choice significantly reduces token noise and increases the success rate of complex tool calls. The Execution Pipeline: Step 6 The power of strict schemas is best seen in Step 6 of the apcore Execution Pipeline: Input Validation . Before your business logic ever touches the data, the apcore Executor runs a full schema validation. If the LLM makes a mistake—sending a string instead of a number—the Executor halts execution immediately. But here is the clever part: instead of a stack trace, it returns a Structured Validation Error . { "code" : "SCHEMA_VALIDATION_ERROR" , "message" : "Input validation failed" , "details" : { "field" : "user_id" , "reason" : "not a valid UUID" }, "ai_guidance" : "The user_id must be a UUID format. Please re-check the user record and try again." } This error informs the Agent exactly what went wrong, allowing it to self-correct and retry without human intervention. Conclusion: Engineering the Contract If you want reliable AI Agents, you must stop "Prompting" your tools and start Engineering your Contracts . Strict schema enforcement is not about adding friction; it’s about providing the semantic clarity that AI needs to act autonomously and safely. Next, we’ll move from syntax to semantics: Behavioral Annotations. We’ll look at how 'readonly' and 'destructive' guide the LLM's planning process. This is Article #12 of the **apcore: Building the AI-Perceivable World * series. Reliability is a design choice.* GitHub : aiperceivable/apcore