Summary

  • AFRINIC’s official AfPIF page described MyAFRINIC v2 as a comprehensive rebuild of its member self-service portal.
  • The page sought member contacts for user acceptance testing and a live beta, along with short interviews about workflows and desired improvements.
  • The same page scheduled a 19 August presentation during AfPIF, but it does not establish that the presentation, interviews, testing or beta occurred.
  • The source does not publish tester participation, test scope, acceptance criteria, defects, migration evidence or a release date.

1. The invitation is verifiable; the outcome is not

The strongest case for AFRINIC’s invitation is practical. A registry portal is not accepted because its screens look finished. Members use it to submit resource requests, update contacts, manage billing and perform daily lookups. Bringing those users into testing can expose the gap between a product team’s model of a workflow and the institutional work a member actually needs to complete.

AFRINIC’s official AfPIF 2026 page establishes that intention. It describes MyAFRINIC v2 as a comprehensive rebuild of the member self-service portal and says the registry was gathering feedback before user acceptance testing and a live beta. It invited member contacts to join the testing and beta programme, and separately sought short interviews about workflows and desired improvements. Those are useful commitments because they place real users and real registry tasks before a release decision.

The programme information supplies a second, narrower layer of fact. The page lists AfPIF in Kigali from 17 to 20 August 2026, followed by a members meeting on 21 August. It also schedules an AFRINIC presentation for 11:00 on 19 August covering AFRINIC services, MyAFRINIC v2 and the policy pipeline. The page does not state the timezone for that session or expose its original publication timestamp.

That chronology cannot be turned into an outcome. By the 28 August evidence cutoff, the scheduled dates had passed, but the source set did not say whether the presentation occurred, how many members volunteered, whether interviews were completed or whether a test environment opened. It did not identify the build available to testers, the workflows implemented in it, the acceptance criteria, the defects found, the migration results or a beta opening date. A date passing is not proof that the activity attached to it happened.

This distinction matters because an invitation is evidence of institutional intent, not evidence of product readiness. It does not establish that MyAFRINIC v2 is secure, accessible, complete or suitable for production. It does not validate a member identity, resolve a resource request, prove a billing balance or show that organisation data migrated correctly. Those outcomes require their own records.

The first complete evidence unit should therefore be a workflow, not a testimonial. A record can name the business outcome being tested—for example, changing an authorised contact—then bind it to a portal build, test environment and privacy-safe data boundary. If the workflow fails, the same chain should retain the defect identifier, severity, owner and disposition. If a fix is made, the chain should identify the fix build, retest result and regression scope. If the issue is accepted for beta, the responsible authority and reason should remain visible.

That is the function of a defect-to-release ledger. It need not expose tester identities, credentials, identity documents, ticket contents or member records. A public view can instead disclose coverage, finding classifications, dispositions, unresolved limitations and the reasons behind the beta decision. Security, privacy, accessibility, performance and data migration should remain separately legible; one green status cannot honestly stand in for all five.

AFRINIC’s outreach can be a sound beginning even if the eventual record shows serious defects. The credible next claim is not that the rebuilt portal is ready. It is that specific member workflows were exercised against a named build, their findings remained attached to fixes and retests, and the resulting evidence—not the calendar—determined what entered beta.

2. A ledger must follow the decision, not merely collect defects

A conventional defect list is not enough for a member portal. It can show that someone reported a problem, but not whether the problem represented a real registry workflow, which version produced it or how the finding affected release authority. The useful unit is a decision chain: workflow, execution, finding, disposition, retest and release state.

That chain begins before a tester clicks anything. AFRINIC would need to define which member workflows the exercise represents and what outcome counts as success. “Contact update,” for example, is not a complete test description. The record should distinguish the authorised actor, the kind of change, the approvals or validation required, the expected state in the registry’s systems and the notification or audit trail the member should receive. A privacy-safe cohort record can show whether large and small members, different operational roles and relevant accessibility needs were covered without naming individual participants.

The environment must remain attached to the evidence. A finding without a build identifier, test environment, execution time and data boundary cannot reliably be reproduced. The same visible symptom may come from application code, permissions, stale reference data, an integration or a migration rule. A ledger should therefore distinguish production-like test data from real member data and record which connected services were simulated or live. That is especially important where a workflow touches billing, identity evidence or resource records.

Disposition is the point where a defect list becomes an institutional record. A finding can be fixed, deferred, rejected as unreproducible, treated as an accepted limitation or excluded because the tested workflow was outside the build’s scope. Each decision needs an owner and reason. Where an exception is accepted for beta, the record should identify who had authority to accept it, the affected users, any compensating control and the condition that would close the exception.

Retesting must then point back to both the finding and the fix. A successful retest on a later build does not by itself show that neighbouring workflows still work. The record should include the regression scope and preserve failures as well as passes. If the fix changes authentication, contact authority or migration behaviour, the retest boundary should say which related controls were exercised again.

The minimum chain can be compact:

Decision point Controlled evidence Privacy-safe public record
Intake Tester eligibility, consent and role Cohort coverage and recruitment status
Workflow Preconditions, steps, data boundary and expected outcome Workflow identifier and coverage state
Execution Build, environment and timestamp Version and execution window
Finding Reproduction evidence and affected records Defect ID, class, severity and affected workflow
Disposition Owner, reason and exception authority Fixed, deferred, rejected or accepted limitation
Retest Fix build, result and regression evidence Retest state and verified version
Beta decision Approval record, limitations and rollback path Included or excluded, with institutional reason

This structure does not prescribe whether AFRINIC should release a particular build. It makes the basis of that judgement inspectable. Product teams retain discretion to weigh severity, operational impact and timing, but the evidence and reasons should survive the meeting in which the decision is made.

3. Public accountability does not require publishing member data

Testing a registry portal can generate unusually sensitive material. Screenshots may contain names, email addresses, resource holdings, invoice details or identity evidence. Logs may expose tokens, internal identifiers, access patterns or connected-system responses. A credible transparency mechanism cannot depend on publishing those artefacts.

The better model is a controlled evidence layer and a public decision layer. The controlled layer can retain the material needed to reproduce and investigate a finding under access, retention and redaction rules. The public layer can expose the stable identifier, affected workflow, classification, severity, disposition, retest state, known limitation and release consequence. The link between the two should be auditable even when the underlying material is restricted.

Aggregation needs care. A statement that most tests passed can conceal a single unresolved failure that blocks a critical resource or contact workflow. Percentages should therefore be accompanied by definitions: which workflows were in scope, how many were executed, which build they covered and what counted as a pass. Critical findings should remain visible as decision items rather than disappearing into an overall success rate.

Security findings may need delayed or limited disclosure while a fix is deployed. That does not justify erasing the decision history. A public entry can initially record that a restricted security issue affected a named workflow, show its disposition and later add the details that are safe to release. Corrections and superseding builds should append to the record rather than silently replacing earlier states.

The beta record should also state the user-facing boundary. Members need to know which workflows are available, what is not yet supported, where to report a problem and how to return to a safe service path if the beta fails. A rollback or support route is part of release evidence because a reversible beta creates a different operational risk from a forced migration.