Supporting evidence
Lending policy via MCP
The complete artifacts and detailed records behind the account. Current public references, original work and proposed designs retain their labels.
Detailed material
The challenge
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.
One proposed policy boundary
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.
Diagnose feedback before changing 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.
Impact and its limits
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.
Explain a decision without rewriting the rule
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.
The contract and the conventional API alternative
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.
Consumer evaluation is not administrative approval
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.
Evaluation and release validation — proposed
Proposed, not executed: consistent evaluation for authorized input and policy versions; explicit failure and authorization handling; reviewed policy changes with rollback. The detailed scenarios follow the illustrative contract, not a deployed service. Fixtures and acceptance thresholds remain to be agreed.
Scroll across to see every column.
| Scenario | Expected behaviour | Available evidence | Status |
|---|---|---|---|
| Tool selection | Select the intended policy engine for the consumer and lender context; do not fabricate an available tool or policy result. | Existing: proposed one-server/two-BRE architecture and shared evaluation direction. No executed MCP tool-selection tests are available. Proposed: routing fixtures including ambiguous and unavailable-tool cases, with consistent answers across consuming interfaces. | Proposed — not executed |
| Arguments and schema versions | Validate required applicant/lender arguments and the rule/schema version before evaluation; preserve caller identity in the audit record. | Existing: shared-request/result system diagram and rule-source direction. No executable contract-test report is available. Proposed: typed schema fixtures, missing/extra arguments and version-mismatch checks. | Proposed — not executed |
| Malformed or unauthorised requests | Reject malformed and out-of-scope calls explicitly; do not expose another role’s case or return an invented decision. | Existing: proposed interface, reviewer and lender boundaries. No adversarial access-test results are available. Proposed: role-scoped malformed requests, audit inspection and permission-boundary tests. | Proposed — not executed |
| Failure handling | On timeout or an unavailable dependency, return an explicit recoverable failure rather than a made-up result; bound retry behaviour. | Existing: architecture proposal only; live failure behaviour is not established. Proposed: timeout, retry and unavailable-dependency scenarios with recorded behaviour before release. | Proposed — not executed |
| Unapproved policy changes | A rejection or override must not change active policy without an identified owner and human approval. | Existing: proposed separation of evaluation, reviewed feedback and human approval. No operating approval mechanism is verified. Proposed: attempted unapproved updates and approval/ownership checks. | Proposed — not executed |
| Approved feedback, versioning and rollback | Review rejection/override evidence, record the approved rule version and demonstrate rollback before a changed policy affects later cases. | Existing: feedback workstream describes rejections and manual underwriter overrides as review inputs. Production retuning is not established. Proposed: reviewed change examples, audit trail, version transitions and rollback tests. | Proposed — not executed |
The test sets, baselines and release thresholds must be agreed before execution. This table records proposed validation work.
The proposed tool is an evaluator, not an approval authority
Later authored reference design, dated 14 October 2026: an authorized verified case, product/engine and explicit policy version produce a pre-check, reasons and missing inputs. A pre-check is not lender approval or disbursement. The operation names below are examples, not a deployed manifest.
Consumer evaluation and policy inspection are separate from permitted feedback submission. Administrative policy approval belongs to a separately authorized human process and is excluded from ordinary applicant clients. The cited MCP revision supplies protocol context; it does not verify this architecture’s implementation.
Scroll across to see every column.
| Operation / actor | Required boundary | Returned information |
|---|---|---|
| evaluate_lender_policy — permitted consumer | Authorised case reference, selected product/engine, verified input snapshot and explicit rule version. | Pre-check result, reason codes, missing inputs and evaluated version; never a lender sanction or disbursement claim. |
| inspect_policy_version — permitted consumer | Read access to the relevant product/lender policy, without applicant-wide or administrative access. | Policy provenance, active version and effective conditions; no secret or raw borrower document. |
| record_outcome_feedback — permitted reviewer/feedback source | Separately permitted case outcome and lender/reviewer reason, attached to the originating evaluation. | A review item with its evidence; this operation does not change active policy. |
| approve_policy_change — separately authorized human administration | An explicitly authorised human owner and reviewed change record; exclude it from an ordinary applicant tool set. | A versioned approval/audit event and rollback reference, if implemented and validated. |
These operation names are authored examples. The source does not supply actual tool manifests, method names, production permissions or execution traces.
Notes and sources
- Evidence: the EduLoans working-guide architecture direction, followed by authored contract/control examples dated 14 October 2026. The protocol references inform those examples rather than establish historical deployment.
- No live manifests, production permissions, execution traces, cross-interface reuse results or approved-change/rollback records are published. Consumer need and MCP versus a conventional service API remain design questions.
Proposed validation plan · Authored portfolio plan; not executed results
Authored policy contract and official MCP tools specification · 14 October 2026 · Released MCP 2026-07-28; new reference design, no live MCP release established
Official MCP authorisation and security references · 14 October 2026 · Released 2026-07-28 HTTP authorisation; authored application of controls, not a deployed security assertion