Problem
A generated answer can look plausible while using the wrong facts, crossing a modelling boundary, or calling a tool whose contract is too vague to constrain behavior. The implementation makes the permitted knowledge, reasoning steps, and tool inputs visible before trusting the output.
Constraints
- The retrieval boundary must be explicit enough for a reviewer to see why a fact was eligible.
- Reasoning should expose accepted and rejected facts rather than return only a fluent answer.
- Agent tools need precise descriptions, required fields, bounded values, and safe sample calls.
- Public experiments should run locally where practical and avoid requiring private data or API credentials.
Architecture
- Data and contentStart from public or generated records whose provenance can be stated and inspected.
- Explicit ontologyRepresent stop types, places, records, and relationships as a graph with named modelling choices.
- Retrieval boundaryA selected rule determines which graph relationships a grounded answer may traverse.
- Explainable reasoningCandidate facts are checked against rules and returned with an acceptance or rejection explanation.
- Semantic quality checksEmbedding-based comparison surfaces similar, repeated, unusual, or potentially incorrect labels.
- Constrained agent contractMCP tool descriptions and JSON Schemas are checked for ambiguity, missing requirements, unsafe choices, and invalid samples.
Decisions
Treat ontology as a policy boundary
ChoiceThe modelled relationships define what retrieval may use, and changing one relationship changes the eligible grounding set visibly.
Trade-offExplicit modelling requires review and maintenance. In return, a changed answer can be traced to a changed rule instead of an opaque model response.
Separate retrieval from reasoning
ChoiceRetrieval selects bounded facts; a separate rule-aware step explains why a proposed fact is accepted or rejected.
Trade-offThe pipeline has more stages and more failure states, but each stage can be inspected and tested independently.
Validate the complete agent sample
ChoiceThe tool checker validates generated arguments against the complete root schema, including nested, union, recursive, and boolean schema nodes.
Trade-offStrict validation rejects descriptions that a permissive agent might guess through. That friction is intentional when the contract is the safety boundary.
Verification
Open the implementation or run the bounded behavior directly.
Limitations
- The demonstrations use public or generated data and bounded examples; they do not claim production model quality, latency, cost, or availability.
- The graph and rules are intentionally small enough to inspect and do not establish governance at organizational scale.
- Local and on-device execution improves inspectability and privacy for these examples but is not presented as the correct deployment model for every workload.