The complete editorial standards behind the canonical index of the people building AI — the definitions, sourcing discipline, taxonomy, lifecycle, dispute resolution, and governance that keep the record trustworthy.
TechWhoIsWho is a canonical reference platform for the people building artificial intelligence. It exists because the AI talent economy is fragmented across platforms that were never built for it — LinkedIn surfaces professional history but not contribution, GitHub surfaces code but not context, arXiv surfaces papers but not people. No single source answers the question most worth asking: who are the people actually building the future of AI, and where is their work?
This page describes how the platform answers that question. It is a masthead document. It defines the editorial standards, the taxonomy, the lifecycle, the dispute process, and the governance that keep the record trustworthy. It is also a promise — to the builders we profile, to the readers who rely on the index, and to the broader community whose trust the platform's legitimacy depends on.
These standards exist to protect three outcomes, in order: the dataset is trustworthy; the process is fair to subjects; editorial judgment remains independent from commercial influence. Every clause below is written in service of one of those three.
We open with Africa. The continent's AI ecosystem is real, growing, and systematically underindexed by platforms built elsewhere. The researchers, founders, and engineers building from Lagos, Nairobi, Cape Town, Tunis, Accra, and across the diaspora deserve a canonical record — and nobody is better positioned to build it than a platform rooted in the continent itself. From that foundation, we extend outward to a global reference layer of researchers and operators shaping the field.
These standards are how we make that work honest.
Several phrases throughout this document do load-bearing work — they determine who is included, what counts as a source, and when a change is material enough to version the standards. They are defined here, formally, so the work they do is legible to editors, subjects, and readers alike. These definitions are normative.
A profile on TechWhoIsWho belongs to someone who has shipped real work in artificial intelligence. We do not include commentators, influencers, or educators without demonstrated building. We do not include subjects whose public presence is primarily about AI without any underlying contribution. The platform is a record of builders, specifically — and the definition of builder in §02 is the standard being applied.
A profile is included when the subject meets one of the following objective criteria, verifiable through public sources:
For the African Edition specifically, inclusion is additionally open to active community organizers, educators, and ecosystem builders whose public contribution to African AI is documented: Masakhane core contributors, Deep Learning Indaba organizers, Zindi top-ranked competitors, Data Science Nigeria bootcamp leads, and similar roles with specific, public contribution evidence.
We do not include: commentators and newsletter writers whose output is about AI rather than the production of AI; public figures whose association with AI is through ownership or investment rather than technical contribution; subjects whose only documented AI activity is a single talk, a media interview, or social posts; and founders of self-proclaimed "AI" companies for which no verifiable AI system can be documented.
Occasionally a subject meets the inclusion criteria but the editor concludes inclusion would weaken the dataset — due to insufficient verification, identity ambiguity, conflict with platform scope, or other specific quality risk. When this occurs, the decision is not discretionary in the quiet sense. The editor records, in the internal decline log: which quality risk applies, which evidence was found insufficient, and a re-review date no more than 90 days out. A second editor reviews every decline before it stands. This protects against silent bias in the inclusion process and ensures deferred profiles are genuinely reconsidered, not forgotten.
Every profile on TechWhoIsWho is built from public sources. We do not use private data, proprietary databases, or information shared in confidence. If a fact about a subject cannot be linked to a publicly accessible source, it does not appear in the profile.
Every profile has at minimum two linked sources. Most profiles have three to five. Sources are classified as primary, secondary, or scholarly — the three types defined in §02 — and at least one source per profile must be primary or scholarly. Every non-trivial claim is cross-checked against at least one additional source before publication.
Our primary source waterfall for the African Edition draws from: Masakhane's GitHub organization and contributor histories; Deep Learning Indaba alumni rosters; Zindi competitor leaderboards; AI4D Africa program pages; the team pages of Lelapa AI, InstaDeep, Awarri, Qhala, and other African AI companies; Google Scholar author pages of African researchers; arXiv author searches cross-referenced with African institutional affiliations; and YC, Techstars, and Antler portfolio pages filtered for AI and African founder affiliations.
For the global reference layer, we draw from Wikipedia and official company pages for established figures, Crunchbase for founder and company records, and GitHub and paper authorship records for technical contributors. Every source is cross-checked against at least one other before the profile is written.
Personal contact information is never included in any profile field. This means home addresses, personal phone numbers, and personal email addresses other than a subject-provided correspondence address used only for correction requests. Age and date of birth are not collected unless publicly and prominently shared by the subject. Family members, partners, and personal relationships are excluded. Sensitive personal attributes are excluded unless explicitly and prominently self-disclosed by the subject and materially relevant to the profile.
Claims that we cannot source are simply omitted. If a subject's undergraduate institution is not publicly documented, the profile does not speculate. If a company's founding date is ambiguous, we state only what the sources agree on.
Sources decay. Links rot; companies rebrand; personal pages disappear. The platform treats source durability as an operational responsibility, not a hope. For every source, the editorial record preserves the source URL, the source type, the access date at which the source was used, and a last-verified date updated on every review. Where legally permissible and technically feasible, an archival snapshot reference is retained alongside the original URL.
Public profiles are re-verified at least every 180 days. High-velocity subjects — active founders, research leads, and others whose affiliations and outputs change rapidly — are re-verified every 90 days. Any broken or materially changed link is resolved or replaced within 14 days of discovery. The last-reviewed date shown on every public profile reflects the most recent completed verification.
Profile copy is written in reference-book register. It is neutral, factual, and specific. The platform does not editorialize about importance. Every descriptive claim is either a direct citation of public fact or immediately followed by a source link.
What this means in practice:
Profile length is disciplined. The short bio is one sentence, capped at 40 words, used in search results and as the SEO meta description. The long bio is two to three sentences, capped at 120 words, used on the individual profile page. The discipline is deliberate: it forces editorial prioritization and protects the reader from padding.
Structured works are where the substantive detail lives. Every profile includes at least one work — a paper, a project, a company, an open-source release, or a documented role — linked directly to its primary source. Most profiles have three to five. The structured works field is what elevates a profile from a listing to a reference.
TechWhoIsWho classifies profiles through a controlled vocabulary of twelve top-level categories and twenty-one subcategories. Every profile is assigned at least one and at most three categories, with exactly one marked as primary. The taxonomy is published below in full — not as marketing, but as the actual operating reference used in editorial work.
A note on the architecture: two top-level categories — applied_ai and scientific_ai — require a subcategory. Three top-level categories — natural language processing, computer vision, and AI infrastructure — allow an optional subcategory where the subject's work is sharply specialized. The remaining seven categories are flat. The selective hierarchy keeps the taxonomy manageable while capturing meaningful distinctions where they exist.
Each profile has exactly one primary category — the single best answer to "what is this person most known for?" — and up to two additional secondary categories. The primary is used for search ranking and category-page composition; secondaries capture genuine multi-domain work.
Editors apply the taxonomy under inclusion rules and, equally important, exclusion rules. A builder who fine-tunes an existing foundation model for a specific use case is tagged applied_ai with the relevant vertical subcategory, not foundation_models — because foundation-model work specifically means pre-training or frontier architecture research. A researcher who releases a dataset as the primary contribution of their work is tagged data_and_evaluation, not the research area the dataset supports. These exclusion rules are what prevent categories from drifting into catchalls over time.
If a third category feels forced, editors do not apply it. A profile with one or two strong tags is always better than one with three weakly-justified tags.
The taxonomy evolves under explicit rules. A new top-level category is added only when three or more profiles have been held in editorial review because they genuinely do not fit any existing category, and when the proposed category has clear inclusion and exclusion rules that do not overlap with existing ones. Subcategories are added more readily — when three profiles would benefit, a new subcategory is introduced and the minor version is incremented. Categories are retired only if, after twelve months, they have fewer than five profiles and an editorial review concludes they are not a leading indicator of emerging work.
As the editorial team grows beyond solo operation, the platform maintains quality controls on tagging consistency — sampling profiles for inter-editor agreement, monitoring recategorization rates, and tracking the frequency with which a forced third tag is applied. These controls begin as internal operational practice, but the platform will publish a periodic transparency summary of the measures that are mature enough to report responsibly. Where a measure is not yet statistically meaningful, the summary will say so explicitly rather than omit the category altogether.
Every profile moves through a defined state machine. This is how editorial review, subject notification, and public launch are orchestrated. Only profiles in the public state appear on the site; profiles in every other state are not publicly visible.
Transitions are one-directional except two: a profile in public may return to notified if a major rewrite requires subject re-review, and a profile in retired may return to draft if a subject later re-consents or circumstances change. A profile never moves directly from draft to public without passing through notified — the subject always sees the profile before the world does.
Because TechWhoIsWho builds from public information, the legal standard does not strictly require prior consent for inclusion. We hold ourselves to a higher standard than the legal minimum. Before any profile moves from notified to public, the subject receives the full draft and a seventy-two-hour review window.
What the notification contains:
What happens during the review window:
A 72-hour window is the default, not a ceiling. We recognize that the platform's audience is global and that the African Edition specifically includes subjects in contexts where a 72-hour email window may be unfair — cross-time-zone distances, low-connectivity environments, religious observances, public holidays, and the ordinary variance of busy professional lives. The default is held firm in the common case; the exceptions below exist so that the default does not become a trap.
If the primary notification bounces or is otherwise undeliverable, we attempt at least one alternative contact channel where one is publicly available — a secondary email from a verified source, a direct message via a subject-controlled handle, or a company contact documented on the subject's affiliation page. If no alternative channel is reasonably available and the notification cannot be delivered, the profile is not published. The editor records the delivery attempts in the audit log and re-reviews the notification plan before proceeding.
Where low-connectivity, cross-time-zone, or holiday context reasonably warrants it, the review window may be extended up to seven calendar days. This extension is at the editor's discretion based on documented context — not a privilege the subject must request. Extensions are logged alongside the reason.
This process is our standing commitment to the subjects of the index. It is how we earn the right to describe them, not just the legal clearance to do so.
Every public profile carries a visible request edit and request removal link in its footer. We acknowledge receipt of every request within two business days, and resolve factual corrections and verified removals within seven calendar days.
Factual corrections are always applied. If a role, affiliation, date, work attribution, or linked source is wrong, we fix it on confirmation. Spelling of names, preferred pronouns, and preferred short forms are corrected to the subject's stated preference. If the subject has updated their professional status — a new role, a departure, a retirement — we reflect it.
Stylistic requests are honored when they do not compromise factual accuracy. If a subject prefers a different phrasing of a factual claim, we accommodate. If the requested change would introduce inaccuracy or remove sourced material, we discuss it.
We do not remove sourced, accurate, and relevant factual claims on request. If a subject would prefer their profile not mention a company they founded, a paper they co-authored, or a role they held — the request is treated as a removal request rather than an edit request. The profile as a whole may be retired, but its individual factual claims do not become selectively invisible.
We do not make changes that would misrepresent the subject's actual contribution — either by understatement or overstatement.
A subject may request full removal at any time. On receipt of a removal request from the subject (verified via the correspondence address on file), the profile moves to retired within seven days. The page returns a clear removal signal, not a generic missing page. The database row is retained for audit purposes — the reason for retirement is captured, the decision is not reversed casually — but no content from the profile remains publicly accessible.
Removed profiles are not re-added without the subject's explicit re-consent.
Not every correction request is a simple factual fix. Sometimes a subject and the editor disagree about whether a claim is accurate, whether a source is credible, whether a category is appropriate, or whether inclusion itself is warranted. For those cases, the platform operates a three-tier dispute resolution process with defined SLAs at each tier. The process is designed to resolve disputes quickly where resolution is reachable, and to escalate cleanly where it is not.
Every dispute outcome is logged: the issue type, the evidence reviewed, the decision rationale, the standards clauses applied, the effective date. This log is internal but auditable — both by the subject whose dispute it concerns and by future editors handling comparable cases. Consistency across disputes is how the standards remain credible as the platform scales.
Editorial independence is not a posture — it is a practice. An editor has a conflict of interest when their judgment about a specific profile could reasonably be influenced by a relationship they hold outside the platform. Conflicts are disclosed, logged, and in material cases, followed by recusal.
Editors disclose the following categories of relationship with any subject being profiled:
Disclosure is the minimum standard. Where the conflict is material — meaning a reasonable observer would question the editor's objectivity — the editor recuses from the profile, and the profile is reassigned. The recusal and its reason are logged in the internal record. Non-material relationships (a casual acquaintance, an attended conference, a shared mutual contact) are disclosed but do not require recusal.
These rules apply equally to the founder during the platform's solo-editorial phase. When an editor is writing a profile of someone they know, the working standard is: disclose, and when in doubt, reassign.
TechWhoIsWho does not sell inclusion. No builder pays to appear on the platform. No builder pays for higher ranking. No builder pays for a promotional tier, featured placement, or any other form of paid visibility. This is the line that separates a canonical index from a vanity directory, and it is non-negotiable.
The platform will introduce paid products. Those products will be directed at the demand side of the market: recruiters, investors, and enterprises seeking access to the dataset, with advanced search, filtering, hiring tools, and API access. Subjects may choose to upgrade their own profiles for control and depth — verification badges, hiring availability signals, expanded media — but the base profile is always free and earned by contribution. "Upgrade" never means "pay to be listed." It means pay for editorial control of your own entry, where the entry itself was earned on its merits.
Sponsored content, where it eventually appears, is clearly labeled and separated from editorial. Sponsors do not influence which builders are profiled, how they are described, or where they appear in search results. Commercial partnerships and integrations do not grant influence over editorial decisions. The integrity of the index is the product; commercial arrangements serve the index, never the reverse.
These standards are versioned and public. Versioning follows a three-level semantic scheme — major, minor, patch — so that changes to this document carry their implications visibly.
Every version published here carries a date and a change summary at the top of the page. Affected profiles — those whose classification, source standards, or subject rights are changed by a revision — are re-reviewed within 30 days of publication. The change log grows over time as the standards evolve.
Inclusion criteria are reviewed semi-annually. Edge cases encountered during editorial work are documented (see §14 below) and, when the cases reveal a recurring pattern the criteria do not handle, the criteria are updated with a version increment and a published change notice.
As the platform scales beyond solo editorial, editorial decisions are logged per-profile — the editor who wrote it, the editor who reviewed it, the decisions made at each lifecycle transition, the corrections applied after publication. Any editor may be audited; any decision may be reviewed. The platform's credibility depends on consistency across profiles, and the governance mechanism protects that consistency as the editorial team grows.
TechWhoIsWho is a project of SITI Africa Holdings Limited. Editorial judgment is held by the editorial team, not by commercial interests within the parent entity or external partners. Sponsorship and commercial partnerships, when they exist, do not influence editorial decisions. Where a commercial interest within SITI Africa Holdings would benefit from a particular editorial outcome, the conflict is treated under §11 and the editor recuses.
The platform publishes a periodic transparency summary covering the operational measures that are mature enough to report responsibly: source-count distribution, correction volume and median resolution time, removal volume and median resolution time, dispute volume, and taxonomy recategorization trends. Where a measure is not yet stable or statistically meaningful, the summary states that directly. The purpose of the summary is not optics; it is to make quality control visible.
The inclusion standard and taxonomy are firm. The boundary cases where they meet real careers are where editorial judgment actually happens. The cases below are the ones that recur in sourcing — profiles that sit on the line between inclusion and exclusion, or between one category and another. Each is published with the platform's current decision and the rationale behind it. The list is illustrative, not exhaustive.
Edge cases encountered in live editorial work are logged. When a case type recurs three or more times without being covered here, the list is updated and published in a minor-version revision of these standards.