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.

4

Thank you! Framing the care period around overlapping technical milestones makes total sense to prove continuity. I’m also taking your advice to split Recrubo/Carv into two files: MC2 for the acquisition narrative and OC3 for the technical architecture deep-dive.

5

Thanks Akash, good reality check. For MC1, I’m focusing strictly on my specific PRs (Filters Management) with maintainer letters confirming adoption, rather than total download counts. I’ll also attach reproducible benchmark charts for Caveman Compression (OC2) and keep routine IT volunteering secondary.

6

@geraldaddey Trust you’re doing well.

Do you still work remotely as a Full Stack Engineer?

Regarding your care role, it may be better to use it to explain any career gap during a period when you were actively looking for a tech role, or simply not make it a focal point. While there is nothing wrong with working in a different profession, relying on a care role as part of your your narrative could weaken the application. Ideally, your experience should remain closely connected to technology so you can clearly demonstrate your potential as a future leader through your technical skills, achievements, and impact. For instance, a role such as “Volunteer IT Support Engineer” is much more aligned and related to tech than a carer role.

Then, the first thing you need to establish is eligibility. As a technical applicant, you should be able to show that you’re working within a technical function, whether that’s in a technology company or a non-technology organisation.

image
image1589×558 42.8 KB

If you’re still working remotely for a company in Ghana, you may be able to use that role as part of your eligibility positioning. Alternatively, for your role at Citizens Advice Reading, consider whether there is a technology adjacent aspect of your work that can be presented, such as operating systems or hardware engineering, or related responsibilities. Because IT Support Engineer is not a qualifying role. Eligibility is always the first hurdle, so it’s important to get that narrative right before focusing on the evidence itself. In simple terms, you need to demonstrate that your role aligns with your chosen discipline, whether that’s the technical or business pathway.

On MC1, your contribution to the official Todoist extension in the public Raycast Extensions repository could potentially satisfy the requirement around significant contributions outside your normal day-to-day work. However, showing user adoption alone is not enough. While active users can help demonstrate impact, you should also provide evidence of the significance of your contribution through commit history, repository activity, stars, pull requests, and similar metrics.

You should also be careful on how you present this evidence. Make it clear that your contribution was to a Raycast extension and not to the Raycast core application itself, as Raycast is proprietary software. The same applies to Spotify Player. The focus should be on the specific open-source extensions you contributed to, not the proprietary platforms they sit on. Be explicit about the extension names and your contribution to them.

For MC2, the acquisition of Recrubo by Carv can be useful supporting evidence, but acquisitions alone do not demonstrate leadership. The acquisition helps validate that the product had value, but what the assessor will want to understand is your role in leading the development of that product.

Most of the evidence you’ve listed show contribution, but you need stronger evidence demonstrating leadership and oversight. Show how you led others, influenced product direction, coordinated development efforts, or made key technical decisions. Evidence as version control author, collaboration with team members, with you as assignee , team structures, technical leadership responsibilities, records showing you represented the technical team during acquisition discussions, and similar materials can help establish that leadership story.

For OC1, the focus is innovation, meaning something genuinely new, novel, or advancing the state of the field.

While Betrix is noted, real-time sports analytics and notifications already exist across smartwatches, mobile applications, and many web platforms. Because of that, an assessor may not view the concept itself as sufficiently innovative.

Also, architecture diagrams, technical designs, and code snippets mainly demonstrate how you built something. They are evidence of technical implementation and contribution, but not necessarily evidence that the work was innovative. What you’ve currently presented leans more towards technical delivery, execution, and third-party validation than innovation itself.

For OC2, Caveman Compression (Open Source AI) could be a stronger area to develop. Make sure you clearly show your personal contribution and the resulting impact. Commit history, repository documentation, pull requests, and contributor records can help establish your involvement. Beyond that, you should also demonstrate how the project advanced the sector. Evidence such as user adoption, downloads, repository stars, usage statistics, community engagement, or industry recognition can help strengthen the evidence set and show impact

As for Citizens Advice Reading, although it is a non-profit organisation with social impact, it is not primarily focused on advancing the technology sector. Because of that, it may be challenging to use that work as evidence of advancing the wider technology ecosystem in the way assessors are typically looking for.

Overall, I think you have some potentially useful evidence, but my suggestion would be to first strengthen and clarify your eligibility narrative. Once that’s in place, focus on gathering additional evidence that are more directly aligns with the criteria. Your existing evidence can then be positioned strategically to complement the stronger pieces and improve the overall strength of your application, which will increase your chances.

All the best.

7

Thanks for your breakdown Raphael.

To clarify my current technical function: alongside my personal projects (Betrix and Caveman Compression), I am actively working on Mercor AI model evaluation and baselining for code-generation models, which keeps my day-to-day side work firmly in software/AI engineering.

On your points regarding the evidence:

  • MC1 (Raycast): I am framing this strictly around my specific PRs to the open-source Raycast extensions (like Todoist Filters Management), supported by PR metrics and maintainer letters.
  • MC2 (Carv Acquisition): I’m using the acquisition as commercial context, but focusing the core evidence on my individual backend architecture ownership and technical leadership attestation from the CEO/CTO.
  • OC1 (Betrix): I’ll make sure to highlight the novel AI-driven safer-gambling mechanism rather than general sports analytics.
  • OC2 (Caveman Compression): I’ll be anchoring OC2 on Caveman Compression with reproducible token-saving benchmarks rather than routine IT support.

Appreciate the feedback!

8

@geraldaddey Thanks for the clarification. My point wasn’t that you’re not doing technical work. The Mercor AI model evaluation work clearly places you within a software/AI engineering context.

My concern is more about how the application narrative is presented to the assessor. From my experience, the strongest applications typically connect the applicant to a recognised technology company, product, open-source ecosystem, or/and commercially adopted innovation, rather than relying primarily on personal projects or side work.

On your proposed evidence:

  • MC1 (Raycast): Focusing on substantial open-source contributions with maintainer or author’s recognition and usage impact is a stronger angle than simply listing contributions. Getting a letter from the maintainer will weaken your evidence, if you know the maintainer to the the level that they can give you a letter, then they may just accept your code contribution even if it’s not valuable. But he/she acknowledging your contribution publicly is better.

  • MC2 (Carv): The acquisition provides context, but the assessor will likely be more interested in your individual technical ownership, leadership, and measurable impact. Letter from the CEO.CTO is not sufficient.

  • OC1 (Betrix): Be mindful that describing novelty alone without a listed patent may not be sufficient. that is why you need to strengthen the evidence with adoption, user traction, commercial validation, partnerships, or other indicators that demonstrate market value of the innovation.

  • OC2 (Caveman Compression): Reproducible benchmarks and measurable technical advancement can be okay, but you need to clearly show impact and how it advances the sector.

Overall, I think the key challenge is not proving that you’re technical, but demonstrating recognised impact, contribution and innovation in a way that rightly aligns with the criteria.

All the best.