Advice on Exceptional Promise evidence structure for Tech Nation Endorsement

Stage 1: Tech Nation Endorsement
1

Hi everyone, I would appreciate some advice on my Global Talent Visa (Exceptional Promise – Digital Technology) evidence structure.

I am a Full-Stack and AI Engineer. My career trajectory includes:

  • Pre-UK Experience (Ghana & Remote): Full-Stack Software Engineer building web applications, scalable RESTful/GraphQL APIs, and AI integrations and working in a remote conversational AI startup remotely, where I was a key engineering contributor during Recrubo’s acquisition by Carv).

  • UK Experience:

    • Reincy Medicare Ltd: Database Administrator managing PostgreSQL and MS SQL Server databases (99.9% uptime).
    • Marygold Care UK: Carer (person-centred mental health support) while actively maintaining software engineering momentum through open-source AI projects, independent AI development, and community IT volunteering.
    • Citizens Advice Reading: Volunteer IT Support Engineer managing Microsoft 365, Google Workspace, Action1, and Intune endpoints.

I am currently considering the following evidence structure:

Mandatory Criterion / Recognition

  • MC1 – Global Open-Source Developer Impact (Raycast Ecosystem): Contributions to the official Todoist(60,000+ active users) and Spotify Player (290,000+ active users) Raycast extensions. Led the development of the Filters Management feature for Todoist and queue management/bug fixes for Spotify. Evidence includes merged GitHub PRs, commit metrics, and formal support letters from Raycast software engineers and community managers.
  • MC2 – Key Technical Contribution to Startup Acquisition (Recrubo/Carv): Recognition as a key engineer during the acquisition of Recrubo by Carv. Evidence includes system architecture diagrams, Ruby on Rails backend integration data, code quality metrics, and formal letters from Carv/Recrubo leadership (CEO, CTO, and Product Manager).

Optional Criterion – Innovation (Employee / Founder)

  • OC1.1 – Betrix AI Sports Analytics Extension (Founder / Creator): Creator of Betrix, an AI-powered browser extension (Chrome/Safari) delivering real-time sports analytics specifically designed to promote safer gambling practices in the UK. Evidence includes codebase screenshots, UI/UX architecture, and product demo materials.
  • OC1.2 – Conversational AI & LLM Observability Workflows (Recrubo / Carv): Design and integration of LLM-based workflows, automated monitoring, and observability mechanisms within a product-led AI hiring platform before and during acquisition. Evidence includes architecture documentation, code snippets, and supporting statements from senior leadership.

Optional Criterion – Work Beyond Immediate Occupation

  • OC2.1 – Caveman Compression (Open Source AI): Early contributor to Caveman Compression, an open-source semantic-compression library for LLMs. Improved encoding/decoding modules to eliminate redundant grammar while preserving factual accuracy, achieving 40–58% prompt token savings. Evidence includes commit history, repository documentation, and a letter from the CTO of Playground Dev.
  • OC2.2 – Volunteer IT Engineering (Citizens Advice Reading): Non-paid volunteer work administering M365, Intune device policies, Action1 remote management, and IT infrastructure for local community service operations.

Recrubo / Carv Acquisition & Open-Source Context

Recrubo’s conversational AI hiring platform was acquired by Carv in 2024. As a key engineer on a 5-person team, I worked on Ruby on Rails backend services, Vue.js/React architectures, and LLM observability features. During the post-acquisition transition, I managed technical debt reduction and service continuity. Evidence includes formal support letters from VP, Carv, PM, Carv, and Head of Integrations, Carv.

For open-source impact, I have a support letter from the CTO, Playground Dev.

My questions are:

  1. How will assessors view my transition through a care role (Marygold Care UK), and is my concurrent technical work (open-source contributions, Betrix development, and Citizens Advice IT) sufficient to prove an unbroken technical trajectory?
  2. Is my open-source work on Raycast best placed under Mandatory Criteria (MC) given the 350,000+ combined user scale, or would it fit better under OC2 (Work Outside Occupation)?
  3. Should I separate the Recrubo/Carv startup acquisition into two distinct evidence documents that is one for technical architecture/debt reduction under OC3 and another for commercial/acquisition impact under MC2?

Thank you! I would greatly appreciate your feedback on evidence categorisation and structure.

2

The care role does not automatically rule out Promise; the Guide allows a longer career in another type of work. Concurrent engineering work can show continuity, but your description cannot confirm sufficiency. Align care-period dates with dated merged PRs and product releases, explaining your contribution and outcomes, corroborated by maintainers. Routine volunteer IT support shows activity but is weak evidence of an engineering trajectory or sector advancement.

I would keep Raycast under MC if you can establish significant personal contribution to a substantial open-source project, an explicit Guide example. Connect your changes to adoption or maintainer acknowledgement of their significance; the extensions’ overall audience does not establish your contribution’s reach. OC2 is an alternative for unpaid work outside your occupation with ongoing sector contribution. Caveman Compression fits OC2 on those conditions: support its claimed savings with reproducible benchmarks and evidence of use beyond your own testing.

Recrubo/Carv’s architecture and debt reduction belong in OC3 if you can demonstrate attributable technical impact through before-and-after performance data and leadership corroboration. OC3 does not require commercial impact exclusively. Yes, separate OC3 and MC2 documents are appropriate if MC2 independently proves emerging recognition of you as a potential leader. Otherwise, use one OC3 document; splitting the same engineering account would not establish MC recognition. The acquisition alone proves neither your individual impact nor recognition. Keep an OC1 claim only with separate evidence of genuine innovation; ordinary product engineering does not establish it.

3

Thanks for laying this out so clearly. A few thoughts on structure and categorisation:

1. Care role transition / unbroken trajectory
Assessors aren’t looking for unbroken employment: They’re looking for unbroken technical engagement and impact. The fact that you maintained open-source contributions, built Betrix, and did IT volunteering concurrently with the care role is actually a strength, not something to downplay. I’d frame this explicitly in your personal statement: name the care role honestly, but pivot immediately to “during this period, my technical trajectory continued through X, Y, Z” with dates that overlap. Don’t let the assessor infer the gap.Tell the story yourself so it reads as continuity, not a pause.

2. Raycast contributions MC or OC2?
With 350,000+ combined users, I’d lean toward keeping this under Mandatory Criteria rather than OC2. OC2 (“work outside your immediate occupation”) is typically for things adjacent to your field but not central to it volunteering, mentoring, teaching. Your Raycast work is core software engineering with measurable reach, which is exactly what MC1 wants: evidence of recognition and impact at scale within your actual occupation. Moving it to OC2 would undersell it. Reserve OC2 for the Citizens Advice volunteering, which fits that category much more naturally.

3. Splitting Recrubo/Carv into two documents
Yes, split it. Trying to make one evidence document carry both “technical depth” and “commercial/acquisition significance” tends to dilute both arguments, and assessors are scanning quickly. A cleaner structure:

  • MC2 document: the acquisition narrative your role in making the company attractive to acquire, leadership attestations on your contribution to that outcome
  • A separate OC document: the technical architecture, debt reduction work, and observability engineering written as a technical deep-dive with the architecture diagrams and code metrics

This also gives your letter-writers cleaner, more specific things to attest to, rather than one letter trying to cover both angles.

One general note: your evidence list is strong on volume, but make sure each piece explicitly states what changed because of your work (adoption increase, performance improvement, revenue impact) assessors reward quantified outcomes over described responsibilities.

Good luck with it.