Product Verification Hackathon Projects: Test Record Matches, Not Authenticity

A product verification project needs a claim that its tests can support. Finding a matching database record does not prove that a physical item is genuine. Our 20-case fictional exercise shows how to test record matching, preserve uncertainty and write a pitch that stays within the evidence.

Research date: 1 November 2026. We executed our own small Python matcher against 20 invented cases: five in each of four controlled states. All 20 returned the expected label. We tested no physical products, accessed no regulatory database and did not test CheckAM or any other hackathon team’s software.

What the Nigerian hackathon report establishes

Augustine University’s 27 October 2026 report describes a 24-hour competition held on 23–24 October with 10 teams. It names Syntax’s CheckAM as the winner and describes a product-information lookup approach. Teams presented functional prototypes, pitch decks and evidence of originality.

The report contains no independent accuracy or false-positive evaluation. Therefore, we use it as a project prompt, without rating the winning implementation. Its publication falls inside the 25–31 October news window, while the competition began before that window. We omit prize amounts because the source’s currency character renders ambiguously.

A project report and a reproducible test answer different questions. An award tells you about a reported competition outcome. It does not supply the fixtures, evaluation rules or outputs needed to assess an unseen implementation. Our exercise supplies those materials for a separate, fictional matcher.

Define a narrow product verification project claim

Start with an observable statement: “For this supplied identifier and name, our local reference record matches.” Specify the fields, comparison policy and reference version. Then write the output label before building the interface. Avoid replacing that precise statement with an unsupported promise about a real item.

For this exercise, matching means exact equality of two strings. We do not trim spaces, ignore case, repair spelling or normalise characters. Those may be useful policies elsewhere, but each needs a stated rule and its own tests. A visually similar string is not automatically equal under our chosen policy.

Similarly, an absent identifier does not mean “counterfeit.” It means our reference lacks that identifier. An unavailable service supplies no lookup result. Both cases should withhold an authenticity conclusion. Our postcode data-contract study explains the same need to keep no result separate from service failure.

Build four controlled states and 20 fictional fixtures

We created five fictional reference records, using identifiers such as FICTION-001 and names such as Fictional object 1. These strings are teaching identifiers, not examples of official product-registration numbers. No student, customer or commercial product record appears in the dataset.

The first five cases supply the exact identifier and name. The next five pair an existing identifier with a different fictional name. Five more use absent identifiers. Finally, five cases make the simulated reference service unavailable, even though a supplied identifier would otherwise exist.

This balanced design makes the output rules easy to inspect. It does not estimate the frequency of these conditions in Nigeria. Five variants within one state also do not provide five independent demonstrations of a complex system. They exercise the same deliberately small decision rule with different fictional strings.

What the executed record-matching results show

Our run used Python 3.9.6 on macOS with an arm64 processor. All 20 cases completed and matched their expected output. The four-by-four confusion matrix places five cases on each diagonal cell and zero elsewhere. Its unit is a selected fictional case, not a physical product.

Read the rows as expected fixture labels and the columns as actual local labels. This prevents an easy error: calling a record-classification matrix “counterfeit detection accuracy.” We wrote both the matcher and the expectations. Passing them demonstrates consistency with our teaching specification, rather than independent validation or field reliability.

A larger test plan would challenge the specification itself. For example, add missing fields, duplicate identifiers, stale references, formatting variants and conflicting source versions. Decide their expected outputs first. Keep those proposed additions separate from the 20 cases actually executed here.

Count abstentions and unsupported assurances separately

We group the 10 exact-match or conflict cases as correct classifications. We group the 10 absent-record or unavailable-service cases as correct withholding of an authenticity conclusion. This second group is an editorial evaluation category; its rows still have explicit output labels.

We also check whether an output asserts that a physical item is genuine or safe. Our matcher emits no such assurance: the count is 0 of 20 completed cases. That zero is largely a consequence of the output vocabulary we designed. It is not an estimate of the risk posed by other systems.

There were zero uncompleted runs. In your own experiment, show unfinished cases alongside completed ones. Report the unsupported-assurance count over completed cases and also disclose the planned total. Do not turn missing results into successful abstentions or quietly shrink the denominator.

Reproduce the local product verification project exercise

The following Python example contains the five reference records and all 20 case definitions. It needs no network connection, credentials or external package. The unavailable-service flag is a controlled input. It does not simulate the full behaviour of a real remote service.

reference={f'FICTION-{i:03}':f'Fictional object {i}' for i in range(1,6)}
def lookup(identifier,name,available=True):
 if not available:return 'service_unavailable'
 if identifier not in reference:return 'no_reference_record'
 if reference[identifier]!=name:return 'identifier_name_conflict'
 return 'reference_record_match'
fixtures=[]
states=['reference_record_match','identifier_name_conflict','no_reference_record','service_unavailable']
for group,state in enumerate(states):
 for i in range(1,6):
  fixtures.append({'case_id':f'R{group*5+i:02}','identifier':f'FICTION-{i:03}' if group!=2 else f'ABSENT-{i:03}','name':f'Fictional object {i}' if group!=1 else f'Different fictional object {i}','available':group!=3,'expected':state})
for case in fixtures:
 actual = lookup(case['identifier'], case['name'], case['available'])
 print(case['case_id'], actual, actual == case['expected'])

Keep the original fixture file and executed result file together. For each later change, retain the code revision, run date and comparison policy. Our version-control guide offers a starting point for retaining that history. Another developer should be able to explain a changed result without guessing which inputs you used.

Attach every pitch claim to inspectable evidence

A claim-evidence worksheet links each statement to a test, a documented source or a clearly marked hypothesis. For example, “our five selected exact-match cases returned the expected label” points to the fixture and result files. “This physical item is genuine” has no supporting evidence in this exercise.

Likewise, do not imply a partnership with a database owner or permission to reuse its records. Before an authorised integration, document the access rights, interface contract, update policy and permitted uses. Then run a separate test plan for that connection. Passing this offline exercise supplies none of those permissions.

Our checkout evidence checklist provides another example of separating a local mock from an external integration. The same discipline helps a supervisor or judge assess what a demo actually demonstrates.

Download the fixtures, results and claim worksheet

• 20 fictional record-matching fixtures (CSV): inputs, availability flag and expected label.
• Executed local results (CSV): actual output, completion, check result and evidence reference for each case.
• Record-matching confusion matrix (CSV): expected labels by actual labels, in case counts.
• Claim-evidence worksheet (CSV): example claims, evidence requirements, available evidence and unresolved limits.

Read the CSVs as UTF-8 and preserve the case identifiers. The availability and check fields use textual Boolean values. A blank or missing result in an adapted worksheet must remain untested until you record an actual run. Never include private customer information or credentials in a public evidence pack.

Methodology, limitations and citation

The university report supplies the news context only. Our original contribution is the author-designed fixture pack, matcher, evaluation rules and claim worksheet. The exercise has 20 selected cases, four controlled states, no random sampling and no real-world product observations. It makes no statement about counterfeit prevalence or any team’s performance.

A matching reference record cannot establish an item’s authenticity, safety or legal approval by itself. Do not use this educational prototype for health or purchasing decisions. The useful outcome is a precise testable claim, reproducible local evidence and a clear account of everything still unknown.

Suggested citation: Nigeria Coding Academy, “Product Verification Hackathon Projects: Test Record Matches, Not Authenticity,” 1 November 2026. Cite the selected-case denominator and local scope when reusing a figure. Our original fictional fixtures and worksheets are available with attribution under CC BY 4.0. Source material retains its own terms. Featured and inside artwork is AI-generated conceptual illustration, not a tested product or interface.