Proposal March 2025–Present
Lending policy via MCP
An architecture exploration: reuse a versioned evaluation while keeping policy changes behind a separate human decision.
My role I explored a reusable policy boundary from the EduLoans rule model and reviewed how feedback could inform a separately approved change.
The experience
If a chat and reviewer tool depend on the same lending policy, separate rule implementations can disagree or require duplicate updates. I explored a common evaluation boundary; cross-interface demand and the choice of transport still need validation.
Reuse an evaluation, not an interface
I proposed letting intended clients—the student interaction, reviewer tools and possible future interfaces—ask the same versioned lending-policy service for an evaluation. The architecture direction places two business-rule engines behind one Model Context Protocol (MCP) server. A business-rule engine applies the explicit eligibility and scoring policy; MCP is one possible interface for exposing that capability to tool-using clients.
An illustrative contract takes an authorized, verified case and an explicit product and policy version. A chat and a reviewer could present the answer differently while receiving the same pre-check reasons and missing-input flags. This is a proposed example, not an executed cross-client comparison or a lender approval.
A conventional service API is a real alternative. Shared evaluation does not require MCP by itself. MCP would earn its added interface and authorization work only if intended tool-using clients need it and the service can demonstrate consistent versioned behaviour. That choice remains unresolved rather than being presented as an architectural inevitability.
Feedback requests review; it does not change policy
A lender rejection might indicate missing information, unsuitable routing or an outdated rule. In an illustrative review, the first task is to identify which explanation fits the original case and policy version. A rejection should create evidence for investigation; it should not silently alter the next applicant’s evaluation.
I separated consumer evaluation from privileged policy change. Feedback can create a review item, but approval belongs to a separately authorized human workflow. The precise owner, operating procedure, version history and rollback mechanism still need to be defined and tested. Ordinary applicant clients must not inherit that authority.
A system can explain today’s evaluation without being allowed to rewrite tomorrow’s policy. Before a release claim, I would require consistent results for authorized inputs and versions, explicit failure handling without fabricated decisions, and reviewed changes with rollback. These are proposed checks, not measured results.
What exists and what remains unverified
What exists is an architecture direction and later authored contract/control examples. Live MCP wiring, consumer reuse, production authorization and the approval/rollback process are unverified. This exploration claims no achieved business result, live integration or automatic policy-retuning capability.
Sources & technical detail
Original artifacts, detailed tables and source notes.