Problem
KnowledgeInteractionContext introspects the handler signature to find validation_model and serialization_model, but then does nothing with them. The apply-them logic is duplicated verbatim across three methods in KnowledgeBase: call(), ask(), and post(). Each one independently does: "if serialization_model, convert inputs; call the operation; if validation_model, convert outputs."
The module that holds the knowledge about binding models doesn't use it — it's a shallow data-bag.
Proposed solution
Give KnowledgeInteractionContext a dispatch(binding_set) -> BindingSet method (for incoming ANSWER/REACT calls) and prepare_outgoing / parse_result helpers (for ASK/POST calls). call(), ask(), and post() on KnowledgeBase become single-line delegations.
Benefits
- All binding-model handling concentrates in one place (locality).
- Tests can target the dispatch logic directly, independent of the KB lifecycle.
KnowledgeBase sheds ~40 lines of repeated conversion logic.
Problem
KnowledgeInteractionContextintrospects the handler signature to findvalidation_modelandserialization_model, but then does nothing with them. The apply-them logic is duplicated verbatim across three methods inKnowledgeBase:call(),ask(), andpost(). Each one independently does: "if serialization_model, convert inputs; call the operation; if validation_model, convert outputs."The module that holds the knowledge about binding models doesn't use it — it's a shallow data-bag.
Proposed solution
Give
KnowledgeInteractionContextadispatch(binding_set) -> BindingSetmethod (for incoming ANSWER/REACT calls) andprepare_outgoing/parse_resulthelpers (for ASK/POST calls).call(),ask(), andpost()onKnowledgeBasebecome single-line delegations.Benefits
KnowledgeBasesheds ~40 lines of repeated conversion logic.