Lesson 2 - Build a Platform Shortlist

Module 5, Unit 2 | Lesson 2 of 3

By the end of this lesson, you will be able to:

• Translate your L2.1 modality decision into practical platform requirements (K8, S27)
• Explain the difference between model capability, platform route and implementation constraints (K8, K25)
• Build a shortlist of realistic platform routes using current primary sources (K25, S25)
• Record evidence, unknowns and disqualifying constraints before making a recommendation (K8, S27)
• Upgrade your Commit Log Agent so it can review shortlist evidence and prepare GitHub-ready updates (S27)

In L2.1, you made a routing decision: does this task need text-only, OCR-first, a multimodal model, or human review? That answer is the foundation everything in this lesson builds on. It tells you which class of platform could work — and it rules out the ones that could not.

Now comes the harder part: turning that routing decision into a shortlist of realistic candidates backed by evidence.

Most AI platform decisions go wrong at this stage. Not because the wrong tool was chosen, but because the question was too vague. "Which AI platform is best?" is not a useful question. It has no answer — it depends entirely on what you need, what constraints you are working within, and what evidence you have gathered.

That is the question this lesson answers. A good shortlist is not a list of impressive tools. It is a disciplined narrowing of the field, grounded in your L2.1 route decision and your real workplace constraints.

What you will build

By the end of this lesson you will have one evidence file:

module-5/unit-2/l2_2_platform_shortlist.md

It will contain:

• Your route brief carried forward from L2.1
• Platform requirements written from the task rather than from provider marketing
• A source log showing exactly what you checked and when
• A shortlist table with at least two realistic candidates
• A disqualifier pass identifying what could rule each option out
• The open questions that must be answered before the full evaluation in L2.3

This is not a repeat of the workflow mapping from earlier modules. You are not mapping the business process again. You are producing the technical evidence that determines which AI platform routes are worth taking seriously.

Key Idea - Route, Platform, Provider

These words are easy to blur together. Keep them separate.

A provider can look impressive and still be the wrong choice. The professional move is to make the route explicit first, then ask which platform routes can support it safely.

Coach Cora

A shortlist is not a wish list. If your L2.1 evidence says OCR-first, a full multimodal model might still be interesting, but it is no longer the default. The strongest platform choices are often the ones that remove unnecessary complexity.

Platform Routes You May Need

A platform route is the class of technical service that supports your L2.1 route decision — not a specific provider.

Use the table below to choose the routes that deserve evidence gathering. You do not need every route. You need the routes that match your L2.1 decision and your workplace constraints.

Agent frameworks sit above these choices. They can orchestrate model calls, tools and memory, but they do not remove the need to select the right model and data-processing route.

Curious Cat

In 2023, a widely-cited benchmark showed one AI model outperforming several competitors by a large margin. Researchers later found the evaluation had been run on a version of the model specifically tuned on the benchmark dataset — a practice known as benchmark contamination. The model that "won" performed significantly worse on real tasks. Every major AI provider publishes benchmarks. Almost none of them tell you what their model cannot do, where it fails, or what it costs at the volume you actually need. Your source log — checking the primary documentation yourself, dated — is the only thing that separates the evidence from the marketing.

Build Part 1 - Create the Shortlist File

Create this file inside your AI Projects repository:

module-5/unit-2/l2_2_platform_shortlist.md

Start with this template:

# L2.2 Platform Shortlist

## Route brief from L2.1
- L2.1 modality decision file:
- Recommended route:
- Why this route was recommended:
- Evidence that visual layout matters or does not matter:
- Evidence that OCR-first was considered:
- Sensitive-data, quality or approval constraints:

## Platform requirements
- The platform route must support:
- The platform route must avoid:
- Data handling requirements:
- Integration requirements:
- Cost or usage constraints:
- Human review requirements:

## Source log
| Source | What I checked | Date checked | What it proves | Link or private reference |
|---|---|---|---|---|
|  |  |  |  |  |

## Candidate shortlist
| Candidate | Platform route | Why it fits the L2.1 route | Main concern | Evidence still needed | Decision |
|---|---|---|---|---|---|
|  |  |  |  |  | keep / reject / needs more evidence |
|  |  |  |  |  | keep / reject / needs more evidence |

## Disqualifier pass
| Candidate | Possible disqualifier | Evidence found | Status | What I will do next |
|---|---|---|---|---|
|  |  |  | pass / fail / unknown |  |

## Questions before L2.3
- [question to resolve]

Keep this file safe to share. Do not include customer names, employee records, API keys, private screenshots, supplier contracts or confidential policy text. If a source is internal, use a safe reference such as internal cloud policy checked with line manager.

Build Part 2 - Carry Forward the L2.1 Evidence

Complete the Route brief from L2.1 before you open provider pages.

This forces the shortlist to start from the task. For example:

• If L2.1 recommended text-only, do not shortlist image-processing services unless there is a new reason.
• If L2.1 recommended OCR-first, include at least one OCR or document-processing route.
• If L2.1 recommended multimodal candidate, look for evidence about image input support, file limits, cost and data handling.
• If L2.1 recommended human review, your shortlist may focus on approved internal routes, manual review tools or conditions for a future automation.

Write the route brief in plain English. A future reviewer should understand why you are evaluating these platform routes without rereading the whole notebook.

Build Part 3 - Gather Current Evidence

Use primary sources wherever possible. A primary source is the organisation or provider speaking for itself: official documentation, pricing pages, security pages, data processing terms, SDK documentation or internal approved-technology guidance.

For each candidate, try to collect evidence for five questions:

1. Capability: Can it support the route from L2.1?
2. Data handling: Where does data go, and what is logged or retained?
3. Cost and limits: How is usage charged, and what rate or file limits matter?
4. Integration: How would your code or workflow connect to it?
5. Control: How can low confidence, errors or sensitive cases be handed to a human?

Add every useful source to the source log. Do not just paste links. Explain what each source proves.

Example:

| Source | What I checked | Date checked | What it proves | Link or private reference |
|---|---|---|---|---|
| Provider pricing page | Image and text processing pricing | 2026-06-25 | Gives the charging unit I need for the L2.3 cost criterion. | [link] |
| Internal approved tools list | Whether this route is already permitted | 2026-06-25 | Shows whether the route is realistic in my organisation. | private internal reference |

Build Part 4 - Build the Candidate Rows

Choose at least two realistic candidates. Three is useful if the evidence is available, but do not add a weak candidate just to fill the table.

Each candidate row must answer:

• Why it fits the L2.1 route: connect it to text-only, OCR-first, multimodal or human review.
• Main concern: name the specific risk or missing evidence.
• Evidence still needed: write what must be checked before L2.3.
• Decision: choose keep, reject or needs more evidence.

Example:

| Candidate | Platform route | Why it fits the L2.1 route | Main concern | Evidence still needed | Decision |
|---|---|---|---|---|---|
| Approved OCR service plus text model | OCR or document-processing service plus text model | L2.1 showed reliable text extraction is enough for the scanned-form route. | Need to confirm low-confidence handoff and regional processing. | Current data handling terms and sample extraction quality. | needs more evidence |
| General multimodal model API | Third-party model API | Could process the original image directly if OCR fails. | May add unnecessary cost and external data exposure. | Data handling terms, file limits and whether visual reasoning improves output. | needs more evidence |

Build Part 5 - Run the Disqualifier Pass

Before you move to L2.3, deliberately look for reasons each candidate might be unsuitable.

A disqualifier is stronger than a weakness. It is something that could make the route unacceptable for this project. For example:

• the data cannot be processed in an approved environment
• the service does not support the file type you need
• there is no safe human-review route for low-confidence outputs
• the organisation does not permit the provider
• the cost model cannot support realistic usage
• the platform cannot provide evidence or logs needed for review

Use this table:

| Candidate | Possible disqualifier | Evidence found | Status | What I will do next |
|---|---|---|---|---|
|  |  |  | pass / fail / unknown |  |

If the status is unknown, do not pretend it is fine. Carry it into L2.3 as an open question or hard constraint.

Challenge Chase

Pick one platform route from the table above that sounds impressive but does not actually fit your L2.1 decision. Add it to your shortlist, then mark it as rejected and write two sentences explaining exactly why — not "it's too complex" but something specific: the data handling terms don't meet your organisation's requirements, or the route adds a processing step that OCR-first already makes unnecessary. A shortlist that only includes safe options you already like is not a real evaluation. Showing you considered something and ruled it out — with a reason — is what professional judgement looks like.

Upgrade Your Commit Log Agent

Open your commit-log-agent.md file. Add this reusable L2.2 prompt:

## L2.2 - Platform Shortlist Review

Use the Commit Log Agent rules above. Help me review and document my L2.2 platform shortlist.

Context:
- L2.1 modality decision file or link:
- Recommended route from L2.1:
- Shortlist file or link:
- Candidates considered:
- Candidates kept:
- Candidates rejected:
- Candidates marked needs more evidence:
- Sources checked:
- Possible disqualifiers:
- Questions still open:
- Evidence I can safely share:
- Evidence I must keep private:

Please draft:
1. A short evidence review: does my shortlist follow from the L2.1 route?
2. A concise Commit Log entry for this lesson.
3. A GitHub-ready README note.
4. A suggested commit message.
5. Three questions I should answer before building the L2.3 Platform Evaluation Matrix.

Before drafting, ask me up to three questions if any important detail is missing. Do not invent sources, links, policies, prices, test results, workplace systems, approvals or confidential details.

Use the prompt after you complete the shortlist, source log and disqualifier pass. Review the output yourself before adding it to your evidence.

Add It to Your AI Projects Repository

If it is safe to share, add this cleaned file to your AI Projects repository:

module-5/unit-2/l2_2_platform_shortlist.md

Add this README note:

### L2.2 - Platform Shortlist

I used my L2.1 modality decision to create a platform shortlist. The shortlist records candidate routes, primary sources, open questions and possible disqualifiers before the full evaluation in L2.3.

Use one of these routes:

• GitHub browser route: upload the cleaned file and use the commit message add L2.2 platform shortlist.
• Local Git route: save the file inside your local repository, then run:

git add module-5/unit-2/l2_2_platform_shortlist.md
git commit -m "add L2.2 platform shortlist"
git push

If your shortlist includes private workplace constraints, publish a cleaned version and keep the detailed version in your private evidence space.

Review Before You Keep or Publish It

Before you add anything to GitHub, your portfolio or apprenticeship evidence, check:

• The shortlist starts from your L2.1 route, not from provider popularity.
• Each candidate has a reason connected to task need, data handling, cost, integration or control.
• The source log says what each source proves.
• At least one possible disqualifier has been considered for each candidate.
• Unknowns are marked honestly.
• Confidential policy, procurement or workplace data has not been copied into the public version.
• The Commit Log Agent entry is accurate and reviewed by you.

Checklist

• I created module-5/unit-2/l2_2_platform_shortlist.md
• I carried forward the route evidence from L2.1
• I compared at least two realistic platform routes
• I recorded current primary sources in a source log
• I completed a disqualifier pass
• I wrote questions that must be answered before L2.3
• I upgraded my Commit Log Agent with the L2.2 review prompt
• I added cleaned evidence to my AI Projects repository, or recorded why it cannot be shared publicly yet

Quick Check

KSB evidence focus

• K8 - The capabilities, risks and implications of on-premise, cloud-based and third-party solutions. Your shortlist compares the practical implications of different platform routes: where data goes, who operates the system, what it costs, how it integrates and where human review remains visible.

• K25 - Approaches to maintaining up-to-date knowledge of existing, evolving and emerging technologies and sector trends. Your source log shows how you checked current documentation, pricing, data handling and implementation evidence rather than relying on memory or hype.

• S25 - Keep up to date with AI, automation and technology, including methods to evaluate vendor and supplier solutions. The shortlist is the first stage of vendor evaluation: you gather current sources, identify evidence gaps and prepare candidates for structured scoring.

• S27 - Apply technical understanding to help align business needs with technical capabilities. You are translating the technical route from L2.1 into platform requirements that can support a realistic workplace project.

Up next: Lesson 3 turns your shortlist into a Platform Evaluation Matrix, so your recommendation is scored against project constraints rather than chosen from a generic provider list.