To score options for an LLM decision within the **Liminality** context, you need a structured scoring pipeline. This setup uses your existing Airtable, Asana, and HubSpot toolkits for data grounding and your MCP architecture for routing.
Here is the required structure for scoring options:
### 1. Define Scoring Criteria (Grounding) The criteria must be explicit and grounded in real tools before the LLM scores. * **Action:** Use **Airtable** or **HubSpot** to define the scoring schema, such as `relevance_score`, `feasibility_score`, and `cost_estimate`. * **Liminality Role:** Decompose the user’s high-level question into sub-questions that map to these criteria. If the question is "Which vendor to choose?", break it down into "What is the cost?" (HubSpot/CRM data) and "What is the SLA?" (Airtable data).
### 2. Retrieve Grounded Data (Tool Use) The LLM must not hallucinate scores. It must use your **connected toolkits** to fetch the data required for scoring. * **Action:** Use **MCP (Model Context Protocol)** to route sub-questions to the correct tool. * *Example:* Route "What is the current budget?" to **HubSpot** or **Google Sheets** (via **Google Drive**). * *Example:* Route "What is the project status?" to **Asana**. * **Liminality Role:** Your MCP server acts as the router, ensuring the LLM calls the correct tool for each scoring dimension.
### 3. Calculate/Assign Scores (LLM Logic) Once data is retrieved, the LLM assigns scores based on the predefined criteria. * **Action:** Prompt the LLM with the criteria and the retrieved data. * *Prompt Structure:* "Score Option A on a scale of 1-10 for 'Cost Efficiency' based on the following HubSpot data: [Data]. Score Option A on 'Feasibility' based on Asana data: [Data]." * **Liminality Role:** Ensure the decomposition is complete so no scoring dimension is missed. If a sub-question cannot be answered by a tool, flag it as **MISSING** and ask the user for clarification rather than guessing.
### 4. Aggregate and Rank (Decision) Combine the individual scores into a final decision metric. * **Action:** Use a weighted average or a rule-based filter, such as "Discard any option with a feasibility score < 5". * **Liminality Role:** Return the ranked options as a "reusable route" for downstream agents or human users.
### 5. Validation and Feedback Loop * **Action:** Log the decision and the scores in **Airtable** or **HubSpot** for future model training or audit. * **Liminality Role:** Store the successful routing path in your **Liminality MCP** registry to improve future decompositions.
### Key Constraints & Flags * **Contradiction Check:** If the retrieved data from **HubSpot** contradicts **Airtable** (e.g., different budget figures), flag this as a **CONTRADICTION** and ask the user which source is authoritative. * **Missing Data:** If a required scoring criterion (e.g., "Legal Compliance") has no corresponding tool in your **connected toolkits**, ask the user: "Which tool should provide the 'Legal Compliance' data for scoring?" * **Pending Action:** Any write action (e.g., updating a score in **Airtable**) requires user confirmation. Do not auto-write scores without approval.
### Summary of Steps for Liminality Implementation 1. **Decompose:** Break the decision question into scoring dimensions. 2. **Route:** Use **MCP** to fetch data from **HubSpot**, **Asana**, **Airtable**, etc. 3. **Score:** LLM assigns scores based on fetched data and predefined criteria. 4. **Aggregate:** Rank options. 5. **Log:** Store results in **Airtable**/HubSpot (pending user approval).
This approach ensures that scoring is grounded, traceable, and aligned with your **Liminality** architecture of decomposition and routing.
This answer was worked out by Liminality — Physea's engine that decomposes a request, grounds each part to a real tool, and returns a reusable, checkable route.
Connect it over MCP: https://mcp.physea.ai/mcp · physea.ai