Alfred AnyanInsights
← All insights

The Applicant Name at 8:47 PM, and the Evidence It Put Out of Reach

Smiling businessman in a suit with laptop and documents, exuding confidence.

Photo by Kampus Production on Pexels

The applicant name defines the evidence a judge can legitimately assess. Choose the Ghanaian operation, and the application must stand on its customers, revenue and capabilities; choose the German company, and a different record enters the room.

In April 1970, Apollo 13’s crew faced rising carbon dioxide inside the lunar module Aquarius. The command module’s lithium hydroxide canisters were square. The lunar module’s receptacles were round. NASA had working filters on board, but the boundary between two systems made them unusable until engineers found a way to connect them.

The field that changes the application

At 8:47 PM, I reached “Applicant Name” and stopped.

The Ghanaian operation reflected the market where much of the work had been tested. It carried the context behind customer conversations, delivery constraints and the practical decisions that shaped the product. The German company offered a different commercial surface, with its own contracts, records and capabilities.

Both belonged to the same broader founder story. The form would not assess that story as a whole.

Once I entered one legal entity, every later answer had to remain inside its perimeter. Which customers had contracted with it? Which revenue had entered its accounts? Which people and systems could it claim? What had that entity shipped, rather than what had been shipped somewhere else in the group?

The first field looked administrative because it asked for a name. In practice, it selected the evidence base.

That distinction matters when a founder works across Accra, Berlin and the US. The product may be shared. The founder may move between markets. Customers may encounter one brand. Judges still need to assess a specific applicant, and the cleanest narrative cannot repair evidence attached to another company.

A working capability can still sit outside the boundary

NASA’s engineers did not lack carbon dioxide filters. They had a compatibility problem.

The Apollo 13 Review Board report documents how the crew used materials available in the spacecraft to adapt the command module canisters for the lunar module system. The improvised assembly worked, helping keep carbon dioxide at safe levels while Mission Control worked to bring Jim Lovell, Jack Swigert and Fred Haise home.

The mechanism is useful here. Capability somewhere in the wider system does not automatically become capability inside the part under assessment.

A Ghanaian company cannot casually claim a German contract because the same founder negotiated it. A German applicant cannot absorb customer traction earned and recorded by the Ghanaian operation because the brand presentation makes them look connected. The relationship may be genuine, but the application needs to explain it without collapsing separate entities into one convenient version.

This is the same discipline required when an AI demo crosses organisational boundaries. I explored that problem from another angle in what happens when legal asks where your AI demo data went. The product can appear unified while contracts, data rights and responsibility remain divided.

Choose the evidence before writing the story

I could have chosen the applicant name by prestige, geography or which registration document was easiest to find. That would have made the first field quick and every later field harder.

The stronger approach starts with the award criteria. I would map each criterion to evidence owned by each possible applicant: contracts, banked revenue, product ownership, staff, customer references and operating records. Then I would choose the entity with the strongest coherent case.

Coherence matters more than the largest combined number.

If the Ghanaian operation has the clearest customer proof but the German company holds the relevant product rights, that tension needs resolution before drafting. If one entity invoiced the work while another delivered it, the application should state the relationship precisely. Where supporting documents cannot establish the claim, the claim should shrink.

This is close to the lesson in the missing IDs in Kigali’s workbook: a record can look complete until one field forces you to confront what the system can actually prove.

Make every answer survive the applicant-name test

After selecting the entity, I would place its exact legal name at the top of a working document and test every paragraph against it.

Did this applicant earn the revenue? Did this applicant sign the customer? Does this applicant own or license the product being described? Can its records support the market claims? If the answer depends on another company, the relationship belongs in the sentence.

That test produces a narrower application, but also a more credible one. Judges do not need the broadest version of the founder’s work. They need a defensible account of the organisation asking to be assessed.

Apollo 13’s engineers succeeded by respecting the interface they actually had: square canisters, a round opening and only the materials already on board. A founder completing an award application faces smaller stakes, but the discipline is similar. Start with the named entity, work within its real boundaries, and build the case from evidence that fits.

Comments

No comments yet.